Nextion somehow changed cyrillic leters order in zi files. It became uncompatible with PC ASCII table. So if send ASCII cyrillic chars via MCU USART into Nextion LCD, strings look like a mess. I am trying to fix it by software. ( edit every chars tediously )
Any font in KOI-8 or 8859-5 ( cyrillic ) are incompatible. If i had defined cyrillic chars string in my C program on PC ( editor does not matter ) Example : t0.txt=“Русский текст” and send it via MCU USART into any Nextion LCD will be displayed on LCD other cyrillic letters - mess. Real cyrillic table in any OC Windows is [https://segfault.kiev.ua/cyrillic-encodings/#cp1251]( windows-1251 or CP1251)
Cyrillic charecter in any generated by Nextion Editor font located uncorrectly - wrong places. But cyrillic text assigned in Nextion Editor looking good if you’ll never try to change it via COM port command or in Nextion LCD code locally. But if you trying to update string with other cyrillic string it become unreadable even if you update string in LCD code locally as respond to some action.
By the way, Intellegent LCD use KOI8 table for updating chars even if text field defined as 8859-5 locally update example : t0.txt=“Русский текст” , but Basic LCD use unknown to me table and all cyrillic leters swap on “???”. It seems bugged Editor. Because in editor debugging mode i saw the same behavior as on real LCD. I guess that will happen with all symbols upper then ASCII 127 code.
I wrote zi converter that change any 8859-5 zi font to correct letters order, and now any cyrillic text looks perfect if i send it into LCD via COM port into any field ( if field has 8859-5 font assigned )
But, how to fix updating fields in LCD code? - unknown to me. Only if Nextion going to fix Nextion Editor behavior. It seems to me all mess and real LCD behavior programmed by Nextion Editor.
ALL Cyrillic fonts in PACK are not good - wrong cyrillic symbols location if update strings from MCU via USART. If updating the same field in LCD commands locally, the cyrillic text will change into another symbols depended on LCD model.
While it might be possible that Cyrillic character sets are broken, this sounds to me like a character encoding mismatch. There are several places where you can set the encoding of text within a project, as noted in this topic.
There are actually 4 places that (can) have a different text encoding:
The Panel Properties :
This is used to encode all text in Event Scriptblocks.
The Text Object .txt attribute:
This is used to encode text using the encoding of the associated font.
The Debugger :
This is used to encode text string in the debugger.
The MCU or PC:
Any encoding, but the encoding of the text sent should match the encoding of the associated font.
Unless the encoding matches the encoding of the font you are using, you will get garbled characters.
While there were clearly issues in the Shift-JIS implementation, I haven’t seen/heard about Cyrillic problems. I’m not actively using this encoding, so further investigation is needed.
The screen is basically a ‘dumb’ device that draws the picture of character number ## at position x/y. It’s up to the program to make sure the requested characters have the matching encoding (character number ##).
Editor bugged. It swap encoding if update strings with cyrillic letters in Nextion LCD programm.
BAD font ( May be cyrillic symbols located correctly according to 8859-5 encoding, but that encoding useless if i updating strings via COM port. Because Windows Text editors, MPLAB , Arduino IDE use another encoding for cyrillic letters.
Unless you check all 4 places for the encodings and match them up, there is no way of knowing where the bug is…
Normally you adjust the program to send out the matching encoding. You can simply verify by monitoring the serial port and looking at a HEX dump of the data.
Yes, you can adjust the font to match the output of the program, but that’s way more work.
Hi, yes i checked all 4 places. Better fix the font , and not use hex char conversion on MCU side before sending every string into LCD. I just inform the readers that the cyrillic support in Nextion LCD bad. May be someone russian spoken read this and desides to unswer. I saw some posts about that problem on russian forum, but 4 years earlier - 2016. Nothing new about that problem. Nextion Editor 0.59 also bugged.
Did you ever contact the Nextion support about this issue, giving them all the needed elements to reproduce it? I guess they are the only ones to shed light onto that and to be able to fix it. What did they say? Did they reply to you? Did they take you serious?
Why did you deside that i am crying ? I solved that problem for my projects. Nextion does not care about hobbyist communities, they care about big orders and paid support services for custumers Read their official forum, and watch how long time ago anybody ask about anything
Yes, I tryed to ask about zi font specification and i had been banned permanently by Patrick - That is the end of the story about my dialogue with Nextion support.
You are a funny guy @Fjodor. Has Nextion support, ever in the history of time, ever once acknowledged a fault in their product? When they finally fail to blame the user (after many attempts), they blame the constraints of the microcontroller platform.
thanks for that great editor.
I already did my own font.
One question. If i open a ZI font which i don’t like (created by Nextion Editor) i see that some Icons are smaller (width) and i want to increase the width of the character. How can i do that?
Let’s say i want the mono-font where every icon has the same width (like 7 Segment numbers) the Nextion Editor now create always a bad font.
Is it actually possible to increase the width when i open a ZI Font with your editor?
That feature was not yet in the current version, but I have added a CharacterWidth dialog box. Now you can use any width and allow to adjust the kerning values too:
This forum is in no way affiliated with NEXTION®, ITEAD STUDIO®, TJC®, or anyone else really. All product names, logos, and brands are property of their respective owners. All company, product, and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement from the respective rights holder(s).