[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Werner LEMBERG
Subject: bug#20628: 25.0.50; Incorrect line height for some fonts
Date: Sat, 23 May 2015 11:50:22 +0200 (CEST)

>> 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.  This
should be completely independent of the back-end.  The idea is that
font designers have a vital interest that a font rendered at, say,
10pt (more or less) fits other fonts drawn at 10pt, regardless what
the font metrics say.  An exception to that are math fonts, of course,
since those need a real two-dimensional layout instead of positioning
glyphs in lines.

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

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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]