> I've been working on a bug for webkit related to an odd behavior
> with the Ahem font in the Qt framework. I tracked it down to Qt
> either receiving incorrect descent/ascent values from
> FT_Size_Metrics or using the Freetype library incorrectly.
Within TrueType fonts, there are three sets of global descent/ascent
values for historical reasons. Normally, FreeType uses the
ascender/descender values from the `hhea' table; this seems to work in
most cases. However, the `OS/2' table holds two other sets, and it is
easily possible that your font contains strange values within `hhea'.
A few days ago I've applied a patch which makes FreeType use the
values from `OS/2' in case the `hhea' values are both zero.
> When using FT_Set_Char_Size(face, width, height, h_res, v_res),
> should face->size->metrics have the proper values for all font types
> afterwards or is it necessary for Qt to handle knowing truetype
> fonts use ((TT_Size)face->size)->root.metrics instead?
The former. But due to the problematic definition of the global
ascender and descender in TTFs, FreeType might give wrong results.
> If face->size->metrics is supposed to have proper values after
> calling FT_Set_Char_Size, then there is a bug in either ttdriver.c
> or ttobjs.c.
>
> ttdriver.c line 248:
> if ( FT_IS_SCALABLE( size->face ) )
> error = tt_size_reset( ttsize );
> will need to copy ttsize->metrics over to ttsize->root.metrics
>
> or
>
> ttobjs.c line 1057:
> metrics = &size->metrics;
> will need to be
> metrics = &size->root.metrics;
>
> are some potential fixes.
IIRC, we had such code a few years ago, and it has been reverted for
reasons I currently don't remember.
Can you privately send me the problematic font for further
investigation?
Werner
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
