[ft] glyphs' metrics and positioning

[Wojciech Mamrak]

Hello List!,

I would like to present some of my questions and doubts regarding
mostly glyphs' metrics and positioning. I will try to be concise.


Data reliability in glyphSlot->metrics

Based on the image from tutorial step 2:
http://www.freetype.org/freetype2/docs/tutorial/metrics.png

advance = bearingX + width + x //for horizontal text layouts

Assume I need to know the value of x - I can obtain it from the above formula.
I've made a test: freetype 246, font arial 5.10, font size 40px,
FT_LOAD_FORCE_AUTOHINT, FT_RENDER_MODE_LCD, FT_LOAD_TARGET_LCD,
FT_LCD_FILTER_DEFAULT, character '1':

(values based on 26.6 pixel format)
advance: 22.0px
bearingX: 4.0px
width: 11.0px

Attached image presents the rendered glyph with additional border so
that bearingX can be verified.
Values taken from the image (ft_1.png):
advance: 22px
bearingX: 4px
width: 13px //!!


I have also noticed some issues with metrics.advance. Specification as
above except: font size 12px, character 'e':
Values from ft:
advance: 7.0px
bearingX: 1.0px
width: 6.0px

Values taken from the image (ft_e.png):
advance: 7px
bearingX: 1px
width: 7px //!!


What can cause the above discrepancies? Is data in metrics reliable? I
will keep my other doubts until I receive an answer to that, since
they follow from it.


Thanks,

regards

PS. Additional question:

Across almost all tutorial examples (ignore those using
transformations) the following code is used:
/* now, draw to our target surface */
my_draw_bitmap( &slot->bitmap,
                          pen_x + slot->bitmap_left,
                          pen_y - slot->bitmap_top );

Since bitmap_left origins from the bitmap, it is always rounded to
integer pixel coordinates (i.e., it is a multiple of 64), right?
What follows from it is that it can't be used when implementing full
wysiwyg rendering systems (i.e. with subpixel positioning), and
instead slot->metrics.horiBearingX should be used. It is my assumption
from the definitions of both, which are very similar. What is more
interesting these values are never equal to each other (the difference
is usually one pixel) TBH I don't like situations when the same data
is duplicated in two forms: accurate and less accurate :) Are my
assumtions correct?

ft_1.png
Description: PNG image

ft_e.png
Description: PNG image