In older versions, it was possible control whether a generated font was or was not monospace.
What MCU/Processor/Board and compiler are you using?
Any
What do you want to achieve?
I want to be able to control whether a font is monospaced.
For example: built in monospace font “unscii” is monospaced.
I would prefer to have it not, considering how much space this wastes on a small screen where a font like this is useful.
What have you tried so far?
I see no option for controlling monospace anywhere.
That’s very unfortunate.
This means you need to modify the font itself, which is extremely time consuming, instead of letting the font converter simply detect the glyph width and essentially un-monospace it.
They want to be able to fit more characters on a screen. The monospacing means that more blank space is left between characters than could be left if they were cropped.
IMO, then they need to find appropriate proportional font, drawn as piхel-perfect for demanded size.
Tracker contains issues with links to big collections of pixel-perfect fonts, suitable for low resolution monochrome displays. I think, this could be presented somehow better, but nobody had motivation to organize this info.
There is no technical possibility to take bad source and make beautiful proportional font, with correct display “WA” combinations and so on.
Just as an example, the pixel perfect font “unscii” that I modified way back looked perfect when generated without “monospace” selected (even though the source font is monospaced).
That is: the old font converter was able to do exactly what you are saying is not possible to do. You can test it easily enough with the old converter and older code with unscii.
There are not so many pixel perfect fonts out there for small displays. The old converter’s ability to effectively un-monospace fonts gave a lot more freedom in font usage.
@puzrin It seems that what’s needed is a script which will output a non-monospace TTF that can be fed into the new converter, with a disclaimer that the results may not be appealing. It certainly appears that there are legitimate places where the ability to do this is useful.
I’d suggest you show that result to anyone, who understand in design. And listen his/her opinion about unkerned proportional fonts.
From my point of view, result is below minimal possible to accept quality. Seriously.
I can undersand people, who wish to change nothing. That’s normal. From the other hand, i don’ like to spend my time for promoting “bad practices”.
But i can’t prohibit volunteers to do such things. Though, i would recommend to invest time into collecting links to good fonts for small bitonal displays.
Could the font converter not do this automatically?
If you have a pixel perfect 1bpp font that is monospaced, 8 pixels wide, it can simply detect the actual width of the character (<= 8) and change it accordingly in the generated font.
Here are some examples of what unscii would look like before, with monospace not checked. You can tell me if they look terrible or not. Remember, the source font is monospaced, the proportional output is done by the font converter:
Why this suddenly is impossible is beyond me… and it was really super useful.
In your eхample, see punctuation. Visual space in fine--, is not the same as in really-!.
There is no possibility to autogenerate kerning. And without kerning result will be good only for people “very far from design”.
As i said, i can understand your desire to change nothing in your sources. But IMO you ask to make worst choice of available - return back deffective hammer for deffective nails. And i suggested at least 2 alternatives without bad side effects - try to search better font (that was discussed in lvgl tracker) or try to bulk fiх your font RSB via FontForge.
They are the same: 1 pixel. There is always 1 pixel between each character, pretty straight forward.
These examples are at 200% so you can actually read them. We’re talking 1-2" OLED displays here. Design is by constraint, let’s not pretend anyone is going to be offended by this kerning on a display of this type (other than you).
You presume there are many small pixel perfect fonts available. There are not, especially ones that have anything other ASCII. I’m the one who found many of those fonts…
I would agree that there isn’t really anything wrong with the appearance on a display of that size. We’re not looking to put Material Design on a 1" monochrome OLED.
That’s not serious. Visually, they differ twice. You asked me to explain what’s wrong. I explained. If you don’t see difference - then we can not discuss things where design is key point.
I suggested two alternaives to “fix” your sources. If first one in not ok for you, try second one. If FF has no option for bulk RSB edit, you can call FF api via small python script.
IMO fixing bad data source (font) is more preferable approach than adding kludges to lvgl core or tools.
IMO label “designed by programmers” is not very trusted :). Many people may see no difference. But that does not mean lvgl should return back magical practices like “autoconverting monospace to proportional font”.
If someone believes in this magic and satisfied with quality - “python + FontForge” will provide required freedom, i’m absolutely sure. But IMO it worth keep such things a bit aside from lvgl.
Clearly you can’t be convinced that the font looks OK, or even that it looks OK to people other than you. That isn’t my goal here. I am arguing the feature that was previously available and no longer is available was useful and would continue to be useful, and is not black magic as you claim.
FYI I was able to use Font Forge to achieve it. I used the “Auto Width” metric on every character except space. This gave me a font that is the same as it was with the old font generator: exactly 1 pixel between each character. And yes it is exactly one pixel. Is this still black magic, or is this suddenly OK to you because it was done in Font Forge instead of through the lvgl font converter?
Not many people are font savvy enough to do this, even developers. The amount of simple questions this forum gets is evidence enough of that. Getting a suitable font to work isn’t even a blip on the radar of the total work that needs to get done in a project. But, it is still a necessary step and a monospace font is useless on a tiny display. If the tool that already exists to convert a font could also do this, then that other work can be done much sooner without having to fiddle around with a font. You also wouldn’t have to answer this question again should it come up.
I think the idea is that @puzrin doesn’t think the font converter should contain workarounds for things like this. Instead it should be the user’s responsibility to use FontForge and fix the spacing themselves.
Personally I’d agree that it would be better to just have a checkbox like the old converter did, but I don’t think it’s worth debating. It’s easier to just make an external script and use that.
Yes, that’s still a magic. But until you do it on your local PC only and don’t try to push your approach into upstream - nobody cares. This solution was suggested to you not because i agree and like what you do with font. But because you can get what you wish without touching upstream.
Yes. Goal of convertor is to make TTF font look in LVGL exactly as designed. Key point is “exactly”.
Problem is, if we follow way of endess support of ancient kludges, situation will never be fixed. IMO it’s not rationale to spend time for such things forever and for free. “Fix” for source is possible, simple & free.
I agree with @puzrin regarding it’s better to keep the font converter as generic as possible. It just converts fonts as they are. Easier to maintain, less possible bugs, etc.
On the other hand, having a monospace-like font with auto-width really can come in handy in some cases. What if we really add an external FontForge script to handle this? You can run it if you wish, and the converter remains generic.
Checking the script API there is an AutoWidth built-in function to do this.
