Chris's Wiki :: blog/linux/ModernXFontDrawbackII

The drawback of modern X font handling gets mysterious

January 26, 2012

Back in The drawback of modern X font handling I covered how modern X font rendering happens in the client and so can vary from client to client, going from nice on one client to bad on another. I illustrated this with xterm on Fedora and Ubuntu displaying the same font, Fedora well and Ubuntu badly. I now have a good reason to change to using xterm with modern fonts, so I spent part of today poking at this issue; the results have turned this into a genuine peculiar mystery.

What I have so far:

the problem does not happen with all programs on Ubuntu. So far xterm and GNU Emacs have the bad font rendering, but Firefox, gnome-terminal, and TK-based programs such as exmh and tkmsg do not; they render DejaVu Sans Mono just like Fedora does.
the problem only happens with some monospace fonts, not all of them. The Ubuntu machine I was testing on has 11 candidate fonts listed by 'fc-list :scalable=true:spacing=mono: family'; seven of them show the problem but four do not.
(The good four are TlwgMono, Tlwg Typo, Courier New, and FreeMono. Unfortunately my preferred xterm font is DejaVu Sans Mono.)
the problem is not the Ubuntu version of xterm, the Ubuntu app-defaults file for xterm, or even the Ubuntu Freetype library; I have built the Fedora xterm and my version of Freetype on Ubuntu and used the Fedora app-defaults, and the bad rendering is still there.
I've directly set several fontconfig font rendering options that might be doing this without changing anything; at this point I haven't seen any difference with autohint, weight, embolden, or aspect (the last was a wild shot). Similarly, Xft X resources (cf) do nothing that I can see.
(Forcing autohint=true actually makes the Fedora font rendering slightly but visibly darker while leaving the Ubuntu rendering unchanged for both the good and bad programs.)
the problem doesn't happen with xterm on some FreeBSD machines I have handy; they render DejaVu Sans Mono the good way.

Clearly something mysterious is happening in the depths of the Ubuntu version of Xft or something it calls, but only if it's invoked in the right (or wrong) way. Unfortunately I don't think there's any good way for non-experts to see what font rendering choices are being made (the fontconfig library can be coaxed into some debugging output, but it's pretty much 'exports only' from what I can see), so I have no idea if I'll be able to figure out a solution that lets me use the font I want.

(Changing to gnome-terminal is not a solution for me.)

Comments on this page:

From 94.194.126.16 at 2012-01-26 14:43:42:

I'm sorry -- I meant to comment on this when you put the original post up, and completely forgot about it.

What you're seeing is a difference in hinting style: the Fedora window is rendering with hintstyle=hintfull, and the Ubuntu window is rendering with hintstyle=hintslight. This screenshot shows how to get both by specifying the hintstyle explicitly in the font name.

If you want to force all fonts chosen through fontconfig to be rendered with full hinting, you can do so with a rule in ~/.fonts.conf:
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <match target="font">
  <edit name="hintstyle" mode="assign"><const>hintfull</const></edit>
 </match>
</fontconfig>
I'd guess that Ubuntu has something like that to make slight hinting the default in one of their /etc/fonts/conf.d files. It's a shame the fontconfig rules syntax isn't better-documented, since it's actually very flexible...

-- Adam Sampson

By cks at 2012-01-26 16:07:20:

As far as I can tell, 'hintstyle=' doesn't have an effect on the rendering on Ubuntu for xterm. It does make a difference on Fedora, where hintstyle=hintlight makes things darker in the same way as autohint=true.

From 94.194.126.16 at 2012-01-26 20:29:13:

Looking at the patch that Ubuntu applies to fontconfig, they ship it with a file /etc/fonts/conf.d/10-hinting-slight.conf that contains exactly the rule I've given above -- so it'll overwrite any hinting preference you or an application sets with hintslight (i.e. specifying hintstyle=hintfull will have no effect, because the rule tells fontconfig to rewrite it).

If you want something other than slight hinting, you'll need to either remove that file or add a rule in your user config that forces it to be something else. It looks like they have some other sample hintstyle-changing configurations in /etc/fonts/conf.avail.

-- Adam Sampson

By cks at 2012-01-27 11:42:02:

Thank you! This seems to be pretty much it, and it's fixable by creating a $HOME/.fonts.conf to override it.

(The rendering still looks slightly different between TK apps and xterm, but there's so many things that that could be.)

I'll theorize that the applications that this doesn't happen in are consulting the Gnome preferences system and overriding all of fontconfig's various decisions and settings. I find it surprising and irritating that fontconfig's config files override explicit fontname settings for this stuff, but apparently that's life in the modern era where all sorts of people know better than you do.

By mMontu at 2014-05-29 12:59:33:

This problem was driving me insane. The following ~/.fonts.conf solved it:
   <?xml version='1.0'?>
   <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
   <fontconfig>
     <match target="font" >
       <edit mode="assign" name="hintstyle"> <const>hintfull</const></edit>
     </match>
   </fontconfig>
Chris, Adam: thank you very much!!

Written on 26 January 2012.

«	The death of system administration: I'm all for it

Why metaclasses work in Python