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.
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.
- 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.
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.
For Quick List on ISO 8859 Encodings see http://en.wikipedia.org/wiki/ISO/IEC_8859
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.
Character Selections and the *.chr file type
I am going to start with some assumptions of the zi font file format:
The pre-release version -0.11 (yeah, its negative) of the ZI Font Editor will be uploaded here tomorrow.
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.
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.
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.
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.
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?