Subject: bug#20628: 25.0.50; Incorrect line height for some fonts

From: Werner LEMBERG <[email-masked]>
Date: Fri, 22 May 2015 23:49:59 +0200 (CEST)

>> Here is an hypothesis. When I open Latin Modern in FontForge, I see
>> two types of ascent and descent values: the ones in the "General"
>> tab are 806 and 194, and the ones in the OS/2 tab, in particular
>> Win Ascent and Win Descent, are 3560 and 3060.  Such a discrepancy
>> does not seem to exist in the few well-behaved fonts that I
>> checked.  Could it be that most applications use the first set of
>> values, but Emacs relies on the second?

Actually, there are *three* sets of font-wide ascender and descender
values in TrueType fonts:

  (1) From the `hhea' table: The `ascent' and `descent' fields,
      together with `linegap'.  Used by Apple, cf.

        https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6hhea.html

      These values are normally set by the font developer; there is no
      relation to the actual ascender and descender values of
      individual glyphs.

  (2) From the `OS/2' table: The `usWinAscent' and `usWinDescent'
      fields, for Windows.  Originally, those values are the ymax and
      ymin values from all characters in the Windows ANSI character
      set.  Today, however, it is often set to the ymax and ymin
      values of all glyphs in a font to avoid nasty clipping on (some?
      older?)  Windows applications.

  (3) From the `OS/2' table: The `sTypoAscender' and `sTypoDescender'
      fields, together with `sTypoLinegap'.  For Windows.  These
      values are normally set by the font developer; there is no
      relation to the actual ascender and descender values of
      individual glyphs.

Note that (1) and (3) are defined differently.  Mac fonts often miss
an `OS/2' table, making (2) and (3) unavailable.  Additionally, many
fonts have incompatible or erroneous values for any of the fields.
It's really a mess, unfortunately.

IMHO the bes solution is to completely ignore font-wide ascender and
descender values.  Instead, use the TeX approach: set the line gap to
the current size of the font, multiplied by a factor of 1.2 (and make
this configurable on a font-by-font basis in case it isn't already),
and increase the linegap if individual glyphs need it.

    Werner