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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39082 in the body.
You can then email your comments to 39082 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Greselin <greselin.andrea <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Inconsolata v3.000 has too wide spacing
Date: Sat, 11 Jan 2020 11:03:39 +0100

[Message part 1 (text/plain, inline)]

Hello, after upgrading to Inconsolata v3.000 letter-spacing for that
typeface
has become too wide, as shown in the attached screenshot. It shows the Emacs
frame I get on running `emacs -Q`.

Note that the font works correctly in other applications such as Gedit and
LibreOffice.

For reference, here are the reports I've made at Red Hat's Bugzilla and
Inconsolata's GitHub page for the same bug:
 - https://bugzilla.redhat.com/show_bug.cgi?id=1786054
 - https://github.com/googlefonts/Inconsolata/issues/42

According to reports at Inconsolata's GitHub page this happens in Emacs
versions
26.2, 26.3 and 27.0.50.

Best regards,
Andrea

System info (from `report-emacs-bug`):
In GNU Emacs 26.3 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.13)
 of 2019-12-10 built on buildhw-07.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.12006000
System Description: Fedora release 31 (Thirty One)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules
 build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu
 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
 -fstack-protector-strong -grecord-gcc-switches
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS GLIB NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LCMS2

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
xwidget-internal move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 95564 5838)
 (symbols 48 20421 1)
 (miscs 40 113 104)
 (strings 32 28619 1327)
 (string-bytes 1 758954)
 (vectors 16 14042)
 (vector-slots 8 503588 7662)
 (floats 8 49 68)
 (intervals 56 288 0)
 (buffers 992 12))

[Message part 2 (text/html, inline)]

[screenshot-inconsolata.png (image/png, attachment)]

Message #8 received at 39082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Greselin <greselin.andrea <at> gmail.com>
Cc: 39082 <at> debbugs.gnu.org
Subject: Re: bug#39082: Inconsolata v3.000 has too wide spacing
Date: Sun, 12 Jan 2020 17:37:58 +0200

> From: Andrea Greselin <greselin.andrea <at> gmail.com>
> Date: Sat, 11 Jan 2020 11:03:39 +0100
> 
> Hello, after upgrading to Inconsolata v3.000 letter-spacing for that typeface
> has become too wide, as shown in the attached screenshot. It shows the Emacs
> frame I get on running `emacs -Q`.
> 
> Note that the font works correctly in other applications such as Gedit and
> LibreOffice.
> 
> For reference, here are the reports I've made at Red Hat's Bugzilla and
> Inconsolata's GitHub page for the same bug:
>  - https://bugzilla.redhat.com/show_bug.cgi?id=1786054
>  - https://github.com/googlefonts/Inconsolata/issues/42
> 
> According to reports at Inconsolata's GitHub page this happens in Emacs versions
> 26.2, 26.3 and 27.0.50.

As indicated in
https://github.com/googlefonts/Inconsolata/issues/42#issuecomment-573409054,
the information returned by font-info for this font on Fedora is:

  ["-CYRE-Inconsolata-normal-normal-normal-*-19-*-*-*-m-0-iso10646-1" "Inconsolata:pixelsize=19:foundry=CYRE:weight=normal:slant=normal:width=normal:spacing=100:scalable=true" 19 21 0 0 0 29 17 4 29 29 "/usr/share/fonts/levien-inconsolata/Inconsolata-Regular.ttf" (opentype ((DFLT ...) (latn ... ... ... ... ... ... ... ... ...)) (DFLT (nil mark mkmk)) (latn (nil mark mkmk) (AZE\ mark mkmk) (CAT\ mark mkmk) (CRT\ mark mkmk) (KAZ\ mark mkmk) (MOL\ mark mkmk) (ROM\ mark mkmk) (TAT\ mark mkmk) (TRK\ mark mkmk)))]

and I think the "scalable=true" part is the problem.  AFAIK, it isn't
supposed to be there, since the average width is reported as non-zero
for this font.  But that's just a wild guess.  I guess it comes from
Fontconfig.

Sadly, I have no idea how to go about investigating this problem
further, maybe someone else does?

FWIW, this problem doesn't happen on MS-Windows with the same font.

