bug#22699: 25.0.91; Accented characters truncated with DejaVu Sans Mono

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 23 Feb 2016 01:54:19 +0100 (CET)
> Cc: andrewjmoreton@gmail.com, 22699@debbugs.gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> >> With DejaVu Sans Mono (version 2.35), accented characters are not
> >> displayed properly at some sizes, and appear truncated at the top
> >> (as if a pixel row is missing).
> >> 
> >> For example, LATIN SMALL LETTER A WITH RING ABOVE "å"
> >> 
> >> Displays properly
> >> -----------------
> >> In Windows font dialog, choose "Deja Vu Sans Mono", "Bold", "9"
> >> 
> >> `describe-char' shows the font as:
> >> uniscribe:-outline-DejaVu Sans 
> >> Mono-bold-normal-normal-mono-12-*-*-*-c-*-iso8859-1 (#xA7)
> >> 
> >> Top of ring is clipped
> >> ----------------------
> >> In Windows font dialog, choose "Deja Vu Sans Mono", "Book", "9"
> >> 
> >> `describe-char' shows the font as:
> >> uniscribe:-outline-DejaVu Sans Mono-normal-normal-normal-mono-12-*-*-*-c-*-=
> >> iso8859-1 (#xA7)
> >> 
> >> This only appears with DejaVu Sans Mono version 2.35 at this size,
> >> with the "Book" or "Oblique" font styles (larger or smaller sizes
> >> display properly).
> > 
> > Thanks.  I wonder how to make sure this is an Emacs problem and not
> > a problem with the font.
> 
> Here's my educated guess as a font specialist, but without any clue
> how Emacs font rendering is handled on MS Windows.
> 
> AFAICS, this is a problem with the Windows GDI library, which only
> renders glyph data in the vertical range between `usWinAscent' and
> `usWinDescent'.  These two parameters are set in a TrueType font's
> `OS/2' table; they are used to define the default spacing between text
> baselines for a particular font.

Emacs uses Uniscribe if possible (and it is in this case), not GDI
directly.

I indeed confirm that the problem exists in version 2.35 of the font,
but not in an earlier version I had before that (2.19?).  So perhaps a
bug report to the DejaVu fonts is in order.

> The only solution to reliably avoid this issue is to use the
> DirectWrite library, as far as I know.

Does MS-Word on Windows 8.1 use DirectWrite?  Because it, too, suffers
from the same problem with this font and size, when displaying that
character.