X11 hits! X11 hits! You die…
I just spent an hour or so trying to figure out why Mozilla doesn’t show nice smoothed fonts anymore on some sites, and all the while I kept thinking of Pete’s recent Tea Leaves post on the X11 disaster. He ranted for a while about how pathetic it is that in 2005 X still doesn’t work right and probably never will, and in response he got some random Linux weenie complaining that his problems would just go away if he stopped using the wrong X server and the wrong programs.
Well, okay.
I’m using the shiny new X.org 6.8.1 server with libXft 2.1.6 and Mozilla Firefox 1.0, all tied together with Gnome 2.8.2. I’m as upgraded as I can get, according to /usr/ports, which I have arbitrarily chosen to trust.
So why is it that it still sucks?
I started off focusing on why Tomato Nation shows a jaggedy un-aliased Times font. After a bit of digging, I found that the CSS file the site uses specifies this:
font-family:new times roman,times,serif;
for body fonts. Since I knew from previous times I’ve bashed my head against Xft (the inscrutably named font-smoothing engine, for those folks blissfully unaware of X internals who have for some reason read this far) that Xft works by pattern-matching requested font names against actual fonts, I guessed that the problem was the weird name. It’s unusual to see new times roman instead of times new roman, and maybe that meant that Xft decided it couldn’t figure out how to render this font and fell back on the old crufty jagged rendering.
Okay, fine. Assuming that’s the problem, how do I fix it?
First try: manpages. “man -k xft” only gives me programming manuals, which is pretty useless. I want to know how to use Xft, not write programs for it.
So, second try: Google. Google tells me a lot more about programming Xft, and briefly mentions ‘XftConfig’ files. I don’t seem to have one of those, and all of the references I’m seeing are suspiciously old. Maybe it’s changed?
On to the third try: poking through my machine’s package files. Aha! The package info for libXft-2.1.6 tells me this:
The current version of Xft provides a client-side font API for X applications. It uses Fontconfig to select fonts and the X protocol for rendering them. When available, Xft uses the Render extension to accelerate text drawing. When Render is not available, Xft uses the core protocol to draw client-side glyphs. This provides completely compatible support of client-side fonts for all X servers.
– keithp
Okay, I guess I want to learn about Fontconfig. On to try four, which is yet again manpages:
nlanza@revelstoke:~> man fontconfig No manual entry for fontconfig
Thanks, “keithp”! Big help!
Try five: back to Google, where I end up at fontconfig.org, which appears to have a User’s Manual. Great, I guess. The manual’s a little opaque:
match target=”pattern”
This element holds first a (possibly empty) list of test elements and then a (possibly empty) list of edit elements. Patterns which match all of the tests are subjected to all the edits. If ‘target’ is set to “font” instead of the default “pattern”, then this element applies to the font name resulting from a match rather than a font pattern to be matched.
After a bunch more googling, since of course there’s no user-friendly FAQ at fontconfig.org, it turns out I want this super-verbose stanza to go in ~/.fonts.conf:
<match target="pattern">
<test qual="any" name="family"><string>new times roman</string></test>
<edit name="family" mode="assign"><string>times new roman</string></edit>
</match>
With that in place, things appear to work. At least, until the next time versions change and my configuration changes subtly, at which point I expect it’ll mysteriously break again.
I still don’t quite get why this is so wonderful and advanced, though. Why do I have to track down mailing list posts in order to find the right four lines of XML garbage to throw into yet another configuration file just so this “fast, powerful, and very flexible” desktop (to quote Pete’s Linux weenie) can get basic details like this right?
Apparently when people say “Windows has nothing to come close to that” they mean “Windows actually renders fonts on its own, so you have to find something else to do with your time.”
Oh, extra credit question:
In digging around, I noticed that some Xft properties can be specified either in ~/.fonts.conf or X resources. So if I want subpixel rendering, I can either use this:
<match target="font">
<edit name="rgba" mode="assign"><const>rgb</const></edit>
</match>
or set the ‘Xft.rgba‘ resource to ‘rgb‘.
Here’s the question: Since I can specify this in two different places, if I specify ‘rgb‘ in one and ‘vrgb‘ in the other one, which one wins? No fair looking at the source code — this kind of thing ought to be documented.
Extra-extra-credit unfair question: How is anyone who isn’t deeply familiar with Unix supposed to figure this out? Sure, I have a shiny little Gnome widget to let me specify some parts of the antialiasing, but it won’t do the name mapping I needed here. It doesn’t even really explain what the options it does support mean — they’re just there for you to click on randomly and hope they actually helped.
Maybe I’ll just give up and buy myself a goddamn Mac to use at work.
January 27th, 2005 at 8:09 pm
Wow, that’s nasty. Why isn’t there a tool for that?
January 27th, 2005 at 8:29 pm
My guess is that it’s because Xft’s default matching works most of the time, and there’s still a lot of “just edit the config file by hand like I do, you big baby” attitude floating free in the Unix world.
Remember, the Unix way isn’t “this program is hard to use”, it’s “you’re not smart enough to use this program”.