* bug#39082: Inconsolata v3.000 has too wide spacing
@ 2020-01-11 10:03 Andrea Greselin
2020-01-12 15:37 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Andrea Greselin @ 2020-01-11 10:03 UTC (permalink / raw)
To: 39082
[-- Attachment #1.1: Type: text/plain, Size: 4652 bytes --]
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))
[-- Attachment #1.2: Type: text/html, Size: 5304 bytes --]
[-- Attachment #2: screenshot-inconsolata.png --]
[-- Type: image/png, Size: 55750 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-11 10:03 bug#39082: Inconsolata v3.000 has too wide spacing Andrea Greselin
@ 2020-01-12 15:37 ` Eli Zaretskii
2020-01-12 16:56 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2020-01-12 15:37 UTC (permalink / raw)
To: Andrea Greselin; +Cc: 39082
> From: Andrea Greselin <greselin.andrea@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-12 15:37 ` Eli Zaretskii
@ 2020-01-12 16:56 ` Eli Zaretskii
2020-01-12 17:52 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2020-01-12 16:56 UTC (permalink / raw)
To: greselin.andrea; +Cc: 39082
> Date: Sun, 12 Jan 2020 17:37:58 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 39082@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.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-12 16:56 ` Eli Zaretskii
@ 2020-01-12 17:52 ` Eli Zaretskii
2020-01-12 18:17 ` Andrea Greselin
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2020-01-12 17:52 UTC (permalink / raw)
To: greselin.andrea; +Cc: 39082
> Date: Sun, 12 Jan 2020 18:56:08 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 39082@debbugs.gnu.org
>
> > Date: Sun, 12 Jan 2020 17:37:58 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 39082@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-12 17:52 ` Eli Zaretskii
@ 2020-01-12 18:17 ` Andrea Greselin
2020-01-12 18:44 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Andrea Greselin @ 2020-01-12 18:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 39082
[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]
> 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@gnu.org> wrote:
> > Date: Sun, 12 Jan 2020 18:56:08 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 39082@debbugs.gnu.org
> >
> > > Date: Sun, 12 Jan 2020 17:37:58 +0200
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > Cc: 39082@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.
>
[-- Attachment #2: Type: text/html, Size: 2736 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-12 18:17 ` Andrea Greselin
@ 2020-01-12 18:44 ` Eli Zaretskii
2020-01-13 9:27 ` Robert Pluim
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2020-01-12 18:44 UTC (permalink / raw)
To: Andrea Greselin; +Cc: 39082
> From: Andrea Greselin <greselin.andrea@gmail.com>
> Date: Sun, 12 Jan 2020 19:17:38 +0100
> Cc: 39082@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-12 18:44 ` Eli Zaretskii
@ 2020-01-13 9:27 ` Robert Pluim
2020-01-13 16:18 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Robert Pluim @ 2020-01-13 9:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andrea Greselin, 39082
>>>>> On Sun, 12 Jan 2020 20:44:08 +0200, Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-13 9:27 ` Robert Pluim
@ 2020-01-13 16:18 ` Eli Zaretskii
2020-01-13 16:43 ` Robert Pluim
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2020-01-13 16:18 UTC (permalink / raw)
To: Robert Pluim; +Cc: greselin.andrea, 39082
> 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.
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-13 16:18 ` Eli Zaretskii
@ 2020-01-13 16:43 ` Robert Pluim
2020-01-13 16:56 ` Andrea Greselin
2020-01-13 17:03 ` Robert Pluim
0 siblings, 2 replies; 13+ messages in thread
From: Robert Pluim @ 2020-01-13 16:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: greselin.andrea, 39082
>>>>> 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.
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
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-13 16:43 ` Robert Pluim
@ 2020-01-13 16:56 ` Andrea Greselin
2020-01-13 17:03 ` Robert Pluim
1 sibling, 0 replies; 13+ messages in thread
From: Andrea Greselin @ 2020-01-13 16:56 UTC (permalink / raw)
To: Robert Pluim; +Cc: 39082
[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]
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@gmail.com> wrote:
> >>>>> 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.
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 2341 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-13 16:43 ` Robert Pluim
2020-01-13 16:56 ` Andrea Greselin
@ 2020-01-13 17:03 ` Robert Pluim
2020-01-13 17:26 ` Eli Zaretskii
1 sibling, 1 reply; 13+ messages in thread
From: Robert Pluim @ 2020-01-13 17:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: greselin.andrea, 39082
>>>>> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-13 17:03 ` Robert Pluim
@ 2020-01-13 17:26 ` Eli Zaretskii
2020-01-14 9:52 ` Robert Pluim
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2020-01-13 17:26 UTC (permalink / raw)
To: Robert Pluim; +Cc: greselin.andrea, 39082
> From: Robert Pluim <rpluim@gmail.com>
> Cc: greselin.andrea@gmail.com, 39082@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."
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#39082: Inconsolata v3.000 has too wide spacing
2020-01-13 17:26 ` Eli Zaretskii
@ 2020-01-14 9:52 ` Robert Pluim
0 siblings, 0 replies; 13+ messages in thread
From: Robert Pluim @ 2020-01-14 9:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: greselin.andrea, 39082-done
>>>>> On Mon, 13 Jan 2020 19:26:41 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: greselin.andrea@gmail.com, 39082@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-01-14 9:52 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-11 10:03 bug#39082: Inconsolata v3.000 has too wide spacing Andrea Greselin
2020-01-12 15:37 ` Eli Zaretskii
2020-01-12 16:56 ` Eli Zaretskii
2020-01-12 17:52 ` Eli Zaretskii
2020-01-12 18:17 ` Andrea Greselin
2020-01-12 18:44 ` Eli Zaretskii
2020-01-13 9:27 ` Robert Pluim
2020-01-13 16:18 ` Eli Zaretskii
2020-01-13 16:43 ` Robert Pluim
2020-01-13 16:56 ` Andrea Greselin
2020-01-13 17:03 ` Robert Pluim
2020-01-13 17:26 ` Eli Zaretskii
2020-01-14 9:52 ` Robert Pluim
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).