>>> There's a bug against Webkit: >>> >>> https://bugs.webkit.org/show_bug.cgi?id=102374 >>> >>> that I think points to a problem in FreeType. Simply put: for >>> fonts that have ascent+descent=line-height, this property may not >>> hold anymore after hinting. ascent+descent may be off by one >>> pixel compared to line-height, which is not quite desirable. >> >> If I understand correctly that equality is broken only in the broken >> fonts. > > Really?
I don't think so. > I thought it happens because FreeType separately rounds ascent, > descent, and line_height. From the bug: > > #ifdef GRID_FIT_METRICS > metrics->ascender = FT_PIX_CEIL( FT_MulFix( face->ascender, > metrics->y_scale ) ); > > metrics->descender = FT_PIX_FLOOR( FT_MulFix( face->descender, > metrics->y_scale ) ); > > metrics->height = FT_PIX_ROUND( FT_MulFix( face->height, > metrics->y_scale ) ); > > metrics->max_advance = FT_PIX_ROUND( FT_MulFix( face->max_advance_width, > metrics->x_scale ) ); > #else /* !GRID_FIT_METRICS */ Exactly this is the problem which I have to analyze. For TrueType fonts, the above code shouldn't be executed (or shouldn't have any influence). The function to execute instead is `tt_size_reset' in `src/truetype/ttobjs.c'), which uses ROUND, not CEIL or FLOOR. It seems that this doesn't get applied. >> So have you tried just forcing it? >> >> metrics->height = metrics->ascender + metrics->descender; The values get rounded first... >> If the height is more trustworthy, force the ascender: >> >> metrics->ascender = metrics->height + metrics->descender; In presence of an `OS/2' font table, global ascender and descender values are not derived, so your suggestion is not applicable for the font in question. > Webkit did end up working around it. I was being a good citizen and > bringing up the issue upstream. Thanks! Werner _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel