Start a new topic

Problem with fonts

t0 = "instruments"
How can I write "instruments" with equal distance between letters?
It is a problem with fonts.
Can someone help me?

Thanks in advance,

Hi Teo,

until current version 0.32, *.zi font files are always generated as fixed width fonts. The initial TrueType font is converted character by character and put into a fixed pixel-matrix. The result is just a fixed-width font like FixedSys or CourierNew ...
Just a Pixel-Font within the generated Matrix, where every character uses the same space, independent how wide the character is. "IIII" uses the same space than "WWWW".
The only way to display text with variable width characters is, to use static text within an external generated graphic ...



Hi Gerhard ,

thanks for your prompt response.
They are the same problem with the dynamic numbers.
I want to use more products from Nextion in multiple applications .
I hope that will appear soon an upgrate who will eliminate this problem

Thanks again for the reply
All the best,

Hi Nextion Team
You can communicate an approximate date when this bug will be eliminated?
A month, a year, say something please!
Thanks in advance,

Do you think can be solved this bug?
All the best,

Hey guys, I will be working on the Nextion Zi Font Editor v.01 (for the Windows Platform).

If you have an "already functioning" or "well it previously functioned fine" *.zi font file, I would ask that you would contribute that font into the "USE This Thread for FONT Issues" thread found in the Free Chat Section.

Please take some time to read what I have posted so far, keep in mind that I will be adding more soon, and the initial release of the Font Editor will be coming as soon as possible once the *.zi font file format is finalized.  I promise that if that is going to take any extended length of time, I will pre-release a v.00 with the understanding and realization that we do so knowing the release was prior to the header commitments.

Thank you

1 person likes this

 Hi Patrick,

nothing against your affords ... but honestly, I don't see the real benefit. The font limitations are firmware-internal, and can't be covered within the font-files. Therefore, external font-editors won't help a lot, they only can work on the zi font-files, but not on the way firmware handle them ....

And the limits are

- zi fonts are monospace

- zi fonts are 1bit black and white

so, no variable character spacing, no antialiasing ... even not with an external editor ...

So, frankly speaking, with an external editor you only can administrate the "poor" quality of existing fonts, but you can't change it a lot ...

Just my 2 cents


As a quick note on font spacing in the Nextion Editor 0.34
In the Post-Initialization Event of the main page

// set font horizontal spacing to two pixels

// set font vertical spacing to 3 pixels


// refresh current page

ref 0

And then everywhere else

// dynamically set text component named t0


// refresh text component named t0, if and as necessary

ref t0

How many people are using the global variables spaxspay and the command ref in your HMI code?   These two global variables will have a default value of 0 upon power on.  They don't seem to update well in the Preinitialization Events, but placed in the Postinitialization Events followed with the ref 0, they will continue to have an effect on the text components throughout your HMI, perhaps even the effect that you are looking for.  Play around with the spacing values.

Hi Gerhard Kropf,

Yeah, I am aware of the long standing font issues as per the many, many posts dating way, way back. But I would also ask that you give me a chance and a fair shake on this Font matter. There _is a long standing_ firmware issue, and there is definite limits within bit rastered formats. By error or by design, some of the current v0.34 font issues are enabling towards non-monospace.

But I will give you some ideas of what I am aiming towards

Unicode characters and user defined characters
- I have achieved some success through work arounds
565 colored smoothed fonts
- obviously they are 16x larger than their mono-bit counterparts, but again I am working on it.

And there is a possibility for me to achieve a success first with the 2.4" versions that are using the STM32F030C8T6 and the ILI9341 hardware with the SPI/DMA connectivity to the display. The 2.8" and the 3.5" are probably also using the same hardware components and configurations. Obviously there is a larger graphics driver on the 4.3" versions and above and will require similar but additional work.

But I am a believer in that if the user base is willing to work towards a good goal and will help in both the discovery and feedback flow, I am certainly slightly better than novice when it comes to programming.



Note the lack of monospacing in the total field of the Yahtzee screen:

Note the user defined characters in the Yahtzee (dice) and the microChess (pieces)

Gerhard, (other people feel free to join in)

Maybe you can tell me what you are hoping to accomplish with a Nextion HMI design.  Try to give some me helpful details.  Start with which size/version Nextion you have.  Many things have a solution, it may require a modified approach.

