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: 2015-05-19 18:30 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.
Comment 12 yardena 2015-05-19 18:30:09 UTC
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.