Changes found on new font converter

beibean · July 9, 2019, 12:02pm

Hi,

I will use this post to comment the differences I’m finding related to font drawing once upgrade to v6.0 and new font converter.

The first thing I have found is about font size. I have used Freesans_18 for both v5.3 and v6.0 resulting a bigger font with this last update.

Header with LittlevGL v5.3 (old font converter)

Header with LittlevGL v6.0 (new font converter)

Header difference

Did you know this was happening? Maybe there should be an advice within the documentation or within the release notes.

embeddedt · July 9, 2019, 12:05pm

I can think of a couple things off the top of my head:

Font sizes might be interpreted slightly differently by the new font convertor. You can probably rectify that by converting with a slightly smaller size.
Kerning is now enabled, which will affect the spacing of the characters. The switch to disable kerning is present in the code but I’m not sure if it is brought out to the HTML.
More information about character positions is stored than before, which (again) will affect the rendering.

beibean · July 9, 2019, 12:10pm

Thanks for so quick answer ;).

I am on the way of trying to understand new font converter and the way now LittlevGL paints a character.

Anyway, a part from all the changes and the new paradigma, I think this should be noted down somewhere.

beibean · July 9, 2019, 1:09pm

I finally think I have the size which matches the previous size of 18. The new size may be 14, I checked quickly and besides the parameter:

.line_height = 18,          /*The maximum line height required by the font*/

Nevertheless, I see worse resolution/convertion on the new font encoder:

Old converter (freesans18, 2bpp)

New converter (freesans14, 2bpp)

Some differences in characters

This could be seen better opening above images with GIMP for example.

Old converter left ------- New converter right

It seems silly, but you can really notice it when watching on the screen.

embeddedt · July 9, 2019, 1:11pm

Did you mix up the first two pictures? To me the new convertor looks better:

kisvegabor · July 9, 2019, 1:59pm

@embeddedt It seems the forum was quoted the wrong image. The second has large characters while in the original post the characters’ height are the same.

Anyway, it’s absolutely possible that the sizes has been changed.
In the old version if you set 18px height the converter adjusted the size internally to fit into a 18 px tall box.
However, in typography the meaning of font size it’s quite complex. If you set 18 px height it doesn’t include all ascents and descents. The new converter uses this more common but more complex approach. So now the fonts will have the same size as on PC in text editors but (usually) will be larger than the height you specify.

Regarding the quality, I think it’s an unlucky case. Could you try a 15px font? Probably the size won’t change much but hopefully, the extra pixel is enough to solve the quality issue.

beibean · July 10, 2019, 6:10am

I understand more or less the new approach, thanks.

Regarding the quality, it seems we have lost some, at least for this case. See, I have done some tests to display the same string for different sizes:

Freesans18 v5.3
Freesans16 v6.0
Freesans15 v6.0
Freesans14 v6.0
Freesans13 v6.0

In general, if we compare character by character, font converter v5.3 obtained much better results. For example, looking the underscore glyph ‘_’, it’s curious that it is not rendered as full color in most of the cases.

It seems that Freesans16 v6.0 is the one which looks better, although the size is bigger (not acceptable in my case). Besides, many characters add soft sourrunding pixels making glyphs widder.

I know it may be an special case for this configuration, but is there any possibility to use the old bitmaps with new approach?

kisvegabor · July 10, 2019, 1:03pm

It’s a usefule article to learn more about font metrics if you are interested:

It seems possible but:

some interface functions needs to be written
the generated fonts needed to be modified manually.

I suggest opening an issue in the lv_font_conv repo and ask Puzrin. (he has written the new converter) Probably he can tell more about it.

beibean · July 11, 2019, 7:16am

Really useful to get first contact with Font’s World (need to read slowly).

Done here.

I have to more questions about fonts:

How can I choose the number of pixels for a space glyph?
How can I choose the number of pixels between any two consecutive glyphs?

kisvegabor · July 12, 2019, 4:40am

