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