@kisvegabor do you intend to implement subpixel rendering in nearest time?
I yes, and you can confirm convertor needs just a different FreeType flags in call & 3x wide bitmaps on output - i will help.
Thanks!
I’d give it a try if you added support to that flag.
@kisvegabor See master branch. CLI options --lcd (horizontal) and --lcd-v (vertical). Sample (dumped):
0x20-0x7F Roboto 16px bpp3 compressed size increase 4.4kb => 8.1kb.
Thanks!
Now mainly I’m working on the color picker widget and Right-to-left support but I’ll try it too.
As it’s about development from now I’ve opened an issue on GitHub. Let’s continue there.
@Jon_Smirl
We struggle with offset values outputted by FreeType.
Can you take a look at this issue? Hopefully, you will have an idea:
The freetype people are experts in this, best to ask on their email list.
https://savannah.nongnu.org/mail/?group=freetype
I think what you are having trouble with is mixing two different algorithms. One algorithm (the freetype one) uses offsets. The cleartype one uses high order filters. The freetype algorithm was needed to work around the Microsoft patents, but those patents are expired now. Best to ask the Freetype developers which is the best strategy for MCUs.
1 Like
@kisvegabor @Jon_Smirl
I am so happy that the subpixel renderd font bitmaps is good when I used bitmaps by the online font convertor in LittlevGL.
But now when I tried to used my local font engine(FreeType2) to realize real-time subpixel font render in LittlevGL, the font was out of shape. Maybe it is not bug of LittlevGL and I so sorry to trouble you.
Here is my code.
glyph_index = FT_Get_Char_Index( face, text[n] );
error = FT_Load_Glyph( face, glyph_index, FT_LOAD_DEFAULT);
error = FT_Render_Glyph( face->glyph, FT_RENDER_MODE_LCD);
FT_Bitmap freetype_bitmap = face->glyph->bitmap;
I am quite sure that there is no bug in LittlevGL, because the output freetype_bitmap is wrong.
the test case is the charter ‘A’.
(1)when the height of font is 50, the ‘a’ is out of shape.
(2)when the height of font is 20, the ‘a’ is good.
The result is that some size of font ok, but some out of shape.
It will thank you very much if you can give me a tip.
Hi @nacyzhouw
It seems rather the width of the font matters here. The skewed image is a typical sign of ±1 issue in width.
Could you try which widths are good and which aren’t? Hopefully we will see a pattern in them.
Thank you for your help and I fixed the bug. In FreeType, the subpixel font rendering case should use the pitch instead of width. The actual width of skewed image is pitch which is one filed of FT_Bitmap.
Glad to hear that you found the solution!