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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Werner LEMBERG <wl <at> gnu.org>
Cc: 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:31:16 +0300

> Date: Sat, 23 May 2015 11:50:22 +0200 (CEST)
> Cc: clement.pitclaudel <at> live.com, ohwoeowho <at> gmail.com, 20628 <at> debbugs.gnu.org
> From: Werner LEMBERG <wl <at> gnu.org>
> 
> 
> >> 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.
> > 
> > Could you perhaps look at the Emacs sources and suggest how to
> > change the *_open functions in the *font.c back-ends, to do what you
> > suggest above?  Or at least tell how to get "the current size of the
> > font" from the back-ends we use, which are Freetype, Fontconfig, and
> > XLib's XLoadQueryFont?  The relevant source files are xfont.c,
> > ftfont.c, and xftfont.c.
> 
> Sorry, no time.  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.

> > Also, how to know from the glyph metrics, in their Emacs
> > incarnation, that an individual glyph needs an increase of the
> > vertical space?
> 
> Again no time to check this, sorry.  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 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.

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

> PS: If you want it especially nifty, implement a skyline algorithm to
>     check whether the ascender of the glyph at a given horizontal
>     position collides with the descender of the glyph(s) at the same
>     horizontal position one line above.

This again goes back to the question how to access the ascender of a
glyph.

Thanks.

Previous Next

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