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,
The pre release version -0.11 (yeah, its negative) of the ZI Font Editor will be uploaded (here) tomorrow.
Hey Andreas L
I am fighting with three main issues in the Font Editor. Clean looking conversions (trying to reverse font smoothing). Dynamic cropping as Windows adjusts font start (0,0) differently for each font. Font compression, getting wide characters like @ and W to still look good after they are compressed to fit in a fixed space - too much space allotted, and l, I and j look like starts of new words. I didn't want to put a yet to be completed version up.
However, I have been considering the possibility of a utility that merely allows you to bit edit a user defined grid (16x24, 8x12, 8x16 etc) for the 224 characters in an ISO-8859 set.
I wont get both of them completed in short order, and if you don't mind playing with a alpha beta version, tell me which one you prefer, and that one will be posted here for you on Monday.
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.
"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 ...
"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.
Hi NEXTION Team
Do you think can be solved this bug?
All the best,
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.
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.
Hi ITEAD Team
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,
ZI Font support is limited to specific font sizes in a fix width format.
The main restrictions are height is a multiple of 8 and width is limited to half of height.
This leaves: 4x8,8x16,12x24,16x32,20x40 ...upto and including 80x160.
Converting fixed width Fonts such as Terminal, Lucida Console, Consolas works
Expecting good results from variable width fonts does not
ASCII includes characters 32 to 126 for a quantity of 95 characters
ISO-8859-XX support includes characters 32 to 255 for 224 characters.
The Nextion Editor work fine in systems, and very poorly in other setting.
As such there have been several .zi font file editors contributed by the users.
With the use of one of these Editors acceptable fonts can be had.
This topic will be closed as solved while remembered as an ongoing issue.
I am not the ITEAD staff, but I am working on the ZI Font Editor.
Can you please describe exactly what "your" font problem is? I have seen so many on the board, and I am very close to releasing first version. Much of the effort has been to produce cleaner looking fonts. If I know exactly what your problem is, I may be able to address it. If I don't know, I can't even try. Also, if you apologize for your English, please provide what language and iso-8859 of your character set?
I am sorry if ITEAD staff hasn't responded. I get your message to ITEAD staff. But on one hand, I hear you say your have a problem, and on the other hand when someone tries to help - you want not that help. You can remain frustrated and your problem will still exist, or you can make some effort towards resolving the problem. I am just a guy trying to help. If you provide no effort -- no reason for me to make effort.
Thanks! I have seen it. Looks nice. Great work
You know what ... let me go off on a rant.
The way I am beginning to see it there should be absolutely no complaints about fonts. Here is the skinny version. ITEAD has a product that has uses a fixed width font, and if you use the font generator inside the Nextion Editor the ratio for width height is 1:2 8x16, 12x24, 16x32 ... The file is a contains a 27 byte header, a fontname, and the raster of each character. Someone even provided their Delphi source code (in another thread) to their "super long font" to capture variable spaced phrases. The hardware itself is a good value for a screen with flash storage and serial communications. Nextion tosses in an Editor to showcase what could be accomplished. But everyone has their own ideas on what the design should be like to accomplish their individual goals, and so this is the point logic kicks in to figure out how to accomplish what you want with the tools at hand. For me, what tools aren't there - I will create myself.
I have spent about 2 months on the editor I am working on, with a month advertised here on the boards to get discussion from the users as to what problems and issues they need fixed.
Well, for all the bitching, whining and complaining that has been done, "almost nobody" bothers to make any effort towards their solution. I can tell you this - I am not a psychic or mind reader. So ZERO responses to what you would like addressed, scientifically leads to ZERO issues needing to be fixed.
At least with the issues on this board regarding fonts, maybe it is just a bunch of people wanting to rant about their difficulties they faced in the life of a programmer. I guess I can be okay with that too. I am not going to feel poorly about my editor when I release it. It will have solved all the issues that all the users have approached me on to be addressed ... and it this point, total issues being addressed is ZERO.