Open MickTheMechanic opened 3 years ago
@MickTheMechanic Once again you failed to post a sample so we are left guessing why you are having a problem. This is becoming a bother.
Attached is a demo using TFT_eSPI and the builtin(classic) fonts working just fine. test-ascii.zip
Without a sample I can only guess your problem,
My guess is that you have entered these as unicode characters and therefore you now have a string in quotes with these characters in your C program. If so that why they don't display. Arduino IDE and most other IDE's use unicode UTF8 character sets. The simple fonts we use like Adafruit's glcfonts are just ascii.
The UTF8 fonts are multiple characters so displaying one of them actually tries to display many, all junk. Most likely wiping out your actual ascii characters like % $.
NOTE: Only linux target platform using true type fonts currently supports UTF8 characters.
You should know some of your glyphs are NOT present in the Built in or Classic fonts. Yes, All spaces are filled in but not with what you think apparently. Using the builder, after you select your font, right click the text property and select character map to see the full character set. Select your characters, press copy and then ENTER KEY when you find yourself back in your text property field. You will then see the new characters and code gen will know how to deal with them so they display correctly. Paul--
First of all, for almost every issue I have opened I have attached a sample code, to say something like that is a bit rough. I have been hammering away with your program/library for weeks and I post issues not just for my sake.
Secondly, I would like to make it clear I am talking about the Builtin font, not custom fonts. The builtin font should contain all 255 ASCII characters. Not UTF8. And no, it is not a problem regarding UTF8, just to be clear, nothing to do with UTF8.
I know the characters are there because I checked many characters by convering the bitmaps to binary and mapped them out, and the bitmaps look how they are supposed to. There appears to be some kind of problem with the mapping of characters that are inputted to ASCII. Many characters/symbols/glyphs show something comepletely different in the builder, then completely different again on screen.
Here is an example project. Look at the characters that have been inputted to the builder. Then look at how they show on the simulated screen. Then upload the sketch and look at how they are shown on screen, you will see exactly what I am talking about.
By the way, I cannot find text property, could you please explain where it is located exactly?
I have checked your sample, and in the input field I see this: %$%£ûê This confirms what I am saying. When I type Ä I should get the character for Ä. There appears to be some kind of a mapping issue. As far as I can see the characters inside glcdfont.c correspond correctly to the ASCII id
I also forgot to mention that the builder does not output the correct ASCII character to the c code. Example: I input ° in the builder, and I get ▓ in the c code.
@MickTheMechanic Your posted example shows you entered "°ÜÖÄüöä" in unicode characters not ascii. On this field after doing a double click to get to editing the field is where you right click to get a mini popup as described in the README file for the Builder and User Guide. Here you can either clear the text field or select character map which will show the full character set. I have no input field in my sample only a display.
As I said my sample worked for TFT-eSPI but since your posted sample is targeting arduino I did a code generation targeting a Mega with a Adafruit 2.8 display and it worked fine exactly like the TFT_eSPI. Your posted sample could not work because you entered unicode why the sample I posted isn't working for you I have no idea. The Builder will output junk in your FontBugTest case. You should have noticed in the Simulated TFT Display of the Builder that the characters are displayed incorrectly. In The Builder unless you are targeting Linux you can only enter printable 7 bit ascii characters from the keyboard. To get to the full 255 set you need to use the Character Map.
Sorry, I can't help you any further. You will have to wait for Calvin. Paul--
That seems strange, as I entered º by holding alt and typing 167, so it should have been an ASCII character.
I found the character map, that part is working fine, however a different symbol is displayed on screen after uploading the sketch.
There are differences between whats shown in the builder and what is shown on screen with certain symbols, which may require further investigation. I have already implemented another workaround (I inserted my own bitmap in place of ' ), so this is purely for usability, I do not need the symbols.
I would like to know where does the builder get the builtin font from. I understand when the Builtin font is used IDE uses the font file in adafruit GFX. But where does the Builder get the font from? Perhaps the differences are diferences between the font file in the builder vs the font file in the driver lib?
@MickTheMechanic GUIsliceBuilder/fonts/glcd/glcdfont.c
Describe the bug
There appears to be a rather large bug regarding fonts. I have only been testing with the Builtin so far, but I suspect it may be wider spread. Ascii characters are being displayed either improperly or the wrong character is being shown. I have confirmed character bitmaps inside adafruitGFX/glcdfont.c are correct. Letters, numbers, and some characters work fine, but most symbols, although ASCII, and provided in the font as ASCII, do not work. Things like öÖäÄüÜ °$%& show the wrong symbol or character, despite being ASCII characters.
Checklist to try first
I have checked the character bitmaps in adafruitGFX/glcdfont.c. They appear to be in order. A quick test shows the bitmaps for ■ at place 254. 255 is blank, and all the umlauts also appear to be present. Some examples of the bug are an upper case Ä shows -ä, a lower case ä shows -n, ° shows ░. But in glcdfont.c the correct bitmaps for these characters are in the correct location. Unfortunately I am unable to confirm if the bug is present when using the Adafruit by itsself
Expected behavior
ASCII characters should be displayed correctly provided they are present in the font file