Start a new topic

USE This Thread for FONT issues. Nextion ZI FONT Editor for Windows

I have seen lots of discussions on the ZI FONT on the boards in every category and have read many of the issues that people are having.  So I am personally taking on the challenge to do something.  I am still waiting on some specs.

1) I have approached ITEAD Studios to work on a Zi Font Editor.


2) The programming I will be doing will be for Windows operating platform, and it is being programmed in Delphi 2009.  My aim to fix any font related issues so that the Nextion Editor is a pleasant experience for everyone.


3) I am not an ITEAD Studios employee.  I am not priviledged with their business information or other data about ITEAD Studios, I will not have any answers or information regarding future products, releases, or statements than you have.  I have taken on this work personally of my own free will.  There may in some future moment exist some reward if and only if you are happy with the solution I come up with.  Other than that, keep in mind that I am unpaid and limit any abuses.


4) I am human and have limitations. I can not perform twenty assignments while simutaneously multitasking at 5.0 GHz.  I am versed in English, but fairly well in binary computerese as well.  I am in the GMT-400 timezone and I am not a 24/7 machine.  I require sustenance, rest and entertainment, try to limit directing any frustrations this direction.  Logical thought processes and comments will help to create a better Font Editor.


5) To accomplish a good Font Editor, the code/updates will be kept in a single location to stay in control and on top of the updates.  For this reason, I am not making my programming code Open Source.  No requests for the source code, no GIT hub file branching -- no zillion copies with unknown versions or multiple versions where one functions well for 2,3,and 7, next 3,4 and 5, and next 3,5 and 7 - no worries about "why doesn't 4 work anymore.

So let's get started.

Patrick

 


1 person likes this idea

The ZI FONT files

The Zi Font Editor v.01 has not yet been released.  I am waiting for specs on the zi font header.  My objective is to make certain that existing fonts will continue to function both in the Nextion Editor and the Font Editor.  As such, I haven't yet committed the created Font Editor font to a file, delaying the editor until I can determine the header specs, or risk that an "already working font" may fail.

If you want to assist, please post your "already working" "existing *.zi font files" and be sure to include the details of the font.  Name, number of characters, character set the font is using, width and height.  To add a font in the Nextion Editor project, you click the "+" (plus sign), an open file dialog appears with the *.zi file format, you select which font you want to add and click "Open".  On success, the Nextion Editor provides details about the font you selected.

Example 0-f2-8X16,(qty:224;size:3,586)
- where 0 is the font number to use in a text component font attribute
- where f2 is the font name
- where 8X16 is the font size, 8 pixels wide by 16 pixels high
- where qty:224 shows the editor has loaded 224 characters from the f2 font
- where size:3,586 shows the font format is taking 3586 bytes.

Please include this detail line when you contribute your "already working" existing *.zi font files

What is a Font Editor