Message #11 received at 39082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: greselin.andrea <at> gmail.com
Cc: 39082 <at> debbugs.gnu.org
Subject: Re: bug#39082: Inconsolata v3.000 has too wide spacing
Date: Sun, 12 Jan 2020 18:56:08 +0200

> Date: Sun, 12 Jan 2020 17:37:58 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 39082 <at> debbugs.gnu.org
> 
> Sadly, I have no idea how to go about investigating this problem
> further, maybe someone else does?

One idea is to look at the character glyph metric we get from the font
here:

  if (it->what == IT_CHARACTER)
    {
      unsigned char2b;
      struct face *face = FACE_FROM_ID (it->f, it->face_id);
      struct font *font = face->font;
      struct font_metrics *pcm = NULL;
      int boff;			/* Baseline offset.  */
    [...]
	  if (get_char_glyph_code (it->char_to_display, font, &char2b))
	    {
	      pcm = get_per_char_metric (font, &char2b);
	      if (pcm->width == 0
		  && pcm->rbearing == 0 && pcm->lbearing == 0)
		pcm = NULL;
	    }

(this is from xdisp.c), and then find the culprit, probably
pcm->width, and go back to where we get these values from the font
back-end.

I cannot myself do this, as I don't have access to a system where this
problem happens.

Message #14 received at 39082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: greselin.andrea <at> gmail.com
Cc: 39082 <at> debbugs.gnu.org
Subject: Re: bug#39082: Inconsolata v3.000 has too wide spacing
Date: Sun, 12 Jan 2020 19:52:40 +0200

> Date: Sun, 12 Jan 2020 18:56:08 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 39082 <at> debbugs.gnu.org
> 
> > Date: Sun, 12 Jan 2020 17:37:58 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 39082 <at> debbugs.gnu.org
> > 
> > Sadly, I have no idea how to go about investigating this problem
> > further, maybe someone else does?
> 
> One idea is to look at the character glyph metric we get from the font
> here:

An easier way to get at the character glyph metrics is like this:

  M-: (font-get-glyphs (font-at 1) 1 2) RET

This should show the glyph metrics of the font glyph used to display
the character at buffer position 1.  (Change 1 to any other buffer
position to report on a character there, and then change 2 to 1 more
than that position, for example 100 and 101 for the character at
buffer position 100.)

I'm mostly interested in the WIDTH element (the 5th element) of the
result, but maybe others will also show something important.  It would
be also interesting to compare this with a font that is displayed
"normally".

Thanks.

Message #17 received at 39082 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Greselin <greselin.andrea <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39082 <at> debbugs.gnu.org
Subject: Re: bug#39082: Inconsolata v3.000 has too wide spacing
Date: Sun, 12 Jan 2020 19:17:38 +0100

[Message part 1 (text/plain, inline)]

> An easier way to get at the character glyph metrics is like this:
>
>   M-: (font-get-glyphs (font-at 1) 1 2) RET

Having launched Emacs with `emacs -Q -fn Inconsolata-12` I get

  [[0 0 59 541 29 2 7 9 4 nil]]

> It would be also interesting to compare this with a font that is
> displayed "normally".

With `emacs -Q -fn "DejaVu Sans Mono-12"` (which displays correctly)
the output is

  [[0 0 59 30 11 3 8 10 3 nil]]

I've run both test on a scratch buffer showing its message, so they
should be referring to the character ";". `(font-get-glyphs (font-at
1) 100 101)` returns

  [[0 0 116 415 29 0 10 12 0 nil]]

with Inconsolata and

  [[0 0 116 87 11 0 11 14 0 nil]]

with DejaVu.

The fourth values look rather off, and the fifth too.

Andrea

On Sun, 12 Jan 2020 at 18:52, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sun, 12 Jan 2020 18:56:08 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 39082 <at> debbugs.gnu.org
> >
> > > Date: Sun, 12 Jan 2020 17:37:58 +0200
> > > From: Eli Zaretskii <eliz <at> gnu.org>
> > > Cc: 39082 <at> debbugs.gnu.org
> > >
> > > Sadly, I have no idea how to go about investigating this problem
> > > further, maybe someone else does?
> >
> > One idea is to look at the character glyph metric we get from the font
> > here:
>
> An easier way to get at the character glyph metrics is like this:
>
>   M-: (font-get-glyphs (font-at 1) 1 2) RET
>
> This should show the glyph metrics of the font glyph used to display
> the character at buffer position 1.  (Change 1 to any other buffer
> position to report on a character there, and then change 2 to 1 more
> than that position, for example 100 and 101 for the character at
> buffer position 100.)
>
> I'm mostly interested in the WIDTH element (the 5th element) of the
> result, but maybe others will also show something important.  It would
> be also interesting to compare this with a font that is displayed
> "normally".
>
> Thanks.
>

[Message part 2 (text/html, inline)]

Message #20 received at 39082 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Greselin <greselin.andrea <at> gmail.com>
Cc: 39082 <at> debbugs.gnu.org
Subject: Re: bug#39082: Inconsolata v3.000 has too wide spacing
Date: Sun, 12 Jan 2020 20:44:08 +0200

> From: Andrea Greselin <greselin.andrea <at> gmail.com>
> Date: Sun, 12 Jan 2020 19:17:38 +0100
> Cc: 39082 <at> debbugs.gnu.org
> 
> >   M-: (font-get-glyphs (font-at 1) 1 2) RET
> 
> Having launched Emacs with `emacs -Q -fn Inconsolata-12` I get
> 
>   [[0 0 59 541 29 2 7 9 4 nil]]
> 
> > It would be also interesting to compare this with a font that is
> > displayed "normally".
> 
> With `emacs -Q -fn "DejaVu Sans Mono-12"` (which displays correctly)
> the output is
> 
>   [[0 0 59 30 11 3 8 10 3 nil]]
> 
> I've run both test on a scratch buffer showing its message, so they
> should be referring to the character ";". `(font-get-glyphs (font-at
> 1) 100 101)` returns
> 
>   [[0 0 116 415 29 0 10 12 0 nil]]
> 
> with Inconsolata and
> 
>   [[0 0 116 87 11 0 11 14 0 nil]]
> 
> with DejaVu.
> 
> The fourth values look rather off, and the fifth too.

The 4th value is unimportant: it's the font's glyph index for that
character's glyph.  The 5th element is the problem: it's what we use
for the glyph.  29 is way too large, about 2.5 times too large.

So the question now becomes how come we get such a large value.  Looks
like we somehow use the space-width value instead of the character
glyph's width, not sure why.  I guess stepping through the code I've
shown from xdisp.c is still necessary to understand this.

Message #23 received at 39082 <at> debbugs.gnu.org (full text, mbox):

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

>>>>> On Sun, 12 Jan 2020 20:44:08 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    Eli> The 4th value is unimportant: it's the font's glyph index for that
    Eli> character's glyph.  The 5th element is the problem: it's what we use
    Eli> for the glyph.  29 is way too large, about 2.5 times too large.

    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.

Robert

Message #26 received at 39082 <at> debbugs.gnu.org (full text, mbox):

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

> 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.

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

Thanks.

Message #29 received at 39082 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #32 received at 39082 <at> debbugs.gnu.org (full text, mbox):

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

[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)]

Message #35 received at 39082 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#39082: Inconsolata v3.000 has too wide spacing
Date: Mon, 13 Jan 2020 18:03:37 +0100

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

>>>>> 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.

    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.

Message #38 received at 39082 <at> debbugs.gnu.org (full text, mbox):

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

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: greselin.andrea <at> gmail.com,  39082 <at> debbugs.gnu.org
> Date: Mon, 13 Jan 2020 18:03:37 +0100
> 
> ** 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.

OK, but please inject something like "a workaround is to ..." into
this text.  Like "A workaround is to build Emacs with Cairo enabled,
as this configuration doesn't have such problems."

Message #43 received at 39082-done <at> debbugs.gnu.org (full text, mbox):

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

>>>>> On Mon, 13 Jan 2020 19:26:41 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: greselin.andrea <at> gmail.com,  39082 <at> debbugs.gnu.org
    >> Date: Mon, 13 Jan 2020 18:03:37 +0100
    >> 
    >> ** 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.

    Eli> OK, but please inject something like "a workaround is to ..." into
    Eli> this text.  Like "A workaround is to build Emacs with Cairo enabled,
    Eli> as this configuration doesn't have such problems."

OK. Pushed to emacs-27, closing the bug.

Previous Next

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