GNU bug report logs - #39082
Inconsolata v3.000 has too wide spacing

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: greselin.andrea <at> gmail.com, 39082 <at> debbugs.gnu.org
Subject: bug#39082: Inconsolata v3.000 has too wide spacing
Date: Mon, 13 Jan 2020 17:43:14 +0100

>>>>> On Mon, 13 Jan 2020 18:18:50 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: Andrea Greselin <greselin.andrea <at> gmail.com>,  39082 <at> 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.

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

Andrea, does building emacs-27 configure '--with-cairo' fix this for
you?

Robert

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.