Back to Blog
Nextion font wizard6/14/2023 I can put this code in the Touch Press/Release Event code and it works fine: b5.txt="ガス" If you decide to use UTF-8 you need to store the text in that encoding instead of Shift-JIS encoding… There shouldn’t be any issue with storing and sending the bytes over UART, just make sure to escape the byte sequences with the extra slash as needed. Unless you really need official support from Nextion (which is both pricey and worthless at the same time), the only drawback I see is generating the font outside the Nextion Editor…įor the MCU it’s all just byte array’s. UTF-8 encoded Japanese text uses more bytes, as the characters use up to 3 bytes.Is the de-facto encoding used in most modern applications.Supports other languages and scripts, making it more versatile.Font has to be generated in another program.Doesn’t contain the 5C sequence in multi-byte characters, so doesn’t have the bug.Not officially supported (yet), but in my testing I found it just works fine.Only for Japanese, if you want to support other scripts you need additional fonts with different encoding.Cannot display ソ in the editor nor any other multi-byte characters that end in 5C like Ы, 噂 and 浬.Font can be generated in nextion Editor.Basically it’s a design choice, so you need to weigh the pro’s and con’s. I will decide if it would be better to have the strings saved in the Nextion or in the MCU memory and send the chosen strings through the UART (more universal).īoth UTF-8 and Shift-JIS can display Katakana characters. This is not good.Īlso I am not sure how to send the japanese characters from the MCU to the Nextion in the future. If I enter ソ\ to the txt field, error message appears but then the compilation is successful and ソ\ is displayed (the backslash is visible). I cannot display the character if I enter this in the Nextion IDE (Attribute). Even if I cannot see it untill I run the simulator :-(. Is good workaround - this is the thing I can work with further. Sorry for the bad link - it was halfwidth version.Īnd here even more useful: (kana)#/Other_representations However I was not able to find workaround or solution. I knew that the problem is related with 0x5C character (\). Yes, other characters have been displayed without problems in Shift-JIS encoding.
0 Comments
Read More
Leave a Reply. |