No no no!  If in auto-hinter mode, it's neither a bug in FreeType nor a bug in xterm (or rather, a bug in Xft) – it's simply not possible to know that those characters should be stacked perfectly![*]  As mentioned earlier, the auto-hinter sometimes increases the vertical glyph dimension at small sizes to increase readability.  [A possible solution would be to check the (hinted) dimensions of block characters and adjust the vertical spacing accordingly.]

Only in native TrueType bytecode mode the user should round differently, because this is what the bytecode expects.  And due to the selection of hinting at `FT_Load_Glyph' time FreeType can't switch to the correct rounding mode in the FT_Size object.

[*] At least not currently.  There were some ideas to make the auto-hinter more aware of characters properties; for example, that the character `i' has a dot that must not be accidentally merged with the stem.  Similarly, there could be a property that ensures that the block characters' vertical dimensions exactly fit the global ascender and descender.

Box characters are special.  To make them work two assumptions must hold: (1) The rendering environment must use the line spacing as given in the font – systems like TeX ignore this.  (2) To avoid visible overlaps, the y values of the box elements must be aligned to the grid, exactly fitting the global ascender and descender values.

That ascender and descender values are rounded to integers (instead of using `ceil' and `floor', respectively) is an arbitrary choice of TrueType.  It would work equally well the other way.  In hindsight I believe that flooring and ceiling would even have been a better choice due to the infamous glyph cut-offs in Windows: It would allow for (slightly) increasing the glyphs vertically while hinting, providing more flexibility for small ppem values.

We round for historical reasons – I fully agree that it is a bad idea in general – the user should do it to fit the desired purpose –, but changing that would be backward incompatible.

If you don't do hinting, it would be appropriate to not round the advance width and not round the ascender and descender either.

Feel free to improve the documentation.

FreeType's values for `ascender' and `descender' in FT_Size are `all-inclusive'.  If you need something better – in particular for TTFs –, follow the advice given in commit 08e2e311.

I've already contacted the author of xterm (with CC to you), pointing to this bug report – hopefully, xterm can be fixed soon.  Please do the same for other programs where you notice bad behaviour.

It was properly announced in the CHANGES file!

And no, it's neither an ABI nor API change, because the new code corrects the metrics for TTFs in all other hinting modes (i.e., unhinted and auto-hinted).  The old FreeType behaviour was essentially a bug, which (more or less accidentally) did the right thing for TTFs with native bytecode hinting.

You can call it a design problem of FreeType's API that hinting can be freely selected at glyph loading time.  [In hindsight, it would have been better to select the hinting mode while creating the size object.]  However, to make this late hinting mode selection universally work for all font formats, the global size metrics must be derived independently of the hinting mode – I thus had to sacrifice the special handling of natively hinted TTFs.

I've just improved the documentation in git.

Regarding comment #8: In your GNOME snapshots, you are definitely using native v35 TrueType hinting in your 2.6.1 image!  And you are definitely using native v40 TrueType hinting in your 2.8 image.  No slight hinting at all...

Use a magnifier and compare with the attached image created with the `ftdiff' demo program (from current git).

On a different machine (my desktop machine, which shows the same issues), I've rebuilt xterm with --enable-trace to get debugging information and compare the traces obtained with FreeType 2.6.3 and 2.8.0. Concerning the differences for the fonts, I get:

 xtermComputeFontInfo font 0: norm(face DejaVu Sans Mono:10, size 14.0)
 ...matched normal font
 ...matched bold font
 ...matched italic font
-Xft metrics screen->renderFontNorm[0] = 20 (16,4) advance 10, actual 10
-Xft metrics screen->renderFontBold[0] = 20 (16,4) advance 10, actual 10
-Xft metrics screen->renderFontItal[0] = 20 (16,4) advance 10, actual 10
+Xft metrics screen->renderFontNorm[0] = 20 (16,5)* advance 10, actual 10
+Xft metrics screen->renderFontBold[0] = 20 (16,5)* advance 10, actual 10
+Xft metrics screen->renderFontItal[0] = 20 (16,5)* advance 10, actual 10
 xtermComputeFontInfo wide(face <null>, char_width 20)
-setRenderFontsize result 10x20 (16+4)
+...increase height from 20
+setRenderFontsize result 10x21 (16+5)
+...increase height from 20
 setRenderFontsize bold unchanged
+...increase height from 20
 setRenderFontsize ital unchanged
-...packed TrueType font 20x10 vs 10
-xtermComputeFontInfo window 20x10 (full 24x23), fontsize 20x10 (asc 16, dsc 4)
+...packed TrueType font 21x10 vs 10
+xtermComputeFontInfo window 21x10 (full 25x23), fontsize 21x10 (asc 16, dsc 5)
[...]

The later differences seem to be a consequence of that. Concerning the "Xft metrics" lines, they are output by:

#define CACHE_XFT(dst,src) if (src != 0) {\
            checkXft(xw, &(dst[fontnum]), src);\
            TRACE(("Xft metrics %s[%d] = %d (%d,%d)%s advance %d, actual %d%s\n",\
                #dst,\
                fontnum,\
                src->height,\
                src->ascent,\
                src->descent,\
                ((src->ascent + src->descent) > src->height ? "*" : ""),\
                src->max_advance_width,\
                dst[fontnum].map.min_width,\
                dst[fontnum].map.mixed ? " mixed" : ""));\
        }

So, that's the "descent" that is modified.

And the fact that (src->ascent + src->descent) > src->height with FreeType 2.8.0 possibly yields the issues.

If the FREETYPE_PROPERTIES environment variable doesn't make a difference, then the machine with FreeType 2.8 (assuming a normal build of the library) uses the auto-hinter, at least for the `DejaVu Sans Mono' font.  You should check your fontconfig settings and switch to `full' hinting.  And just to be sure you should also check whether your DejaVu fonts are identical.

I'm at the end of my wit.  Please contact the xterm people so that they can help you debug the issue.  I suspect an incorrect rounding somewhere – most likely in xterm, but it can also be a bug in FreeType.  However, since I have no idea how xterm works, I can't further help.

`Monospace Regular 10' is an alias.  Please try to find out what font this really is (for example, using the `fc-list' program) so that I can check the font's built-in line height values.  What dpi value are you using?

Additionally, your 2.6.3 Gnome snapshot obviously uses native TrueType hinting (perhaps v35), while the 2.8.0 snapshot uses either native v40 hinting or auto-hinting – if you magnify the image you can see that it is fuzzier along the x axis.  If the latter is true (which I believe), chances are very high that vertical scaling is different.

You can activate v35 hinting with setting an environment variable (provided your system is set up to use native TrueType hinting).

  FREETYPE_PROPERTIES=truetype:interpreter-version=35

In general, there is no reliable way for non-bitmap fonts to get `correct' vertical spacing.  There are too many ways to define `correct', unfortunately.  For example, TeX uses 1.2*em size as the line height by default, ignoring the fonts' line height values altogether.

I think that you have to adjust the vertical spacing manually to get block characters line up correctly.  KDE's `konsole' application allows this, but gnome doesn't, it seems.  BTW, xterm allows this also, cf.

  https://wiki.archlinux.org/index.php/Xterm#Adjust_line_spacing

AFAIK, there are no such problems with applications that are based on Qt or Pango, for example KDE or Gnome – can you verify that?

It seems that xft is causing the differences you are noticing; cf. https://savannah.nongnu.org/bugs/?52124 for a similar report.

Alas, xft is largely unmaintained, AFAIK, but maybe you get an answer or advice if you write to the xorg people.

You might also try to compile FreeType with AF_CONFIG_OPTION_TT_SIZE_METRICS; maybe it fixes your issues.

Try using a slightly smaller, fractional point size for your terminal font, e.g., 12.8pt instead of 13pt.