Unofficial Nextion/TJC User Forum

Open source Nextion ZI-font tools and ZI-specification

Looks cool, I tried it but gave me some errors. Is there a tutorial on youtube or a guide on how to use it?

Nvm. Got it to work.

A+ is to generator font. and Pen tool is to edit.

-In Editor Open and load a font first. then make changes and save it. Use it in Nextion.
Tested for v0.53. Works great.

Thanks Hag.:raised_hands:

1 Like

I have a script that can convert a otf/ttf into a .zi v5 file. It can take the google repository and batch convert them into HMI fonts. Is there a list of prefered fonts, size, encodings? I can make a repository for compiled HMI fonts if there is interest.

It’s in PowerShell for the moment, but I’m converting it to C# so it can be used in @hag 's font editor.

1 Like

Dozens of Google Fonts in v5 .zi format, for all codepages and various fontsizes.

@Flatpack2 We’re working on v5 support in the Editor. But it’ll takes some time.
If you’re on Discord, you can post the .zi there and I can have a look at doing some quick edits to the file.

1 Like

A new version of the HMI Font Pack v0.0.2 has been released on Github. It now includes 2 new UTF-8 fonts and a bug-fix that could crash the Editor when the HMI screen orientationt was rotated.

All .zi files are Version 5 fonts and I’ve also included a .png preview for each font.

1 Like

Awesome :clap:t2: You’re doing so much great work @fvanroie! I’ve made some comments on your PR’s on GitHub btw, I’m not sure if you’ve seen them. If you could take a look at that we could get them merged.


First of all, thank you for you work.

Its not clear for me is *.zi file spec officialy closed ?

Is it possible to make available just replace pixel picture for every letter from any input file ? ( PNG , for example may be same dimention X * Y )

It will be much better and faster. Cause a lot of good fonts letters images available.

It seems to me that *.zi fonts are not monochrome Font ’ ! ’ symbol in Editor

Thank you!

Font example:

It’s a proprietary file format, but V3 and V5/6 have been reverse engineered and the font editor can do basic copy/paste of characters:

Fonts only have 8 shades of gray (3-bit).

Converting to/from bitmap can be done with ZiLib from the font editor, but that will involve programming that part…

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

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 []( 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?

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).