After the upgrade of libfreetype6 from 2.6.3-3.2 to 2.8-0.2, there is
a blank line between characters. This has several consequences:

1. Tables look a bit ugly.

2. Windows (with the same number of text lines) are higher than before.

3. This breaks existing configurations. For instance, the xterms
   started at the beginning of my X session appear partly off-screen.

This issue appears with both xterm and emacs (at least), and is more
visible with xterm (but this might depend on the config).

I've attached two snapshots of xterm:
  ft263.png with libfreetype6 2.6.3-3.2 (correct)
  ft280.png with libfreetype6 2.8-0.2 (bad)

I'm increasing the severity because this is a visible change of
the behavior of the library that breaks the rendering in various
applications (at least xterm, GNU Emacs and GNOME Terminal), which
need to change their code. I suppose that there should have been a
proper transition, with a SONAME change.

According to the upstream bug, the way some values are rounded has
changed for the TrueType fonts, which seem to be the most common fonts
in Debian (apparently the default). In particular, one can now have
ascend + descend > height, which yields problems with xterm at least
(GNU Emacs and GNOME Terminal have a similar issue, so that I assume
that this may come from the same reason). That's a major change of
behavior since in such a case, it yields an additional line (a blank
line) between characters.

Upstream now recommends to use the values from the FT_Face structure
and scale them manually:
------------------------------------------------------------------------

Global size metrics values in the `FT_Size_Metrics' structure can be
different for TrueType fonts. Reason is that in older FreeType
versions the metrics were rounded differently to integer pixels
compared to all other font formats, yielding an inconsistent behaviour
if you used non-native hinting. Starting with this version, global
size metrics for TrueType fonts are handled the same as other font
formats: `ascender' gets rounded up, `descender' getsrounded down,
`height' gets normally rounded, and `max_advance' gets normally
rounded, too.

If you need more precise values of (global) ascender, descender,
height, or `max_advance', please take the corresponding values from
the `FT_Face' structure and scale them manually.

------------------------------------------------------------------------

Thanks for persisting on this bug. I've been affected by this as well in
terminator (vte-based) since the libfreetype6 update.

I can confirm this with Gnome Terminal, Terminator, and gvim.

I believe all of these use libfreetype6 via libpangoft2.

I scanned the upstream bug report. I don't really follow all the details
yet, but I guess a next step would be to identify packages that may be
affected by this change? So far that looks like Pango and Xft?

I'd be happy to help debug or test or whatever's needed to help resolve
this.

and possibly the applications themselves. In the case of xterm,
it uses the inaccurate, rounded "ascent" and "descent" values of
FT_Size_Metrics that are passed by FreeType via Xft (set up by
XftFontOpenPattern). Instead, the accurate values from FT_Face
should be used. [1] However, I don't know whether Xft provides
them in some way. They are not in the XftFont structure. [2]

[1] https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html
[2] https://linux.die.net/man/3/xft

I've reported bugs against xterm in Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880407

and GNU Emacs upstream:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29078

After testing xterm with FreeType 2.10.1, I couldn't see the extra
line gap reported.

While it is true that FreeType has slightly adjusted its computing
logic for global ascenders, descenders and height (particularly for
OpenType fonts), this issue seems to be fixed in xterm and xft.

Closing.

Control: reopen 866960

I haven't checked xterm (I'm using a version I've patched to avoid
the problem), but both rxvt and GNOME Terminal are still affected
by the window size issue and blank lines (for the blank lines, not
with the box-drawing characters as they have special code for that,
but this can be seen on multiline brackets, for instance).

With rxvt, this is even worse as this also affects the horizontal
size.

I've attached a screenshot concerning rxvt and multiline brackets.