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

Previous Next

Full log

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

From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Oleh Krehel <ohwoeowho <at> gmail.com>
Cc: 20628 <at> debbugs.gnu.org
Subject: Re: bug#20628: 25.0.50; Incorrect line height for some fonts
Date: Fri, 22 May 2015 14:57:01 -0400

On 05/22/2015 02:15 PM, Eli Zaretskii wrote:
>> From: Oleh Krehel <ohwoeowho <at> gmail.com>
>> Cc: clement.pitclaudel <at> live.com,  20628 <at> debbugs.gnu.org
>> Date: Fri, 22 May 2015 18:33:43 +0200
>>
>>> Math fonts are notorious for requesting huge ascent and descent
>>> values.  I always disable them using fontsets.
>>
> 
> It would be nice if someone could look at gedit sources and describe
> what it does to avoid the problem.  Finding such a solution is what
> this discussion is all about, no?

I don't know much about gedit's source code, nor how fonts are handled. However, I'm not sure if gedit can really give us much information: indeed, Emacs is the only application that behaves this way on my system. LibreOffice and Thunderbird, for example, display these characters fine.

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?

Clément.

Previous Next

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