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

[Peter Hurley]

Werner LEMBERG wrote:
> > We had report of regression in GTK markups rendering in Ubuntu
> > precise, (i.e <u>label</u> would render underlined), [...]
> >
> > We have reverted that commit in Ubuntu for now to workaround the
> > issue but I would like to know how to determine if that's a bug in
> > freetype or if other part of the stack (i.e gtk) would need to be
> > updated to deal with the new freetype?
> 
> AFAIK, the problem is in gtk.  For years, FreeType had this metrics
> bug, and unfortunately the users got used to the appearance of far too
> widely spaced lines.  What FreeType now returns is what the font
> designer has had in mind while designing the font, and what can be
> found in the font.
> 
> As has been stated in one of the Debian bug report comments, the
> amount of the vertical line spacing is something which *must* be
> configurable or explicitly set by the application.  Additionally, the
> underlying graphical library should provide a better default in case
> the font value is not satisfying (for whatever reason), for example,
> by multiplying the vertical distances by a fixed amount.  Just think
> of TeX which ignores a font's line spacing values completely,
> providing its own default (1.2 * design size).
> 
> Until someone can prove that the patch is incorrect, I won't change it
> back.  Simply reverting it, as done by some distributions, is *not*
> the correct solution IMHO, since it hides the problem of gtk.

Hi Werner,

Let me apologize if this reply is not properly threaded. I had to thread
it manually.

Although I have no interest in proving the patch is incorrect, I do have
some relevant comments which may shed additional light on the
complications introduced by "fixing" this bug.

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

One outcome of integer scaling the metrics is that monospace fonts have
'excessive' space between glyphs. Unlike vertical line spacing, there is
no way to directly control the max_advance metric value from the
application layer -- only the font stack has access to this value.

Integer scaling *may* have been the font designer's requirement.
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.

Regards,
Peter Hurley