Freetype project general mailing list

Wojciech Mamrak | 19 Apr 2012 21:52

[ft] glyphs' metrics and positioning

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

(Continue reading)

headers

Werner LEMBERG | 23 Apr 2012 10:40

Re: [ft] glyphs' metrics and positioning


> 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 //!!

This is an artifact of the LCD rendering (you are using
FT_LCD_FILTER_DEFAULT).  From the description of
FT_Library_SetLcdFilter:

  If this feature is activated, the dimensions of LCD glyph bitmaps
  are either larger or taller than the dimensions of the corresponding
  outline with regards to the pixel grid.  For example, for
  FT_RENDER_MODE_LCD, the filter adds up to 3 pixels to the left, and
  up to 3 pixels to the right.

> I have also noticed some issues with metrics.advance. Specification
> as above except: font size 12px, character 'e':
>
> Values taken from the image (ft_e.png):
> advance: 7px
> bearingX: 1px
> width: 7px //!!

This is the same issue, I think.

> Across almost all tutorial examples (ignore those using

(Continue reading)

headers

Wojciech Mamrak | 30 Apr 2012 14:36

Re: [ft] glyphs' metrics and positioning

Thanks for the reply,

so slot->metrics.horiBearingX and slot->bitmap_left base on the same
value, but later start to differ due to filters, and additionally the
latter is rounded to integer pixel coordinates even when hinting is
disabled? Is there a way to get values corrected due to above?

>> 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.
>
> No.  The subpixel positioning is specified on the input side; on the
> output side, you always get pixmaps aligned to the pixel grid which
> can be easily blended into the target pixmap.  Note that you really
> must do blending and not simply overwriting; the latter would possibly
> cut off the right side of the previous glyph (assuming left-to-right
> writing direction).

I know that resulting pixmap is aligned to the pixel grid and that I
need to alter it. Maybe I wasn't clear enough here.
The question is: since bitmap_left is always (even with hinting
disabled) rounded to integer pixel coordinates, it can't be used to
calculate the offset required to create the blending, because together
with advance it is responsible for accurate positioning of glyphs (as
in the cited example).

regards

2012/4/23 Werner LEMBERG <wl <at> gnu.org>:
>

(Continue reading)

headers

Werner LEMBERG | 30 Apr 2012 19:14

Re: [ft] glyphs' metrics and positioning


> so slot->metrics.horiBearingX and slot->bitmap_left base on the same
> value, but later start to differ due to filters,

Yes, I think so.

> and additionally the latter is rounded to integer pixel coordinates
> even when hinting is disabled?

Well, a non-integer value is meaningless for pixmaps.

> Is there a way to get values corrected due to above?

`Corrected'?  What shall be corrected?

> The question is: since bitmap_left is always (even with hinting
> disabled) rounded to integer pixel coordinates, it can't be used to
> calculate the offset required to create the blending, because
> together with advance it is responsible for accurate positioning of
> glyphs (as in the cited example).

It sounds like you are theorizing here without a real example.  Have
you actually looked into the demo programs and checked how they work?
You don't need fractional pixel coordinates for blending!  FreeType
itself shifts the glyph appropriately to the non-integer position if
necessary, and you blend the glyph's pixmap using the integer offsets.

Maybe I really don't understand what you are complaining.  Most likely
this indicates confusing documentation, so please help improve that.

(Continue reading)