Re: [ft] glyphs' metrics and positioning

[Wojciech Mamrak]

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 <address@hidden>:
>
>> 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