Linux Font Rendering Revisited
Since I wrote my original article on the subject of font rendering in Linux, a few things have happened: Freetype development has moved forward, and I’ve experimented quite a bit, always trying to improve on how fonts appear on screen. I’ve achieved significantly better results using the latest Freetype and Cairo LCD patches than was previously possible, and have finally spent a morning putting my experience in writing to help others with similar interests.
Here are the steps I took to produce my current results. I’m sorry they aren’t in a more distribution-agnostic format, but I use Gentoo—and font rendering is awful by default.
By contrast, Ubuntu seems to produce considerably better font rendering without all this effort, so if you’re an Ubuntu user (or you think fonts render just fine already), please don’t bother yourself with trying to improve them; you probably won’t notice a difference (or they’ll look worse than they do now).
- Install Freetype 2.3.1. It contains numerous additions to improve font rendering over 2.2.1. No patches are necessary, although you will still want to enable the Byte-Code interpreter. In Gentoo, you add a line that reads
media-libs/freetype -bindistto the file/etc/portage/package.usethenemerge -av freetype. - Next, you will need to patch Cairo using the LCD Filter Patch—make sure you get the correct patch for your version of Cairo (probably 1.2.4). Applying the patch is relatively straightforward so I won’t describe it here: you can find plenty of instructions elsewhere on how to apply patches.
- If you’re a Gentoo user, I’ve saved you most of the effort: You can download my ebuild and patches for Cairo:
su mkdir -p /usr/local/portage/x11-libs/cairo/files cd /usr/local/portage/x11-libs/cairo/files wget http://www.isolationism.com/patches/cairo-fir.diff wget http://www.freetype.org/freetype2/patches/cairo-1.2.4-lcd-filter-1.patch cd .. wget http://www.isolationism.com/patches/cairo-1.2.4.ebuild ebuild cairo-1.2.4.ebuild digest echo "x11-libs/cairo lcdfilter" >> /etc/portage/package.use emerge -av cairo
- Next, patch libXft in much the same manner using the LCD patches. I have a Gentoo ebuild for this but I haven’t uploaded it yet, sorry.
- Now, you will need to create/edit your
~/.fonts.conffile. You can use mine or you can fiddle with it yourself to your heart’s content. The salient points:- Set your preferred “general” settings at the top of the file. You probably want to enable hinting, autohinting, and antialiasing. Choose and set your preferred hinting level. If you have an LCD monitor, you can try out enabling sub-pixel hinting as well, although I find the colour bleeding to be too distracting and prefer to leave it disabled.
- Create an exception for things you don’t like by default—For example, I hate how smaller text tends to have awful kerning/tracking, so I match text within a certain pixel size and disable autohinting for it (which in turn enables the BCI). Note how I’ve also disabled sub-pixel hinting as well: this is because sub-pixel hinting and the BCI do not get along; you will have rainbow fonts if you omit this step when using the BCI. You’ve been warned!
- Some other example exceptions I’ve created are for handling poor autohinting for certain fonts/sizes, boldfaced fonts, and serif fonts, which seem to cause more rendering issues than the sans-serif variety.
- Last but not least: write-protect your
~/.fonts.conffile. You can shoot yourself in the foot much too easily if you forget all your hard work and try to change your font rendering settings in KDE/gnome—they will rewrite the file from scratch and all your hard work will be lost.chmod 444 ~/.fonts.conf
That’s it. Reload your favourite web browser and surf to a few different sites to see how everything looks. Hopefully the improvement will be noticeable (it sure is for me!).
Note that you will have to restart X to make sure all applications are using the new libraries. Do this when you’re happy with everything you’ve set above so you don’t have to keep restarting over and over to get it looking right.
You do realise that the FIR filter patches have no effect if you disable subpixel rendering, right?
Yes. My problem with the sub-pixel font rendering is … complex.
In a nutshell, I want the font shapes to look nice (obviously), but I want the kerning to be decent even more.
If you use light autohinting, the overall texture looks great although the characters appear slightly soft, and verticals tend to have a bit of extra visual ‘weight’. LCD filtering of any has very little effect on light autohinting—except to bring out shimmery green/blue edges to fonts (they look terrible).
If you want to actually use the FIR filter, you have to enable “full” autohinting—where the characters look great. Unfortunately they do so at the expense of the kerning; serif fonts in particular r e a d l i k e t h i s. I tried to address this problem before in my
.fonts.conffile by “snapping” fonts to precise rendering sizes (much like Microsoft’s ‘ClearType’ does) but this only reduced—but did not eliminate—the problem.This is of course what the RSB/LSB deltas are designed to address; they tighten up this woeful appearance to make the glyphs (again, only in full “auto-hinting” mode) render with the correct kerning distances. Unfortunately, as David Turner himself points out:
So I can choose from fuzzy shapes but readable text under all fonts, or have fonts render as if they’ve been tracked out by 50%. Much to my chagrin, it appears impossible to mix between ‘full’ and ‘light’ autohinting via
.fonts.conf; you either render all fonts with one or the other (you can however enable/disable the BCI on a per-font basis, it seems).At the end of the day, my choice was the slightly-fuzzy and horizontally-elongated (but readable) slight autohinting setting. I would love nothing more than to be able to enable full autohinting and still be able to read text without going crosseyed; however, since there is a patent(s?) quagmire surrounding anything to do with sub-pixel font rendering technology, I doubt very much that we will see any official patches for any software anytime soon, least of all browsers (which arguably will benefit most from application of this technology).
You’re mixing up FIR filtering with LCD sub-pixel rendering. It’s true that the original filter for LCD rendering does result in color bleeding — and that’s exactly the problem FIR filter patch tries to solve. And I think it’s very successful. To try it out, you have to install patched freetype, Xft and cairo. Fortunately freetype and Xft both have patches already commited upstream, so it’s just a matter of simple emerge. I’m not sure about cairo, though. Anyway, check it out yourself — KDE uses Xft, so any KDE app would show the effect instantly once restarted.
About the kerning and spacing stuff — you can’t be more right. I believe the best approach would be to use full potential of sub-pixel rendering to get rid of horizontal hinting altogether — as outlined in this insightful paper (examples included). That way horizontal spacing is exact — and it shows that with sub-pixel rendering horizontal resolution is already high enough to get rid of hinting in that direction.
I’m not sure there’s really a distinction in this context; FIR filtering is an alternative method of deriving LCD sub-pixel rendering, the effects of which are certainly reduced colour bleeding, but not eliminated: Again, quoting David from one of his more recent posts covering his advances with Freetype:
… So we’re never going to get rid of the color fringes unless we adopt something closer to Microsoft/BCI, which I find less desirable than the product of either slight or full autohinting (although your tastes may differ). It is trivial to demonstrate the effects of all of the various filter combinations thanks to the very nice (painful interface aside) ftdiff program David created. What I’d like to know is how all of the multitudinous options are supported simultaneously in one application without having to restart anything; it sure would be nice to be able to run a completely mixed font-rendering technology environment natively in X…
As for the article, It looks to be brand-spaking new so I’ve certainly never seen it before—and it definitely looks to be comprehensive. I’m going to have to give that a read; thanks for bringing it to my (and my readers’) attention!
Here’s hoping David finds himself with a bit more free time in the near future for reading this new paper and perhaps thinking of ways to apply it to the Freetype, XFT and Cairo libraries.