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

[Werner LEMBERG]

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

???  This is not the case.

> 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).

Hmm.  You are probably talking about the pixel size, right?  The
formula to convert from points to pixels (per EM) is

  ppem = pt * dpi / 72

and this resulting ppem value must be an integer if bit 3 is set.  So
while you can request a non-integer value in `FT_Set_Char_Size', you
can only request integer values in `FT_Set_Pixel_Sizes'.  Of course,
if you are using a resolution of 72dpi, the character size equals the
pixel size.

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

Yes.  If you look into 

  http://www.microsoft.com/typography/otspec/head.htm

it explicitly says

  Bit 3: Force ppem to integer values for all internal scaler math;
         may use fractional ppem sizes if this bit is clear;

which is a better description than in the Apple specification.  The
old behaviour in FreeType was a bug.

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

Yes.  BTW, can you provide images for your worst-case scenario?
Honestly spoken, it sounds quite artificial, since TrueType bytecode
instructions normally adjust a glyph's advance width to the right
value.  You might also read the following three FreeType bug reports:

  https://savannah.nongnu.org/bugs/?34156
  https://savannah.nongnu.org/bugs/?34507
  https://savannah.nongnu.org/bugs/?33939

>> 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?

Too much honour, really!  You are thinking of the Ubuntu font family,
right?  AFAIK, its developer, Dalton Maag, is exclusively using
Microsoft's Visual TrueType tool (VTT) for hinting since there is
nothing comparable to this program...

It's always the goal that FreeType yields similar results to the
Microsoft rasterizer.  Everything else would be simply insane.

> My point here is not to argue for reverting this fix, but rather to
> illustrate the impact at a higher level.

I fully understand your concerns, and its unfortunate that many
applications are affected unexpectedly, but I don't see an alternative
to fulfilling the OpenType specification.


    Werner