bug#39082: Inconsolata v3.000 has too wide spacing

[Robert Pluim]

>>>>> On Mon, 13 Jan 2020 17:43:14 +0100, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Mon, 13 Jan 2020 18:18:50 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >>> From: Robert Pluim <rpluim@gmail.com>
    >>> Cc: Andrea Greselin <greselin.andrea@gmail.com>,  39082@debbugs.gnu.org
    >>> Date: Mon, 13 Jan 2020 10:27:32 +0100
    >>> 
    Eli> So the question now becomes how come we get such a large value.  Looks
    Eli> like we somehow use the space-width value instead of the character
    Eli> glyph's width, not sure why.  I guess stepping through the code I've
    Eli> shown from xdisp.c is still necessary to understand this.
    >>> 
    >>> I can reproduce this, but I donʼt know how much effort we should spend
    >>> getting to the bottom of it: a Cairo-enabled build (ie !XFT) does not
    >>> have this problem.

    Eli> So I guess this is some kind of Xft bug?  In that case, I think it
    Eli> would be enough to describe the Cairo workaround in etc/PROBLEMS, and
    Eli> close the bug with that.

    Robert> Itʼs either a bug or a limitation in the Xft interface. I see the
    Robert> width of characters coming back from XftGlyphExtents as 26, with all
    Robert> the other metrics as 0, so I donʼt think thereʼs much we can do.

How about the following (assuming the Inconsolata or libXft devs donʼt
come up with an alternative API we can call).

** Under X, some characters are unexpectedly wide.

e.g. recent versions of Inconsolata show this issue for almost all of
its characters.  Due to either a limitation in the Xft interface used
by Emacs, or an Xft bug, the determination of the width of some
characters is incorrect.  Emacs built with Cairo enabled ("configure
--with-cairo") and the appropriate cairo development packages
installed does not have this issue.  See
<https://github.com/googlefonts/Inconsolata/issues/42> and
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-01/msg00456.html>
for more discussion.