Open source Nextion ZI-font tools and ZI-specification

Thanks for explanation

If you can make each letter into an individual greyscale bitmap 32.png to 255.png with the correct height/width, I can turn it into a .zi font for you.

Thank you

I can do it by myself.

If i can’t get multicoloured fonts it’s not necessary. I thought i can use multicoloured fonts.

I have an editor ( not finished yet 100% ) and can convert ASCII symbols in to beautyfull multicoloured symbols.

I thought i can use it with Nextion.

Thanks for you work , guys.

Does any font has fixed characters table size 0xE0 ? ( 0x20 - 0xFF )

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 )

Can you try some fonts from the Cyrillic HMI Font Pack?
It would surprise me that they changed the character sets.

Does any font has fixed characters table size 0xE0 ? ( 0x20 - 0xFF )

Almost all character sets use 0xE0 characters: See the ZI font format version 6 specification

fvanroie
Thanks for answer

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:

  1. The Panel Properties :
    This is used to encode all text in Event Scriptblocks.
  2. The Text Object .txt attribute:
    This is used to encode text using the encoding of the associated font.
  3. The Debugger :
    This is used to encode text string in the debugger.
  4. 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 ##).

1 Like

Editor bugged. It swap encoding if update strings with cyrillic letters in Nextion LCD programm.

  1. 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.
  2. Correct cyrillic symbols location - compatible with Windows Text editors

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. :slight_smile: 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?

Hi

Why did you deside that i am crying ? :slight_smile: 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 :wink: Read their official forum, and watch how long time ago anybody ask about anything :slight_smile:

Yes, I tryed to ask about zi font specification and i had been banned permanently by Patrick :wink: - That is the end of the story about my dialogue with Nextion support.

1 Like

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.

2 Likes

Hi Hag,

I tried out your actual version of the font editor and didn’t find a check box ‘bold’ to generate bold fonts. Isn’t it not yet implemented?

Best regards,
Hans

Hey,

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?

Thanks,
Alex

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:
image

If you have Visual Studio Code, you can try it here: https://github.com/fvanroie/nextion-font-editor/tree/GUIupdates (Use the GUI Updates branch). I have also sent a Pull Request to @hag

2 Likes

Hey guys!

I’m sorry for not being very active in here at the moment. I appreciate the kind words and thank you for requesting features and reporting bugs.

Most of all, thank you to @fvanroie who actually does respond as opposed to me :see_no_evil: !

I will have a look at his PR tomorrow. Thank you all! Good night :slight_smile:

1 Like

Thanks a lot for the Update with the width.

But the app crashs regarding this feature.

Here is a font where the character no. 2 is smaller than the others.
https://www.file-upload.net/download-13889042/1-.zi.html

Font is not a real font, that’s not the problem :slight_smile:

Maybe you can have a look and see the problem.

Thanks,
Alex

Indeed, there is something strange about the widths in char 2…
Now I added better boundary checks. That seems to work.
Please try again.

1 Like