Bug: Incomplete display involving Chinese character #238
Comments
luwenjin
changed the title
|
Could you please send an example generated *_menu.cpp file, |
|
ui.zip You may also past these text containing Chinese characters to your experimental menuitems; |
|
So my initial suspicion was incorrect, I thought that there could have been a UTF-8 issue rendering the C++ file, this is not the case and the file is correctly generated with all the UTF-8 characters entact. Two things strike me here straight away: For unit, there is the possibility of the field being too short, it is only 5 bytes long with one byte needed for the null terminator. At least one of those characters you're using needs 3 bytes, and therefore may be very close on space. In the next version I'll NAME_SIZE_T and UNIT_SIZE_T build flags to allow the name and unit fields to be made longer. However, this does not apply to enum labels, they allow at least 20 characters. Given that as far as I can tell, the string is correctly generated, I would actually turn on IoLogging's maximum debug level and see what's getting printed into the buffer that's sent to the graphics library text printing function. To do that set the following build flag:
And then in your sketch main add the following include:
Lastly, add the following code at the start of setup:
Let's start here, and see what we find, if need be we'll add an extra log line right before the text printing to dump the contents of the string using the hex dump logging function. |
|
I'll try that on Monday. |
|
Before I can try that, I have a clue. The bug may be due to length calculation, in unicode As I recall, I've tried to add more ASCII code after the last Chinese character, eg: Hope this clue can help you find out the cause of the bug. |
|
You may be the first to use Kanji but I know there are users that have used Cyrillic and Arabic, they both ran into issues Let's get the debug output and take it from there, in the case that there is not enough detailed information from the present logging, a few lines of extra logging code may be needed. |
Designer UI
Display(selected the 2nd row)
LogI started the MCU, nav to the enum menuitem |
|
I'm going to need to try and debug this, I have a Nucleo with ST-Link debugger that has an OLED attached, which display library are you using (u8g2)? Is the font standard? |
|
I use |
davetcc
added
bug
|
I've Isolated it into a simple sketch and managed to work out what's wrong, I've fixed the U8G2 renderer so you can switch on UTF-8 encoding from a flag during code generation. Editing UTF-8 text may be a different proposition, one which would probably be possible for you to implement if needed once I add custom multi-edit soon. |
|
So I've also checked TFT_eSPI and UTF8 should work there too without any changes on our side, it just seems like the UTF8 library attribute would need to be turned on. I think for AdafruitGFX it would be better if I fixed the font renderer I have for frame buffers to work with Unicode fonts, and then handle it that way. Rather than rely on the fork that seems to use malloc in the main print loop. |
|
How about making UTF-8 the default encoding ? For at least 3 reasons:
|
|
The problem is that to the best of my knowledge based on the youtube video watching, there's at least four thousand and maybe as high as ten thousand users of tcMenu. I just don't want to break existing sketches, and UTF8 support can be turned off by the user in U8G2 too, meaning it would break things. By default the designer always outputs UTF8, Arduino on most boards compiles using UTF8, but for the graphics libraries, its a bit more hit and miss:
The flags will only be for U8G2 and Adafruit. |
|
I see 👍 |
|
If you take a look at https://github.com/davetcc/tcUnicodeHelper you'll see what I've been working on. Based on some old code I'd written for mbed, it now is able to render Unicode properly regardless of the display technology, and even has a new screen in designer to create custom fonts with complete control over the ranges. I've tested it with up to 4 character long sequences. It will be available as an option for all graphical displays in TcMenu 3.0 |
|
So the new option in the designer will allow for font creation, initially it will be quite basic:
You'd then switch on TcUnicode in code generator (which then limits the font dialog to only allow the right font types to be created.
And all the way through you can pick between TcUnicode and AdafruitGFX fonts (both for export from UI, and loading on the device). I've got a fair bit of documentation ready to go at the same time as the release. |
|
and here is the output on the display. The title is rendered using an AdafruitGFX font using TcUnicode renderer, and the items are rendered using a tcUnicode font with Latin, Latin extensions and Cyrillic enabled. If you take a look at either the arduino32 pico example or the mbed frame buffer example, these two have been converted. What's more, the library is even usable standalone, without TcMenu, and it allows Adafruit_GFX users to work with Unicode without needing any special forks. |
Case 1:
I set Unit name to "秒1" (a Chinese character + "1"), after uploading, the display only show the Chinese character， "1" is missing.
It seems only the first character is shown.
However If I only use ASCII for Unit name, everything is fine.
Case 2:
I set row in EnumMenuItem with Chinese character "1分钟", after uploading, the display only shows "1分", the last character is missing.
However If I only use ASCII for the rows, everything is fine.
I use this font
The text was updated successfully, but these errors were encountered: