Inconsolata v3.000 letter-spacing is too wide in programs that use Xft

[agreselin]

Hello, after upgrading to Inconsolata v3.000 on Fedora 31, letter-spacing has become too wide in Emacs, as shown in the attached screenshot; it shows the Emacs window I get on running emacs -Q. I'm running Emacs 26.3.

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

[mjmartineau]

I see this problem on Fedora 30. It happens with both emacs 26.2 and 26.3.

[aterweele]

I can also repro on Emacs 27.0.50.

[raphlinus]

This is very likely a bug in Emacs and not the font, though I'm happy to apply a workaround. I recommend filing a bug against Emacs and see if they can analyze it.

There are a couple of culprits which seem plausible. One is the ligatures (though if that were the case it would probably have triggered with an earlier version). Perhaps a more likely explanation is that when it assembles a family it gets confused and thinks that the expanded widths are the reference for width.

[agreselin]

I recommend filing a bug against Emacs and see if they can analyze it.

Done, here it is: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39082

[Eli-Zaretskii]

I can also repro on Emacs 27.0.50

27.0.50 is an old development version of an unknown date. Current Emacs master is at 28.0.50, and the emacs-27 release branch is at 27.0.60.

Please make sure you are using the latest Emacs codebase, and make sure your build is with HarfBuzz, which is our default font-backend starting from Emacs 27.

FWIW, I see no problems with this font in Emacs 27, but I'm on MS-Windows, not on Fedora. Maybe it's a problem with font software on Fedora.

[Eli-Zaretskii]

Perhaps a more likely explanation is that when it assembles a family it gets confused and thinks that the expanded widths are the reference for width.

Could you please elaborate on this? What do you mean by "assemble a family", and what are the "expanded widths" and where do they come from? And how is this different from the older versions of Inconsolata?

I'm not an expert on fonts, but with enough information I could try looking at the relevant Emacs code to see whether it gets confused by this font.

TIA

[Eli-Zaretskii]

Also: are the problems with OTF or TTF version of the font?

[Eli-Zaretskii]

And one more question: what does the below produce in an Emacs session with the problematic display?

    M-x set-variable RET eval-expression-print-length RET nil RET
    M-: (font-info (font-at 1)) RET

Please show the full output (take it from the *Messages* buffer if needed.)

[agreselin]

Also: are the problems with OTF or TTF version of the font?

I use the fonts from Fedora's levien-inconsolata-fonts package, which are TTF's.

And one more question: what does the below produce in an Emacs session with the problematic display?

I get ["-CYRE-Inconsolata-normal-normal-normal-*-21-*-*-*-m-0-iso10646-1" "Inconsolata:pixelsize=21:foundry=CYRE:weight=normal:slant=normal:width=normal:spacing=100:scalable=true" 21 23 0 0 0 32 19 4 32 32 "/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)))]. Note that this is in Emacs 26.3 (the current version from Fedora's repos).

[Eli-Zaretskii]

And if you invoke Emacs as emacs -Q -fn Inconsolata-12, what happens then with the output of the above command and with the spacing on display?

[Eli-Zaretskii]

Also, can you try the OTF font?

[agreselin]

And if you invoke Emacs as emacs -Q -fn Inconsolata-12, what happens then with the output of the above command and with the spacing on display?

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

Also, can you try the OTF font?

The OTF font I've downloaded from dl.fedoraproject.org is also afflicted by this bug. (font-info (font-at 1)) output after running emacs -Q -fn Inconsolata-12 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 "/home/andrea/.fonts/Inconsolata-3.000/otf/Inconsolata-Regular.otf" (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)))]

[Eli-Zaretskii]

Using the related Emacs APIs, we've established that Emacs treats the glyphs of this font as if they had width of 29 pixels, instead of the expected 10 or thereabouts. The way Emacs accesses the glyph metrics is as follows:

static void
xftfont_text_extents (struct font *font, const unsigned int *code,
int nglyphs, struct font_metrics *metrics)
{
struct font_info *xftfont_info = (struct font_info *) font;
XGlyphInfo extents;

block_input ();
XftGlyphExtents (xftfont_info->display, xftfont_info->xftfont, code, nglyphs,
&extents);
unblock_input ();

metrics->lbearing = - extents.x;
metrics->rbearing = - extents.x + extents.width;
metrics->width = extents.xOff;
metrics->ascent = extents.y;
metrics->descent = extents.height - extents.y;
}

(where CODE is the index of the glyph for the character in this font).

Can the font experts here tell whether this is incorrect, at least with this font, and if so, how to fix it?

[Eli-Zaretskii]

According to https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-01/msg00509.html, this seems to be a bug in Xft, and the workaround is to use the Cairo build of Emacs, which doesn't have this problem.
Xft seems to be unmaintained, and Emacs will probably deprecate its use in some future version. So I guess a better way forward is to switch to the Cairo build.

[raphlinus]

@Eli-Zaretskii Thanks for the update, that's useful. Do you know if there's a workaround that can be done in the font in the meantime?