The drawback of modern X font handling

November 17, 2011

In some ways, font handling in modern versions of X is quite nice. We have a decent number of good, high quality fonts in modern scalable formats like TrueType, and one can use fonts from Windows and Mac OS X if one wants to. Thanks to various reforms in font handling, specifying fonts is generally easier and more flexible (hands up everyone who ever tried to generate or read an XLFD string for a particular font), and you can install personal fonts without huge contortions. But it does have one drawback, at least for someone like me.

In the old days of X font handling, the X server did all of the work. X clients simply told the server to render some text in a particular font; it was the server itself that was responsible for generating the font bitmaps and drawing them (sometimes the X server delegated generating font bitmaps to a separate program, such as xfs, the X font server). This meant that you only had to tune fonts in one place and your tuning applied to every X client that you ran, no matter what they were or where they running. Or to put it another way, I could carefully select an xterm font (and size) that I really liked and it would stick everywhere.

(The fly in this 'all in the server' ointment was default X application resources, but you could fix that with some more work.)

In the new world of X fonts, fonts are rendered separately by each X client (using various layers of font selection and rendering) and sent to the server as precomputed bitmaps. If all of your clients are running on the same machine and using the same set of font libraries, the result is the same as in the old world. But if some of your clients are running on different machines and displaying remotely (or some of your local clients have decided to use their own copies of libraries), they can render the same nominal font quite differently. This is especially so if you use generic font names like 'monospace' or 'serif', because what actual fonts those generic names map to is system-specific; one machine may very well map 'monospace' to 'DejaVu Sans Mono', while another maps it to 'Liberation Mono'.

(The corollary to this is that font availability is also a per-machine thing. If you install a new font you like onto your local workstation, an xterm or Firefox or whatever running from a remote server cannot use it.)

In the new world, what you see for something like 'DejaVu Sans Mono 10' depends on the specific version of the font each system has installed, what exact rendering library version each system is using, and what rendering settings each system is using for things like subpixel anti-aliasing. This drastically complicates efforts to, say, pick a single modern font for all of your terminal windows.

(I'm aware that the modern answer to this drawback is that I should run all of my X programs locally and just use ssh. This is what you could politely call a fail.)

Sidebar: a concrete example

Both of the following images are xterm using DejaVu Sans Mono 10, displaying on a Fedora 15 machine's X server. One of the xterms is running locally on the Fedora 15 machine; the other is running on a 32-bit Ubuntu 10.04 machine.

Fedora 15 xterm Ubuntu 10.04 xterm

One of these I rather like, one of these I can't stand.

(Part of the difference is clearly in different settings for subpixel anti-aliasing; the Ubuntu 10.04 version has colour fringes that the Fedora 15 version does not. But I don't think the difference in line width that makes the 10.04 version visibly blacker is due to that.)

Written on 17 November 2011.
« A classic and standard C quoting bug
My Liferea crashes are not Liferea's fault »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Nov 17 17:22:18 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.