One of the first objectives of the Font Editor is to resolve the issues around a lack of previews.  The next objective is to include the user in as many aspects as possible during the font creation and with as much control towards editing as possible.  To begin, you the user must understand that the Nextion Displays are not driven with the same computing power as a desktop publishing computer, but comparatively a rather limited MCU.  If we try to create a calligraphic font with elaborate flourishing tails that intertwine with the other letters, we will fail (not that you couldn't put that kind of thing into a picture and then swap picture elements - but that is not a font).  The next point is that the Nextion Display stores the font in a raster format and not through vectors and vector calculations, points, lines and weights.  So much of what you have seen on your desktop system with True Type Fonts have been vectors. 


Raster format is a grid of pixels, with a width and a height.  An 8X16 raster is 8 pixels wide with 16 pixels high. So picture drawing out a grid, and marking each tiny block in the grid you want to have lit up, because in essence that is pretty much what the MCU is doing.

Every, Any and All vector-to-raster automated conversion or raster-to-vector automated conversion will contain imperfections.  The key is for the conversion process to do most of the heavy lifting and allow for slight tweaks along the way.  Every user will always have personal preferences, and those preferences will definitely differ from person to person.  So no matter what the scenario, some people will like one group of settings, while others want a different group of settings.  The key will be to allow each person to make their own tweaks so that they can be pleased with their own results.

How many characters are in a zi font? 


Well, as more people contribute their working *.zi font files, I may learn more.  From my understanding it can be high with a Chinese Character set working with double-byte characters in a 94x94 grid, though I have no direct experiences.  For most of the International Character sets, my understanding is that without Unicode or UTF-8 Encodings a character set contains 256 characters from 0 (null) through to 255.  In some cases, there may be a limitation to just the 128 7-bit ASCII characters from 0 to 127.  In may cases the first 32 non-printable characters from 0 to 31 are simply not given access and are just not included.  Likewise, many fonts also blank the first 32 after the ASCII set from 128 to 159.  So to answer the question of how many, it may vary from 96, 128, 224 and possibly 256.

What about UNICODE and UTF-8?

I will make a serious effort at creating provisions for Unicode characters, I will not be attempting UTF-8.  UTF-8 would require that the MCU onboard the Nextion Display to continually check upcoming characters sometimes three and four characters deep to determine if this single-byte represents a character, or if it is a two-byte character, or if it is a three-byte character, and maybe even a four-byte character.  We are creating a Font Editor and I am certainly not in control of the Nextion firmware. Unicode goes from the hexadecimal range from 0x00 through to 0x1F9FF.  Trying to attempt the entire Unicode character set into a *.zi font format would result in a file with 129536 declared placeholders for the characters.  For a Tahoma 12 point font (16 pixels wide X 19 pixels high) stored in one bit per pixel, Unicode could consume 4,922,330 bytes, and if we attempted a 565 color font we are at 78,757,280 -- completely blowing the storage capacity of the Nextion Displays.  But there is a method that can pull out a Unicode character from an installed font and place it into a quantity-limited character set in a zi font.



1 person likes this

Windows Font CharSet and ISO-8859 Character Encodings.

There are similarities and there are differences.  In version v.01 of the Zi Font Editor, I am certainly not going to attempt to capture, catalogue and understand every potential lettering set that may exist.  Rather, since this is a Windows program, running on a Windows platform, I am going to tap the Windows CharSet Font Attribute that already exists.  As Windows TrueType Fonts can include additional characters for the various character sets types via this font attribute, we will have indeed provided you with access to all the possible characters that are within any given Windows TrueType Font.

Windows defines the following CharSets: ANSI_CHARSET, ARABIC_CHARSET, BALTIC_CHARSET, CHINESEBIG5_CHARSET, DEFAULT_CHARSET, EASTEUROPE_CHARSET, GB2312_CHARSET, GREEK_CHARSET, HANGEUL_CHARSET, HEBREW_CHARSET, JOHAB_CHARSET, MAC_CHARSET, OEM_CHARSET, RUSSIAN_CHARSET, SHIFTJIS_CHARSET, SYMBOL_CHARSET, THAI_CHARSET, and the TURKISH_CHARSET.


Please be aware, not every true-type-font file will contain every attribute, many simply contain some.


For Quick List on ISO 8859 Encodings see http://en.wikipedia.org/wiki/ISO/IEC_8859




1 person likes this

Raster Fonts: Chunky vs Smooth/Antialiasing


I want to quickly address this attribute of fonts.  Raster fonts are lit pixels in a width x height grid.  The choice for each pixel in the grid is either off or on.  Its binary 0 or 1.  So raster font tend to look blocky, chunky, so retro!  Most computer systems today have implemented antialiasing and font smoothing techniques, and while this is nice on our desktops, phones and tablets, it generally is not a feature of MCUs and the embedded world.  So how does this smoothing work.  Where binary black is black and white is white, smoothing puts in extra pixels with softer shades and tones beside the binary pixel (only appears to smooth) and yields a more pleasing effect to your eyes.  When converting from true-type with this smoothing feature into a raster that does not, the technique we employ is to use thresholds.

Converting with Thresholds: and understanding 24-bit RGB and 16-bit 565 colors


24-bit RGB colors have 3 color channels (red, green and blue) with three values.  An 8-bit value 0 to 255 for red, An 8-bit value 0 to 255  for green and An 8-bit value 0 to 255 for blue.  Many times RGB is expressed in hexadecimal as FF88CC where FF is 255 for red, 88 is 136 for green and CC is 204 for blue.  If we were to use the formula 255 x (65536) + 136 x (256) + 204 = 16746700 = FF88CC.  In binary FF 88 CC would look like 11111111 10001000 11001100


Likewise 16-bit 565 color also has 3 color channels (red, green and blue) with three values.  A 5-bit value 0 to 31 for red, A 6-bit value 0 to 63 for green and a 5-bit value 0 to 31 for blue.  It is less easy to see 565 format in hexadecimal FC59 where 31/31 for red, 34/63 for green, and 25/31 for blue.  We can use the formula 31 x (2048) + 34 x (32) + 25 = 64601 = FC59  In binary FC59 would look like 11111 100010 1001.


You may notice comparing RGB 24-bit and 565 16-bit binary, the 565 format basically discarded the 3 least significant binary digits for red (the same as value / 8), the 2 least significant binary digits for green (the same as value / 4) and the 3 least significant binary digits for blue (the same as value / 8).


Using the Thresholds


When we use thresholds to determine if a colored pixel should be in an off or on state, we are merely placing a minimum value on each of the three color channels. If all of the channel values are greater than their threshold values, the pixel is set to on, if any of the channel values are less than their threshold values the pixel is set to off.  The threshold values range from 0 to 255: in steps of 8 (0,8,16,...) for red, in steps of 4 (0,4,8,...) for green and in steps of 8 (0,8,16,...) for blue.  The Zi Font Editor will allow you to adjust each of the channel threshold values individually.



2 people like this

Character Selections and the *.chr file type


I am going to start with some assumptions of the zi font file format:

  • The zi font format may be limited to a specific number of characters
  • One finds by some limitation that not all characters are addressable.
  • Unicode and UTF-8 are not supported

Selecting how many characters in a *.chr file set

For what ever reason, if the font is limited to the 7-bit ASCII values 0 to 127, and the control characters from 0 to 31 are not available, most of the other characters are addressable from the keyboard by directly typing a keystroke.  In the scenario, we are limited to a maximum of 96 characters.  If we have access to 8-bit ASCII but the control characters are not available, then we again are limited to a maximum of 224 characters.  If by chance we have access to the control characters in 7-bit ASCII our limit becomes 128 characters, and in 8-bit our limit becomes 256. 

Because of the various scenarios that may or may not occur, the Zi Font Editor allows you to select between 96, 128, 224 and 256 characters in the set.  As you discover what your limitations are (limited to just 96 characters), you can simply select the 96 Char in Set for each font file you will want to generate.  Fewer characters of course, will also mean less Nextion resource space is required for your HMI.

The default.chr file

This should be simple enough.  To allow for multiple languages in multiple character sets, the Font Editor starts off with this basic assumption.  The first 256 characters are the Unicode range U+0000 to U+00FF.   The first time the Font Editor starts, the default.chr file is created with two-byte word values for the characters 0 to 255 filling in the Character Selection table where character 0 (null) is U+0000 or decimal 0, character 1 is U+0001 or decimal 1, all the way through U+00FF or decimal value 255, and then saves this table to the default.chr file.

Now, lets suppose for any reason that 0 to 255 is not the case, and three of the characters need to be changed.  If I can look up the Unicode value of the replacement characters I need, I can then use the Hex to Dec converter below the Character Selection table and copy the decimal value into the appropriate table cell where I need to change the character. 

For an example:

Lets say instead of the letter C (Hex 0x43) I need replace the C with the Coffee Cup symbol (U+2615)
Below the Character Selection table
  • I enter 2615 in the box for the Hex value
  • then I click on the box for the Dec value.  This converts 0x2615 to decimal 9749
  • I can then copy 9749 (Ctrl-C or right click and select Copy) 
  • Goto the original cell for the letter C (Row 40, Col 3/B) and double click to edit the value
  • either paste (Ctrl-V or right click and select Paste) or enter 9749 into the cell value.

I can now right click the Character Selection table and either
  • select "Save Changes" to amend and save my current *.chr file and the changes are saved, or
  • select "Save as ..." to create a new *.chr file.  I will give this one a new name "test34" and click Ok.  This will create a new file test34.chr with the new values in the Character Selection table.  I will immediately notice in the upper right corner of the Character Selection table that my test34.chr is immediately available in the drop down box.

Each successive time I use the Font Editor and select my test34.chr, the capital letter C 0x43 will be replaced by the Unicode 0x2615 Coffee Cup symbol if it is available in the selected font. 

When using the Nextion Editor, a text component using this generated zi font and that containing a C will have the coffee cup displayed.  ie:  t0.txt="C at 10:30" will show:   coffee cup at 10:30.

1 person likes this

The pre-release version -0.11 (yeah, its negative) of the ZI Font Editor will be uploaded here tomorrow.




3 people like this

Okay, here it is ... the ZI Font Editor.  There is more that can and will be done.  But it made these:



Can it be better, oh yeah.  Is it the best thing since sliced toast - hell no.  Is it clumsy, maybe.  But just think about it, you only have 224 characters in a set (except for Chinese GB2312, then it's 8178+ascii)

Don't expect miracles from fixed width, they haven't added Variable Width to the firmware.  Read the About, I expect everyone that will use this to send off an email to the email address in About.  I will get to work on the manual now.  And just remember, it's not the last and final version.




1 person likes this

We are now at pre-release -0.10 after I made a final update in -0.11.  It was uploaded, I discovered the error (would not bit-edit at all, yeah I broke it), removed it ... and have that part fixed.  I apologize for the delay.


zip

Thanks for your work Patrick,


A question if I may!


I'm struggling with an issue that larger fonts cause the display to drastically slow down (dropping refresh rate of value updates from ~50hz to about ~15hz when using a single 3 digit display at 160 height font on the 5" display

Is this just a pixel rendering issue, or could I cut down the font character set to just numbers to speed things up?

@James.  Can you post a screenshot so I can see the font/background, or the HMI.  Personally I would have considered a different approach just for the sheer size the font file.

80x160 font x 224 characters = ~358433 bytes of flash for the font

3 digits @ 38400 pixel coverage, changing 86400 bytes of GRAM has to compare pixels

80x160 @ 10 digits as 10 pictures uses 256000 bytes, but may not need to compare.

You could run trials to time comparisons


I could reduce the font size if it is just the 10 digits you needed, possibly better

is there is a defined range for the three digits, or is it 000..999?


I'd still like a peek.



Let me peek, I'll give you an opinion.

Image below - the gear (N) is a set of 6 images, which works reasonably quickly. The zero below is the speedometer - up to 3 digits. Have tried adding 3 seperate pictures with a 0-9 number picture array and just changing the pic= value, however this is about as slow as just using the font...

If I make the speed font small - there is hardly any slowdown!



Prior to you mentioning you were using a font height of 160, 96 was the highest I was entertaining in the font editor.  The useful size of your N and 0 as pictured is around 80 wide and only 60 high.  I'll make the assumption that it is the time to redraw each 80x160 that is the bottle neck.  Also questioning the page size in flash, crossing page boundaries to retrieve the font/picture could also be a cause slowing things down.  Now, considering the application, if you were to set the digits as individual numbers, the need to update the third digit doesn't occur often, you could order you updates third digit often, second digit frequently as needed, and first digit seldom as needed.  Also as individual digits you can have an irregular font 80wx60h as your placement becomes fixed (assuming the size is as pictured).


80x60 as a font, is 4800 pixels, 600 bytes per character, to cover the digit range from space to 0, 26 chars in the font file 15,633 bytes which with a touch of code could be 6033 bytes.  Assuming third digit is every round, second digit is 60% of the time, and the first digit is 1%, the 80x60 size brings pixel changes to 37.5% compared to the full 80x160, and the update as needed brings changes to 53.67%.  Combine those to savings to ~20%, and you hope that the extra cycles for the code balance out with the reduced cross page flash accesses.


Let me know if it is that is the larger size in the photo, perhaps attach the font.









1 person likes this

The latest Version -0.09 (yeah, negative) of the ZI Font Editor is available now.


Bypassed Preview Mode and Table editing functions now added.

Read the Readme, and Send an eMail to get the Manual.

zip

Patrick, thanks for the tips - I'll try that, have you had any experience with the Enhanced model? Would the faster processor aid in font rendering speed do you think?

Login or Signup to post a comment