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 344-1
Control: found -1 345-1

Things have changed again with FreeType 2.9 (libfreetype6 2.9.1-3).
I now get with "DejaVu Sans Mono" and size 10 (-fs 10):

Xft metrics screen->renderFontNorm[0] = 21 (18,5)* advance 11, actual 11
Xft metrics screen->renderFontBold[0] = 21 (18,5)* advance 11, actual 11
Xft metrics screen->renderFontItal[0] = 21 (18,5)* advance 11, actual 11

(it was "20 (16,5)* advance 10, actual 10" with FT 2.8), but the issue
is the same (if not worse).

With size 11 (-fs 11):

Xft metrics screen->renderFontNorm[0] = 23 (19,5)* advance 12, actual 12
Xft metrics screen->renderFontBold[0] = 23 (19,5)* advance 12, actual 12
Xft metrics screen->renderFontItal[0] = 23 (19,5)* advance 12, actual 12

With size 12 (-fs 12):

Xft metrics screen->renderFontNorm[0] = 26 (21,6)* advance 13, actual 13
Xft metrics screen->renderFontBold[0] = 26 (21,6)* advance 13, actual 13
Xft metrics screen->renderFontItal[0] = 26 (21,6)* advance 13, actual 13

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.

Note that even with size 12, I need to decrease both ascent and descent
to avoid blank lines.

With this patch, I get the same behavior (window height and rendering)
as with the old FreeType 2.6 in sizes 10 and 12. For size 11, I have
the choice between
  - decreasing either ascent or descent, which slightly increases the
    window height compared to FreeType 2.6 (I get slight blank lines,
    but there was the same issue with FreeType 2.6 with this size),
  - decreasing both, which completely solves the blank line issue,
    but one may find text lines a bit too close to each other. This
    may be a matter of taste, though.

I haven't found any drawback, but I haven't tested other fonts. Note,
however, that the behavior is changed only in the "inconsistent" case
height < ascent + descent.

Perhaps there should be an option about such adjustments...

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

Index: xterm-345/fontutils.c
===================================================================
--- xterm-345.orig/fontutils.c
+++ xterm-345/fontutils.c
@@ -2839,8 +2839,10 @@ setRenderFontsize(XtermWidget xw, VTwin
 	ascent = font->ascent;
 	descent = font->descent;
 	if (height < ascent + descent) {
-	    TRACE(("...increase height from %d to %d\n", height, ascent + descent));
-	    height = ascent + descent;
+	    ascent = --font->ascent;
+	    descent = --font->descent;
+	    height = font->height = ascent + descent;
+	    TRACE(("...(ascent,descent,height) decreased to (%d,%d,%d)\n", ascent, descent, height));
 	}
 	if (is_double_width_font_xft(screen->display, font)) {
 	    TRACE(("...reduce width from %d to %d\n", width, width >> 1));