Gerhard, you mentioned antialiasing, variable width, and it almost sounded like full-color-pixel fonts. 

What is your HMI design goal? 

What is your Display's role? (a stand alone, intermittently connected like a data logging sensor, always connected like a real-time sensor). 

What are you trying to drive your project with?  (Display only, a TINY85, Arduino, RaspPi, A Jaguar superComputer compute node) 

Is there a comparative project/product you are relating to?  Can you say like the gauges, this other HMI's have more than just drawing the line. 

But be helpful, is this a three hour a month project as a tinkerer/hobbist or are you some full-time NASA engineer.  Some people are veteran programmers, some don't know how to program.  Some people have a dozen resisters and caps while others have every component in a full blown lab.  Sometimes the tools make all the difference.



"Problem with Fonts" is this threads headline ... I don't see that any of your questions and indeed any of my answers would be helpfull for this ... sorry

btw. antialias and monospace has nothing to do with full color ... 

It is surely possible to send text from an external source via XSTR to a HMI, on a character by character base, and calculate the position for every single character based on its real width. But this wont change the fonts itself. For small numbers it may work, but it is no real solution for longer text.

And to create symbol zi fonts is also no issue, there are many symbol ttf fonts out ... just use them. But their zi pendant is still and only a 1bit b/w one ...


Hey G,

"Problem with Fonts" is the headline, and it is indeed directly related to my _task_ of developing the Font Editor software.  Antialiasing does have plenty to do with full-color. Antialiasing can not be accomplished in mono-bit formats.  Black next to Black only adds another pixel.  There are three methods of accomplishing lighting that pixel up.  Either every mono-bit pixel in the font is assigned to a color constant and that pushes to the display driver, or the pixel assignment goes through the word size 16 bit 565 color assignment and you push that to the display driver, or you access the GRAM directly via the DMA enabled SPI and work with the 666 18-bit color bypassing the driver conversions.

Look, I am truly trying to be helpful, in fulfilling my new role to develop a good Nextion Font Editor.

I hope you will come to the understanding my role as an ITEAD Studio sanctioned developer.


Just a thought Guys,

If I know more precisely what you are looking for, the greater the chances of me working on exactly what you were looking for.  That is simple logic. I can work on it because you articulated it to me.  But I will say that I am not looking forward to trying to play the psychic, always second guessing what you are looking for.  For some things, flexibility dictates an array of functions that are needed to accommodate a range of scenarios, and I am currently working on those type functions already.

You guys are in a great position.  Compared to the user base that comes after the Editor is released, you guys have the ability to directly influence that software now, while it is being developed.  Does this not help ensure the functionality you want has an chance of being in there?  For someone F2 could do exactly what they wanted it to do, and not "out of luck".  But because they took the time to work with me, and tell me that they wanted that F2 key to accomplish <these particular steps> for them.

Though participation is always optional, I hope you see that participation can have it's rewards.


PS: G,

There are tonnes of fonts out there, so I imagine there are likely tonnes of symbols to select from.  If someone knows how to grab from one font and insert it into a zi font, then someone can always keep on doing it that way. The two points of me showing the two screens is that the chess pieces are user defined and not grabbed from a different font -- and that means that I have the ability to create anything that I want, be it a letter, a symbol or other.  I am most certain others might like that flexibility and capability as well.  The other point there was that I gave an example of a non mono-spaced font text component output, and after seeing much issues surrounding others wanting variable-spaced and not mono-spaced, I have shown that that too is possible.   I am most certain that if something can be done once, it can be done again.  And again, I am most certain that others might like to have that flexibility and capability as well.

While I will concede that the variable spacing needs further work, I believe I have proved progress. 

