[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Rounding of ascent, descent, and line height

From: Werner LEMBERG
Subject: Re: [ft-devel] Rounding of ascent, descent, and line height
Date: Fri, 11 Jan 2013 08:05:23 +0100 (CET)

>>> There's a bug against Webkit:
>>> 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:
>     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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]