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 Toolybird (Toolybird) - Monday, 01 May 2023, 23:12 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
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.

[1]: https://aur.archlinux.org/packages/st-git/
This task depends upon

Closed by  Toolybird (Toolybird)
Monday, 01 May 2023, 23:12 GMT
Reason for closing:  Fixed
Additional comments about closing:  See comments
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 (https://www.archlinux.org/packages/community/x86_64/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: https://github.com/LukeSmithxyz/voidrice/commit/f6659aac334265a73c48d27a7babdfce1f5f886e#commitcomment-37998014
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 https://github.com/googlefonts/Inconsolata 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.

[1] https://github.com/googlefonts/Inconsolata/blob/master/fonts/ttf/Inconsolata-Regular.ttf
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:
Comment by Toolybird (Toolybird) - Monday, 01 May 2023, 23:12 GMT
This is supposedly fixed in recent libxft [1]. Either way, I'm failing to see how this is an Arch packaging problem.

[1] https://gitlab.freedesktop.org/xorg/lib/libxft/-/issues/15