Created attachment 58262 [details]
screenshot with libxft 2.2
Hi, since libXft-2.3.0, my fonts look really faint in my xterm. Also the space between the characters looks much bigger.
See attached screenshots.
I ran a git bisect on libXft git repository.
Unfortunately, libXft crashed on many commits. So, it's really difficult to determine the exact commits where the bug first appear.
here is the result:
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
Here are the matching links:
So, it may have something to do with the "Subpixel LCD text rendering improvements"
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)
You can notice visible gaps on the right side of the statusbar.
This only seems to affect antialiased fonts.
(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
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.
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.
on Mar 25, 2017 at 15:31:41.
(provided by the Example extension).