Re: [ft-devel] Issues due to commit "Fix metrics on size request for scalable fonts."

[Peter Hurley]

On Tue, 2012-04-03 at 11:35 -0400, Werner LEMBERG wrote:
> > This is not strictly a vertical line spacing problem. The primary
> > impact of this fix is that the metrics are now integer-scaled rather
> > than fractionally scaled. (Indeed, this appears to be the reason the
> > TT driver overrides the default size_request.)
> 
> Yes.  This is what the TrueType standard mandates for bi-level and
> grey-level glyphs.  Note that ClearType is *not* implemented in
> FreeType yet!  As soon as this happens, the situation changes.  This
> document
> 
>   http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx
> 
> writes the following about the GETINFO bytecode instruction:
> 
>   Compatible Width ClearType (Selector bit 7, Return bit 14)
> 
>     This flag is requested by setting selector bit seven.  If the
>     return bit fourteen is set, this indicates that the glyphs for
>     this font size will be adjusted post hinting in order to return
>     advance widths that are exactly the same as bi-level rendering.
>     If the return bit fourteen is not set, then the advanced widths
>     will be either returned as integers rounded to the nearest pixel
>     or rounded to the nearest sixteenth of a pixel.  The former is
>     referred to as natural widths ClearType and the later as sub-pixel
>     positioned ClearType.
> 
> > Integer scaling *may* have been the font designer's requirement.
> 
> If you develop non-ClearType TTFs, this *is* a requirement.

I think I wasn't clear enough here about integer-scaled vs. fractionally
scaled metrics. I'm not referring to "Fractional Advance Widths".

I'm referring to when the x-scale is forced to be an integer-multiple of
units/EM.

For example, let's suppose that I use FT_Set_Char_Size() to specify the
desired character width as 10.66 (really, 10 43/64). This generates a
size_request() to the TT driver, which the TT driver initially forwards
back to FT_Request_Metrics(). Assuming that units_per_EM == 2048, the
computed x_scale will be:

   x_scale = 10.66 * 2048 = 21856

This represents a fractional scaling value.
Let's say this produces a max_advance of 384 (or 6.0).

Now, if the TrueType font header indicates that integer-scaled values
are required (Flags & bit 3 -- see here
https://developer.apple.com/fonts/TTRefMan/RM06/Chap6head.html)
the TT driver recomputes x_scale:

  x_scale = 11 * 2048 = 22528

and then recomputes max_advance. This larger scalar produces a
max_advance of 448 (7.0). Note that the advance width is integral but
now larger by 1 pixel per glyph (for monospace fonts).

Before the fix, these computations did not affect the font metrics for
layout because the base metrics were not changed. Now they are.

Just to be clear here: there is no way for an application to control
this outcome.

> > However, it could be argued that if the font designer was using
> > FreeType to proof the work, that the 'intention' was for the font to
> > look as it did before this fix.
> 
> Hmm.  A font designer who relies only on FreeType for proofing a font?

At first glance, perhaps that seems wrong, but some Linux distributions
are providing custom fonts specifically for the distribution. What else
would be the reference standard in this situation but FreeType?

My point here is not to argue for reverting this fix, but rather to
illustrate the impact at a higher level. Hopefully this collective
doesn't consider that to be immaterial.

Regards,
Peter Hurley