Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#65932 - [ttf-inconsolata] wide character spacing

Attached to Project: Community Packages
Opened by Tyler Johnson (tejohnso) - Sunday, 22 March 2020, 14:29 GMT
Last edited by freswa (frederik) - Monday, 23 March 2020, 13:41 GMT
Task Type Bug Report
Category Packages
Status Assigned   Reopened
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 9
Private No


The latest version 1:3.000-1 works with xterm, but with st[1] the font has extremely wide character spacing, no matter which font version is used.
Previous version 1: worked fine in both xterm and st.

This task depends upon

Comment by SATO Tatsuya (tattsan) - Monday, 23 March 2020, 13:40 GMT
  • Field changed: Percent Complete (100% → 0%)
This task was once closed because 'st' is an AUR package. But Emacs (of course, offical package) also gets abnormal spacing.
Comment by SATO Tatsuya (tattsan) - Monday, 23 March 2020, 14:17 GMT
It seems to be a problem of Xft.

As for Emacs, the problem seems to be avoided by building emacs with cairo enabled.
Comment by Rian McGuire (rmcgu) - Monday, 23 March 2020, 21:14 GMT
This is also a problem in kitty (
Comment by death (death) - Tuesday, 24 March 2020, 15:46 GMT
Issue also manifests itself in gitk.
Comment by Mads Peter Rommedahl (madpet) - Wednesday, 25 March 2020, 07:50 GMT
I believe it is also present in dmenu
Comment by Mads Peter Rommedahl (madpet) - Wednesday, 25 March 2020, 08:24 GMT
It seems the core problem is that XFT is unmaintained, and the recommended solution is to move affected packages to rely on Cairo instead:
Comment by Alessio (a1ess1o) - Saturday, 04 April 2020, 14:04 GMT
Same behaviour on rxvt-unicode
Comment by Ricardo (jimenezrick) - Tuesday, 23 June 2020, 11:12 GMT
I also have font rendering issues in Emacs/Alacritty terminal. So the Inconsolata github repo has more recent changes that may or may not improve the situation, but there isn't a properly tagged release including those changes.
Basically the last release v3.000 is including changes up to Dec 2019. I think we should start packaging this font just following master commits directly when we find the font is working well.
Comment by Ricardo (jimenezrick) - Tuesday, 23 June 2020, 11:19 GMT
And just to confirm version 1: works well for me, but not 1:3.000-1. Hence I propose to try the last changes in master from and if so, start releasing picking specific commits from master (instead of using official tags which aren't kept up to date).
Comment by Antonio Rojas (arojas) - Tuesday, 23 June 2020, 12:26 GMT
As mentioned above, this is an issue with xft so it's unlikely to be fixed in the fonts. Anyway, what about trying that git build yourself and reporting your findings?
Comment by Ricardo (jimenezrick) - Tuesday, 23 June 2020, 20:22 GMT
Fair enough. I was thinking to build myself the font, but oh well, it's actually complex, extra tooling is needed, not really an automated process. But seems like they regenerated the font on the last changes[1], i tried and no improvement with Emacs, same wide spaces problems, which rules out xft based applications. I'm aware that recent Emacs now has stable support for cairo backend, so that seems the best approach in my specific case if Arch enables it.

Comment by mattia (nTia89) - Sunday, 19 September 2021, 08:44 GMT
I cannot reproduce the issue.
Is it still valid?
Can you provide a screenshot?
Comment by Kevin (kilogram) - Tuesday, 21 September 2021, 00:14 GMT
I can reproduce on rxvt-unicode (screenshot attached). Please let me know if there are other reproduction instructions, or inspection info I can provide.

Workaround has been to use version 1: