Fedora 26 and a font rendering dilemma for me

August 25, 2017

I recently upgraded my office workstation from Fedora 25 to Fedora 26, which didn't go entirely smoothly. One of the things that didn't is fonts, or more specifically a change in font rendering. I have a long standing set of fontconfig user tweaks that are supposed to give me relatively light-weight fonts, and they've now stopped working all that well (although it turns out they haven't completely stopped working).

To make this concrete, ere are three images of xterm using DejaVu Sans Mono 10, all displaying on the same machine via the magic of remote X. The Fedora 25 image is my normal and preferred font rendering, the 'Fedora 26' image is the stock font rendering on Fedora 26, and the 'Fedora 26 me' image is how Fedora 26 renders fonts with my fontconfig settings (which is almost identical to the stock rendering, but slightly lighter in spots and I think less antialiased).

Fedora 25 xterm Fedora 26 xterm Fedora 26 xterm with my fontconfig

This is not the first time I've had my font rendering change around to give me darker fonts; it once happened with Ubuntu 10.04 and was ultimately resolved as a different in fontconfig settings (see the comments here). Unfortunately this isn't the case this time around; instead, it appears to be a change in how FreeType renders exactly the same fontconfig setup. Something in the shift from version 2.6.5 (in Fedora 25) to 2.7.1 (in Fedora 26) seems to be ignoring parts of my fontconfig customizations.

(The Fedora 25 and Fedora 26 /etc/fonts and /usr/share/fontconfig are almost identical, and my usual diagnostic tools like 'fc-match -v monospace' and 'FC_DEBUG=1025 xterm' claim that there is no difference in computed results. Even the versions of fontconfig itself are essentially identical. I verified it was the Fedora 26 version of FreeType by copying the Fedora 25 libfreetype.so to my Fedora 26 machine and using it with LD_LIBRARY_PATH.)

This leaves me with a dilemma. On the one hand, perhaps I could invest a lot of effort into figuring out either what I need to do to FreeType to fix this rendering issue (I've built custom versions back in the old days) or what magic new options to use in my fontconfig settings to make FreeType 2.7.1 render things the old way. On the other hand, not only would this be a bunch of work invested in fighting how FreeType really wants to render fonts, but maybe the new rendering is actually objectively more readable, even if it looks wrong to me.

I'm very used to my thin font rendering; I've literally been looking at it for years. The thicker rendering that FreeType does by default (and more or less forces in Fedora 26) looks viscerally wrong and feels annoyingly different. But this doesn't mean that my old fonts are more readable, and in fact I've made that sort of mistake before, which makes me suspicious about the idea that I know better than everyone working on FreeType and font configuration on Linux (it's not just Fedora, since just about everyone seems to default to this thicker and darker style of font rendering).

It irritates me to give in this way, and I definitely feel run over by the sprawling mess that is modern display fonts on Linux and Unix generally (given Wayland, it's not really accurate to call them just 'X fonts' any more). I reflexively don't like surrendering to city hall this way. But maybe it's for the better, and it's certainly going to be easier.

As an experiment I've now turned off my fontconfig customizations even on Fedora 25, by renaming my .config/fontconfig/fonts.conf to another name. It's, well, different. But I haven't yet changed back, and I can probably live with it after I get used to it. After all, I've gone through big font changes before, when I moved from old bitmapped fonts in xterm and even my web browser to modern XFT fonts, and I survived back then.

Written on 25 August 2017.
« Why Go changes its minimum version requirements for OSes (and hardware)
The probable coming explosion of Firefox 57 »

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

Last modified: Fri Aug 25 01:45:22 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.