Re: [ft] glyphs' metrics and positioning

[Werner LEMBERG]

> 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
> 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?

Yes.

> 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).


    Werner