You can adjust the adv_w parameter of “space” (upscaled by 16)

github.com

lvgl/lvgl/blob/a42154777414bd768e753c55e3f80248f613de22/src/lv_font/lv_font_roboto_16.c#L1513


      
              0x0, 0x0, 0x2, 0x33, 0x10, 0x0, 0x0
          };
          
          
          /*---------------------
           *  GLYPH DESCRIPTION
           *--------------------*/
          
          static lv_font_fmt_txt_glyph_dsc_t glyph_dsc[] = {
              {.bitmap_index = 0, .adv_w = 0, .box_h = 0, .box_w = 0, .ofs_x = 0, .ofs_y = 0} /* id = 0 reserved */,
              {.bitmap_index = 0, .adv_w = 63, .box_h = 0, .box_w = 0, .ofs_x = 0, .ofs_y = 0},
              {.bitmap_index = 0, .adv_w = 66, .box_h = 13, .box_w = 2, .ofs_x = 1, .ofs_y = -1},
              {.bitmap_index = 13, .adv_w = 82, .box_h = 4, .box_w = 4, .ofs_x = 1, .ofs_y = 8},
              {.bitmap_index = 21, .adv_w = 159, .box_h = 12, .box_w = 10, .ofs_x = 0, .ofs_y = 0},
              {.bitmap_index = 81, .adv_w = 144, .box_h = 16, .box_w = 9, .ofs_x = 0, .ofs_y = -2},
              {.bitmap_index = 153, .adv_w = 188, .box_h = 13, .box_w = 12, .ofs_x = 0, .ofs_y = -1},
              {.bitmap_index = 231, .adv_w = 159, .box_h = 13, .box_w = 10, .ofs_x = 0, .ofs_y = -1},
              {.bitmap_index = 296, .adv_w = 45, .box_h = 4, .box_w = 2, .ofs_x = 0, .ofs_y = 8},
              {.bitmap_index = 300, .adv_w = 88, .box_h = 17, .box_w = 5, .ofs_x = 1, .ofs_y = -4},
              {.bitmap_index = 343, .adv_w = 89, .box_h = 17, .box_w = 5, .ofs_x = 0, .ofs_y = -4},
              {.bitmap_index = 386, .adv_w = 110, .box_h = 8, .box_w = 7, .ofs_x = 0, .ofs_y = 4},

Use style.text.letter_space

beibean · July 18, 2019, 5:23am

That’s great!

Hopefully I will be able to test all the font stuff in a few weeks.

Thanks

jking · September 3, 2019, 8:08pm

I am in the same boat with fonts under 6.0. My display is 240x320 with no antialiasing, and the font I used in 5.3 looks horrible under 6.0, even adjusted to get it to the same size.

I am using Pixellari (pixellari at 16px (at 5.3 size)

Here is a photo of 5.3 version on the display:

Here is the 6.0 version on the display (please disregard color differences):

embeddedt · September 3, 2019, 9:52pm

We are planning to switch a component of the font converter back to the one that was used in 5.3 and prior versions. That will hopefully fix the majority of the issues that users are seeing with fonts in 6.0.

jking · October 10, 2019, 3:28pm

Has this been change been made yet?

I tried the online converter again and it still does a really poor job on non aliased fonts (compared to 5.3)

Here is a screenshot from the simulator, even using a very large font size for the conversion, it’s not good. The original font is in the background.

TFT_Simulator

jking · October 10, 2019, 6:09pm

I tried using the CLI converter and seem to get better results, at least for sizes down to 16:

this is with the command:
lv_font_conv --font Pixellari.ttf -r 0x20-0x7F --size 16 --format lvgl --bpp 1 --autohint-off -o ./pixellari_6_test_cli.c

embeddedt · October 11, 2019, 1:17pm

I believe that the online font converter has not been updated (and probably won’t be until 6.1 is released). You will have to use the offline one to get the fix.

kisvegabor · October 11, 2019, 1:25pm

Yes, that was my plan.