Gerhard, I am definitely interested in your take on antialiasing, and how you think you might be able to accomplished it without employing full color.  To the display's ILI9341 (on the 2.4", and prob 2.8" and 3.5" as well)  there is nothing but 18-bit color. The display actually reads 18-bit 666 color from GRAM to light each pixel.  The majority of exposed display functions use some 16-bit 565 converter to expand the passed value to the GRAM.  Mono-bit font functions are almost certainly passing a 16-bit 565 color value into the function that is then looping each bit in the character to the previous 16-bit 565 converter (and in turn sets the 18-bit GRAM value). The way to bypass this is to write directly to the GRAM via SPI to the ILI9341 driver, and the only way to speed things up over that SPI is hoping to have DMA tied directly to the SPI line.  You might notice that this equates to 172,800 bytes of GRAM memory embedded in the layers of the display.  You might also notice (on the smaller models at least) that what is between the UART lines and that touch display is that 48 pin STM32F030C8T6 MCU.  Now it has a maximum of 8K of SRAM and maximum 64K for code, using just 16 32-bit registers and about 57 thumb commands, which the firmware will consume a good chunk of.  Off to the side is either a 32Mbit (4M) or 128Mbit (16M) Winbond Flash chip which is where your compiled HMI (*.tft) will reside.  That microSD SPI card is connected to the STM32F's BOOT0 pin, and that is how your *.tft file gets over to the Flash chip.  And to finish the hardware review the TX/RX UART lines are attached to the STM32F's USART pins. 

When you break the firmware down, you have bootloader portion of the firmware that will transfer the tft from microSD to Flash via BOOT0, and USART function for transferring via the USART TX/RX pair.  You have another portion of the firmware that has the functions for sending data to the display driver.  Another portion of the firmware handles the functions for responding to touch. Another portion of the firmware will handle transfers, and fetches from the 16Mbit Flash.  Now ditch any of these and you chance bricking your Display.  The remaining portion of the firmware is the "program functions" and "variables" that define the Nextion display Editor HMI design (an interpreter if you will), including the functions that are defined in the Nextion instruction set, and all the functions that communicate data back and forth from the HMI, (response codes) to your Arduino, Pi, or the MCU you connected to Rx/Tx .  They basically fetch 12-byte chunks of tft from flash, interprets what needs to be done, reports, completes, and fetches.  We know that after the firmware is loaded, the Nextion Editor is tracking compiler stats to ensure it doesn't exceed 3584 bytes on the MCU and that the compiled *.tft file routed to the Flash chip doesn't exceed the Flash's limit.

So with regards to antialiasing, and variable spacing, it is indeed calculated each/every time it is needed, repetitively for a few characters or a long character string (maxed out at 255 bytes by the way).  Those calculations will have to be accomplished somewhere.  You certainly don't have the SRAM space inside the STM32F MCU to hold a copy of the display's GRAM, and it will become painfully slower for each function you move away from the STM32F and loop over any 38400 /57600 /115200 baud UART lines. 

So, maybe my approach to making the Nextion HMI/Font Editor better is not the same approach others would take, but I will be crystal clear - I am certainly willing to entertain and discuss anyone's logical ideas while I am in the development phase to search out solutions that work best for the user base.

I am going to get back to work now.  I will eventually have to breach that plateau where I stop begging for the user base's input.  I thought my approach was simple, if you don't already have all the tools to make that Nextion Display dance to your every whim on command, then working collaboratively towards a better tool is nothing less than a benefit.  You can have your say, or not, that part is actually optional.

Sorry for the book, I hope it is insightful.


Hey Patrick,

Love the thought and details you put into the previous post!  You taught me a couple things with it. :)

Admittedly, I personally have little interest in the non mono-spaced fonts for such a display... however, I would use them if the capability was available.
My primary interest is in communication between the MCU and the Nextion.  I mean... who the heck came up with the communication protocol of ending data strings with 3 x 0xFF, and what's up with the mostly haphazard command names (rhetorical)?  They simply sucks eggs!
In my opinion, the command structure should all be short, 1 or 2 byte, codes (not human readable text).  This would give the apparent communication speed a huge boost!  And afterall, no human will be reading the data stream from the UART... that's a job for the MCU (or other connected device)!



Six months have passed since I bought one model of each display.
I spent enough money to test which model is best for my project.
The problem with fonts is very troublesome.
I waited four months for an answer from you and you have not had time to give me an answer.
Do you think we can work normally or have to forget for money spent and orient me to another producer.
I apologize for my English and I hope you understand me.
I want to use your product in my projects but you fix bugs in normal time.
Maybe I'm lucky .........
And give me an answer
All the best,