Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

[Vincent Lefevre <vincent@vinc17.net>]

Control: found -1 347-1
Control: tags -1 patch

Patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880407#100

On 2019-05-20 15:54:42 +0200, Vincent Lefevre wrote:
> The attached patch, which decreasing both ascent and descent by 1 when
> height < ascent + descent, avoids this font height issue. I'm not sure
> about the "height = font->height = ascent + descent;" line; it doesn't
> seem to have any effect.

Tagging patch, even though one may want to add configurability to
decide what to do in the "height < ascent + descent" case.

This is a bit like scaleHeight should do, but:
  * The new Xft behavior is now opposite as described (for a past
    behavior): instead of causing glyphs to be scaled larger than
    the bounding boxes, the bounding boxes are now increased by
    xterm (in order to match ascent + descent) while the size of
    the glyphs has remained the same, which makes windows taller
    than needed (thus wasting valuable space on the screen) and
    introduces blank lines between line-drawing characters.
  * The scaleHeight feature does not work well with this opposite
    Xft behavior, e.g. instead of removing a blank line, it removes
    some other horizontal line from the glyph.
  * The new Xft behavior is a rounding issue: one or two values have
    been rounded away from zero instead of toward zero. Thus the
    difference with the old behavior is something like 1 or 2 pixels
    (along a vertical). So, the configuration value, if any, should
    not be a scaling factor, but a value in pixels.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)