GNU bug report logs - #20628
25.0.50; Incorrect line height for some fonts

Previous Next

Full log

Message #203 received at 20628 <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit--Claudel
 <clement.pitclaudel <at> live.com>
To: Werner LEMBERG <wl <at> gnu.org>, eliz <at> gnu.org
Cc: ohwoeowho <at> gmail.com, 20628 <at> debbugs.gnu.org
Subject: Re: bug#20628: 25.0.50; Incorrect line height for some fonts
Date: Sun, 24 May 2015 04:20:32 -0400

On 05/22/2015 05:49 PM, Werner LEMBERG wrote:
> 
>>> 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.

Thanks for this detailed description! 

I looked a bit more into how other programs handle this, and it seems that they take the simple approach of relying on font-wide metrics. Only, they don't seem to use the same ones as Emacs. This causes LibreOffice and vim-gtk to display "∫" as slightly truncated when using Latin Modern Math (it's taller than the line height). Emacs on the other hand displays it fine (at the cost of having a huge line height.

I wonder if changing the set of metrics used in Emacs would be easy.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.