Font Rendering

Posted November 20th, 2007 by Paul Gideon Dann

Computing

I'm a perfectionist by nature, so something as fundamental as on-screen font rendering is a big deal to me. In my quest toward a usable Linux desktop, I decided to look deeper into the way font rendering works, and what is available.

I'll try to demonstrate the problem of font rendering as I understand it using some simple illustrations. A font glyph (e.g. a letter) is stored in the file as a mathematical series of curves and lines. We render the glyph on to a grid of pixels in order to display it on-screen. When we're working with high resolutions (measured in Dots per Inch), it can look pretty good. Printers work at much higher resolutions than monitors (~1200 DPI vs ~100 DPI), and as a result have no problem printing perfectly shaped fonts at a readable size. However, take a look at what happens as we draw a glyph at progressively smaller and smaller sizes on a computer screen:

simple resizing

The glyphs start to lose their shape. This is due to a phenomenon known as aliasing — due to a limited space on the pixel grid, two or more neighbouring pixels in the original image may be joined together to form a single pixel in the smaller image. Two very different processes were devised to deal with this problem:

Hinting

Antialiasing

The hinting system is employed by Microsoft in Windows. The way it works is quite clever really — they've embedded a kind of small program inside the font file. When a font is rendered, the hinting program is used to modify the glyph's shape to counter the natural deformity that would otherwise occur. The result is very clear text, but the actual shape of the glyphs are often very different from the original shape.

Antialiasing uses the technique of smoothing over the edges of fonts to make them appear less jagged at lower resolutions. The advantage is that we don't have to sacrifice the font's distinctive shape. The downside is that the text may appear blurry and a bit fat.

Now the font rendering system in Linux-base systems (FreeType) is quite capable of using the hinting in Microsoft Fonts. Unfortunately, the hinting algorithm used by Microsoft is patented (by Apple actually), so support for this is usually switched off in Linux. It is possible to switch this on by recompiling FreeType, but to take advantage of it, you will have to get hold of some fonts that contain hints. You can download Microsoft's Web Core Fonts, which include the popular Arial, Comic Sans, Courier New, Times New Roman, and Verdana fonts (among others). Going down this path will provide you with the same pixel-aligned characters in Linux as in Windows. Some prefer that, some don't.

LCD monitors are worth mentioning here, as they are in a world of their own. The problem with LCDs is that they have a very rigid pixel grid. Each pixel is a perfect square, made of red, green, and blue stripes clumped together. This is a great contrast to CRT displays, which are simply much blurrier. When it comes to font rendering, these rigid square pixels can cause problems. The grey blurring caused by antialiasing becomes much more noticeable on LCD monitors, especially on vertical and horizontal strokes. Interestingly though, we can take advantage of the physics of LCD monitors to improve the effective resolution of our onscreen fonts. This technique is known as subpixel rendering, and I'll leave it to Wikipedia to explain it to you.

In an attempt to minimize each system's flaws, most modern systems use a mix of hinting and antialiasing. For Linux-based systems, FreeType is capable of hinting fonts by using an elaborate and carefully tuned "auto-hinter", whose job it is to make a good guess at how best to render fonts at low resolutions. Combined with antialiasing, this is capable of producing very good results.

Since I have the rare privilege of having access to all three major operating systems (Windows, MacOS X, and Linux), I thought I'd finish off this article with some screenshots of text rendering on the three giants, to let you decide which you like best: