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

Previous Next

Full log

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

From: Werner LEMBERG <wl <at> gnu.org>
To: eliz <at> gnu.org
Cc: handa <at> gnu.org, clement.pitclaudel <at> live.com, ohwoeowho <at> gmail.com,
 20628 <at> debbugs.gnu.org
Subject: Re: bug#20628: 25.0.50; Incorrect line height for some fonts
Date: Sat, 23 May 2015 13:45:09 +0200 (CEST)

>> However, with `current size' I mean the pixels per EM value
>> computed in the standard way:
>>
>>   ppem = size * DPI / 72
>>
>> where `size' is given in points and `DPI' the screen resolution.
>
> I guess you mean font->pixel_size, something we have already.

Sounds right.

>> Assuming that Emacs somehow provides the maximum descender of the
>> glyphs in the previous line together with a linegap value, simply
>> check that the maximum ascender of the glyphs in the current line
>> doesn't collide, shifting the line downwards if necessary.  AFAIK,
>> Emacs does this already.
>
> Emacs indeed does that already, but it uses the font's ascent and
> descent values, not values specific to each glyph.

I suggest to change that, not relying on the font's ascent and descent
value, but deriving this value from the font size instead.

> I was under the impression that you said we could access and use the
> ascent/descent values of each glyph in a font, and I was asking how
> to do that, i.e. which metrics express these per-glyph values.

Well, a quick search for FreeType functions brings me to function
`ftfont_text_extents', which fills `font_metrics' structures for
individual glyphs.  So I guess the answer are the fields `ascent' and
`descent' of Emacs's `font_metrics' structure.

>> As a corollary, the only question is how to compute a proper
>> default linegap value without relying on quirks caused by
>> incompatible font formats and font metric data.
>
> What do you mean by "linegap"?  the vertical gap between two screen
> lines in Emacs is the sum of the line height, computed as a sum of
> its max_ascent and max_descent values, plus the value of
> line-spacing.

Yes, I've meant the baseline-to-baseline distance.  Sorry for the
confusion.


    Werner

Previous Next

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