GNU bug report logs -
#39082
Inconsolata v3.000 has too wide spacing
Previous Next
Full log
Message #32 received at 39082 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've never built Emacs before (nor any other non-trivial program for that
matter). If you can instruct me on doing that I will try, otherwise I don't
have time to learn by myself now, I'm sorry.
Andrea
On Mon, 13 Jan 2020 at 17:43, Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> 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
>
[Message part 2 (text/html, inline)]
This bug report was last modified 5 years and 129 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.