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

[Peter Hurley]

On Wed, 2012-04-04 at 01:39 -0400, Werner LEMBERG wrote:
> > I'm referring to when the x-scale is forced to be an integer-multiple of
> > units/EM.
> 
> ???  This is not the case.

The description below is from a code trace in GDB. x_scale is
specifically recomputed in tt_size_reset() as:

   metrics->x_scale = FT_DivFix( metrics->x_ppem << 6,
                                 face->root.units_per_EM);

The effect of this line is that "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).
> 
> 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.

I tried to be as specific as possible wrt what FreeType actually does; I
can provide a GDB code trace of FT_Set_Char_Size() if that will help.

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

I understand that the old behavior was the result of a bug; I understand
that the specification says to use integer scaling when bit 3 is set
(that's why I included the link -- to help explain what I was referring
to).

> > 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 [...]

There is nothing artificial or contrived about this. 1 pixel per glyph
of wasted space is 132 pixels in a 132-char wide window. 2 windows
side-by-side = 264 pixels. That's valuable screen real-estate.

You can look at 
https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/966654

Of course, those images aren't meant to be convincing, just
illustrative. I can prepare more 'convincing' comparative images, but
realistically, that's going to be a waste of my time, don't you think?

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

Ok, but they're reverting this so that the designed font appears as they
intended.

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

Thanks for taking the time to appreciate my point-of-view. I too do not
see an alternative but to faithfully represent the specification.

Regards,
Peter Hurley