Bug 47178 - fonts are all messed up since libXft-2.3.0
fonts are all messed up since libXft-2.3.0
Status: NEW
Product: xorg
Classification: Unclassified
Component: Lib/Xft
unspecified
Other All
: medium normal
Assigned To: Xorg Project Team
Xorg Project Team
:
Depends on:
Blocks: X11R7.8
  Show dependency treegraph
 
Reported: 2012-03-10 01:38 UTC by arno
Modified: 2013-05-15 14:28 UTC (History)
8 users (show)

See Also:


Attachments
screenshot with libxft 2.2 (23.63 KB, image/png)
2012-03-10 01:38 UTC, arno
no flags Details
screenshot with libxft 2.3 (28.23 KB, image/png)
2012-03-10 01:38 UTC, arno
no flags Details
screenshot with libxft 2.3 + patch (30.24 KB, image/png)
2012-03-12 09:53 UTC, arno
no flags Details
screenshot with libxft 2.3.0 - vim-powerline - urxvt (6.12 KB, image/png)
2012-03-13 23:25 UTC, Kevin Sullivan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description arno 2012-03-10 01:38:32 UTC
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:
21a59c10803582c8f90d3b5f32e8f0240c050adf
550b2f76401c292d982700b60326e0a837e391b4
6f1d7bcdd461b1f6cc64370793f52d7c170187d0
301029c9a1d9429009eaf08bb726357d4e94780d

Here are the matching links:
http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=21a59c10803582c8f90d3b5f32e8f0240c050adf
http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=550b2f76401c292d982700b60326e0a837e391b4
http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=6f1d7bcdd461b1f6cc64370793f52d7c170187d0
http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=301029c9a1d9429009eaf08bb726357d4e94780d

So, it  may have something to do with the "Subpixel LCD text rendering improvements"
Comment 1 arno 2012-03-10 01:38:53 UTC
Created attachment 58263 [details]
screenshot with libxft 2.3
Comment 2 Chí-Thanh Christopher Nguyễn 2012-03-12 02:30:11 UTC
Try the patch from bug 47196
Comment 3 arno 2012-03-12 09:53:15 UTC
Created attachment 58331 [details]
screenshot with libxft 2.3 + patch

With the patch, fonts are no more faint, but the space problem remains
Comment 4 Kevin Sullivan 2012-03-13 23:25:12 UTC
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.
Comment 5 Rob 2012-03-19 04:25:32 UTC
This only seems to affect antialiased fonts.

https://bbs.archlinux.org/viewtopic.php?pid=1072487#p1072487
Comment 6 mcortese 2012-07-23 10:32:07 UTC
(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.
Comment 7 Matthieu Herrb 2012-07-23 12:05:46 UTC
Commit 84b8b5b46773f9b686d57f28092824b86bffed9d (and libXft 2.3.1) is supposed to fix that. Has debian updated its packages ?
Comment 8 Dmitry Dzhus 2012-10-20 09:08:36 UTC
(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.
Comment 9 yardena 2013-04-23 05:36:35 UTC
I also have this problem. I use Arch Linux with otherwise up-to-date packages. Downgrading to 2.2.0 fixes it.
Comment 10 yardena 2013-04-23 07:00:27 UTC
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. :)
Comment 11 yardena 2013-04-23 07:45:33 UTC
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.