Bug 47178

Created attachment 58263 [details]
screenshot with libxft 2.3

Try the patch from bug 47196

Created attachment 58331 [details]
screenshot with libxft 2.3 + patch

With the patch, fonts are no more faint, but the space problem remains

Created attachment 58417 [details]
screenshot with libxft 2.3.0 - vim-powerline - urxvt

I confirm this problem in URxvt. It is especially noticeable while using vim and the vim-powerline plugin.

Font: DejaVu Sans Mono for Powerline(patched version on Github)
Term: URxvt

You can notice visible gaps on the right side of the statusbar.

This only seems to affect antialiased fonts.

https://bbs.archlinux.org/viewtopic.php?pid=1072487#p1072487

(In reply to comment #4)
> Created attachment 58417 [details]
> screenshot with libxft 2.3.0 - vim-powerline - urxvt
> 
> I confirm this problem in URxvt. It is especially noticeable while using vim
> and the vim-powerline plugin.
> 
> Font: DejaVu Sans Mono for Powerline(patched version on Github)
> Term: URxvt
> 
> You can notice visible gaps on the right side of the statusbar.

Under Debian, I use URxvt with DejaVu Sans Mono, and confirm the same experience.
I think I can isolate two orthogonal issues:

1) extra width -- this is a bug in URxvt, which calculates the cell width from the glyphs' g.width - g.x whereas the correct method would be to use g.xOff (a patch was submitted to Debian, but ignored so far: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628167). I think this bug has been present for some time, but it has never shown up, because for most fonts it is true that xOff equals width - x. The latest version of libxft might introduce new hinting tricks that trigger the bug.

2) even removing the issue #1 (applying the patch linked above), the on-screen rendering of the glyphs is different than before (libxft pre 2.3.0), markably darker and with visible colored artefacts between vertical strokes.

Commit 84b8b5b46773f9b686d57f28092824b86bffed9d (and libXft 2.3.1) is supposed to fix that. Has debian updated its packages ?

(In reply to comment #7)
> Commit 84b8b5b46773f9b686d57f28092824b86bffed9d (and libXft 2.3.1) is
> supposed to fix that. Has debian updated its packages ?

On my system with libXft 2.3.1 I don't see that rendering anyhow improved since
it was broken in 2.3.0. I'm using rxvt-unicode with DejaVu Sans Mono fonts.

I also have this problem. I use Arch Linux with otherwise up-to-date packages. Downgrading to 2.2.0 fixes it.

After doing my own testing I can confirm arno's results:

0e0efb8 fonts good
6f1d7bc crashes
21a59c1 crashes
550b2f7 crashes
301029c fonts bad
...
c5e760a fonts still bad

Unfortunately, none of the later fixes work for me. I don't know a lot of C, but I'm feeling adventurous so I'll try narrowing down a changeset anyway. :)

After merging 6f1d7bc with the one-line fix from 301029c, urxvt runs successfully, and the fonts are bad. That means I've narrowed the bug down to THIS commit: http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=6f1d7bc

Sadly, it's a large complicated commit, and this is coming close to exhausting my C skills. I am not sure I can finish the job.

To summarize: 6f1d7bc was supposed to be "Subpixel LCD text rendering improvements" but messed up font rendering and also made the whole program crash. 301029c fixed the crash, but did not fix the font rendering.

http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=6f1d7bc
http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=301029c

It's been many years. Can anyone else look at this who's more familiar with the code? If not I can try to fix it myself, but my C still sucks.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libxft/issues/1.