October 12, 2004

A font primer for Linux

Author: Nathan Willis

Like most people, I've generally taken fonts for granted over the years. You hit a key, a letter appears on screen -- no magic involved. That was pure ignorance on my part; when I first switched to Linux it surprised me how much was involved in getting that character up on the screen.

As recently as two years ago, the average deployed Linux system had inconsistent font support -- some applications were not able to access all the installed fonts on the system, some applications were incapable of anti-aliasing, and a user trying to sort it out quickly became mired in an alphabet soup of confusingly-similar terms: TrueType, OpenType, FreeType, Type 1, et cetera.

Today the situation is greatly improved, putting Linux on comparable footing with commercial operating systems for font-intensive tasks like desktop publishing. This article aims to clear up that confusion about the different font types and how Linux (and other Unix-like operating systems) incorporates them into the user experience.

Where do fonts come from, Mommy?

Quick: what exactly is a letter? How do you define it? Think back to what they taught you in school when you first learned how to write. The letters of the alphabet were defined as sets of lines that connected in a particular way. It didn't matter how thick or thin the lines were. Sometimes they were slanted and sometimes straight. You could write them in any size. But as long as they connected in the right places, they were still the right letters.

That's at the heart of the difficulty with digital fonts: our alphabets are defined by lines, but computers output all their graphics with dots (either printed or phosphors).

The earliest digital fonts were nothing but dots: monochrome bitmaps. Every character was handmade for each available point size, ensuring that they would be clear and legible at those point sizes, but forcing interpolation if you wanted a size that the font foundry did not supply -- leaving jagged edges when increasing letters in size and indistinct blobs when decreasing.

For real scalability, there was no alternative but to create fonts that defined their characters with smooth curves -- what we call "outline" fonts.

In the late 1980s, the two major systems vendors, Apple and Microsoft, and software maker Adobe, which led the desktop publishing revolution, all agreed on this. Adobe was pushing its PostScript technology for printers, and tried to get the systems vendors to license the new, scalable "Type 1" font technology it had designed to go with it. But Apple and Microsoft were wary of the idea, because although PostScript was an open standard, Type 1 was closed and proprietary.

So, rather than hand full control of their operating systems' font technologies to a third party, the two companies struck a deal with each other. Apple would produce its own outline font standard, Microsoft would produce a PostScript-compatible interpreter, and they would swap. Microsoft's PostScript alternative TrueImage more or less died on the vine, but Apple's new font format caught on and became what we call TrueType today.

TrueType vs. Type 1

Adobe's Type 1 and Apple's TrueType have remained the most widely used and important font formats ever since. The Type 1 format was reverse-engineered years ago, but both have persisted (even on Unix-like systems that did not receive vendor-support) because they are technically incompatible.

The two formats share the same basic ideas, but differ in implementation. Both contain a "glyph table" containing the outlines for every glyph in the font face. A glyph can be a single character or a ligature of two or more characters. In the Latin alphabet, the most common examples of ligatures are the fl and fi combinations, but other alphabets (such as Arabic) make much more widespread use of ligatures.

The first difference between the formats is that Type 1 uses cubic equations to define the curves, while TrueType uses quadratics. In theory the Type 1 model could describe each glyph using fewer control points, making the glyph table smaller, but because the math involved is more complicated each glyph would take longer to rasterize (meaning to convert to a bitmap, which is the final destination of all outline glyphs). The truth is that there is no significant time or space savings for one format over the other on modern systems.

The second difference between Type 1 and TrueType is in the hinting tables. Hinting refers to a number of methods the font creator can employ to ensure the best readability at different point sizes. This is necessary because the glyphs in the font table are defined as shapes on an abstract grid called an em square (a term from pre-digital typography used to draw the glyphs at a consistent scale to the same baseline; named originally because it was the width of the generally largest glyph, "M").

This means that whenever glyphs are rasterized to a display device, care must be taken to ensure that the shapes align properly with the physical dot pattern of the display grid, not halfway in between. Were it not for hinting, a lowercase "l" placed right on the border between two columns of screen pixels would be rendered as a blur.

Also, for small point sizes it is frequently necessary to adjust the width or height of the glyph just to make sure that all of its characteristics remain visible. A good example of this would be the lowercase "g" and "q" glyphs, on which it is vital to be able to see on which side the descender connects to the circle. Consequently, the descender may be proportionally longer when rendered at a small point sizes than it is at larger size.

Fonts may also contain kerning information, which tells the rendering engine how to adjust the space between glyphs, to minimize awkward gaps, as in the two-letter pair "AV." Without adjustable kerning the whitespace between these letters is much larger than between other pairs of letters, which adversely affects readability.

The Type 1 hinting system lets the font creator mark and specify the important features of each glyph, such as the main lines or "stems" and distinctive overhangs. It is then left up to the system's rendering engine to line up these features on exact pixel boundaries to ensure clarity.

The TrueType format, on the other hand, has a much more complex and powerful hinting system -- rather than a simple table, it actually includes a virtual machine the font creators can fully program. TrueType hints can be specific down to per-pixel placement for any and all specific point sizes, leading some to refer to it as less of a hint and more of an order. The advantage of this system, according to TrueType boosters, is that it enables far better hinting, even if it does so at the expense of increased font file sizes. Adobe maintains that the Type 1 system is superior because it leaves more up to the rendering engine, so any improvement to the renderer improves every font at every size, something TrueType cannot claim.

A grand unified format

The fact that TrueType and Type 1 were so similar, yet not the same, was a source of frustration both to desktop publishers and to font foundries, which had to produce their fonts in both formats. Prior to Type 1, there were essentially no standard formats, but when it comes to standards two is still a lot to choose from.

Looking at it mathematically, a quadratic curve (like those used to define a TrueType glyph) is just a cubic curve with a zero in the cubic coefficient, so you might think that it would be easy to convert glyphs from TrueType to Type 1. That would be true, except that TrueType and Type 1 fonts also use different grid systems to describe their glyphs; the Type 1 grid is 1,000 units wide, while the TrueType grid is 2,048. That makes automatic conversion imprecise at best, and the difference in the hinting systems is impossible to bridge.

It doesn't happen much, but sometimes conflicting standards give rise to an improvement that benefits everyone. In 1996, Adobe introduced OpenType, a new format that can encapsulate both Type 1 and TrueType fonts, and introduces some newer features as well. The current versions of Windows and Mac OS X both include built-in support for OpenType. Currently only a handful of font foundries are producing OpenType fonts, but Adobe halted production of new Type 1 fonts in 1999 and has built its all of its graphic design applications with OpenType support. Further adoption of OpenType is a sure bet, and will simplify the decisions of end users.

X marks the font

As great as Type 1 and TrueType are, none of it matters unless your OS supports the right font format.

On the graphical Unix-like systems of yesteryear, X Windows provided the fonts directly through the X server. These X fonts were bitmaps like their contemporaries on other systems, and could be used only at the point sizes provided by the font maker. Modern Linux distributions still supply these bitmapped fonts; they are part of the standard releases of XFree86 and X.org and are necessary for legacy application support.

With it of 4.0.2 release, however, XFree86 introduced a new extension to the X protocol called Xft to enable the use of scalable fonts. Xft provides a set of routines that substitute for the core X text-handling functions, allowing applications to be easily ported. But Xft hooks into the FreeType library, an open source scalable font renderer that supports Type 1, TrueType, and OpenType fonts, in addition to a number of less common formats. FreeType is modular in design, with a separate "font driver" for each font type it supports. If a new format comes to prominence, FreeType can add a font driver for it without making changes to the rest of the FreeType engine.

When an application needs to write text to the display, it calls on Xft, passing it the string and the font face that it requires. Xft must then determine which specific font is required if more than one match, as in the case where a scalable and bitmapped version of the same font are available. It then sends the character codes it needs to FreeType, which finds the appropriate glyph in the font file, scales it, and rasterizes it.

FreeType hands back to Xft an 8-bit greyscale rendering of the requested glyph, regardless of what colors might be of interest to the application. It's up to the application to transform the greyscale glyph into another color or bit-depth, or composite it onto some interesting surface. Most X11 applications today are written with higher-level toolkits like GTK or Qt, and these toolkits supply the transformative power that FreeType itself does not directly provide. So if you use the right toolkit, Xft and FreeType support is automatic, and you gain additional font-handling capabilities as well.

If you need to dive into FreeType font details, you can download FontForge, an X11 program that can open font files and allow you to see (and, if you're brave enough, alter) the TrueType and Type 1 glyphs that FreeType renders.

There are some applications where toolkit-level support is not good enough, simply because they need to allow users to manipulate text at will. Word processors and desktop publishing applications are the most obvious examples, where enabling fully manipulatable text is the primary purpose of the program. These applications therefore have to interact with the system's font handling libraries directly, which is part of why it took them longer to fully incorporate Xft.

The same is true of image-manipulation programs like The GIMP, which can depend on GUI toolkits for Xft support in their interface but must provide their own more complete font-handling options for the user.

Limitations in FreeType

There is one key area in which FreeType cannot compete with its counterparts in other operating systems: hinting of TrueType fonts. I mentioned earlier that TrueType fonts use a powerful virtual machine to describe complex hints. The trouble is that Apple has three patents on particular methods of using this hinting data, and although the patents by no means cover all the methods needed to perform TrueType hints, they leave software developers with a choice: either license the patents from Apple or build an incomplete interpreter into your TrueType rendering engine.

The FreeType 1.x series came with a built-in TrueType bytecode interpreter, simply because it was coded before the patent situation was publicized. The FreeType 2.x code could be compiled with the bytecode interpreter turned on, but the FreeType project does not provide it in any binaries, nor (as far as I am aware) do commercial Linux vendors.

Without a built-in TrueType hinter, the only available option is to try and hint the glyphs just as you might for a font that came without hinting altogether, and this is what FreeType does. The FreeType autohinter is used for fonts that have no hinting tables, and is no worse at hinting TrueType fonts with legally encumbered hinting. Of course, improving the quality of the FreeType autohinter is a topic of great debate and much ongoing work. Type 1 font hints, having no such patent issues, are fully supported by FreeType.

Configuration

The last piece of the font-handling puzzle is called fontconfig, a library to simplify finding and accessing the fonts on a given system. Fontconfig can autodiscover the fonts installed on your computer, automatically find the correct font for a given language or character set, and let you configure your own personal font preferences (including substitutions) with XML configuration files.

Fontconfig does not render glyphs or process fonts in any way. It simply assists other programs in accessing your font collection, so that you do not have to search for fonts manually and so that when a particular font is unavailable, the program expecting it can find a replacement and recover gracefully.

End of the line

Ben Franklin and his printing-press contemporaries had it relatively easy; they cast their blocks of type out of metal, as smooth and as ornamented as they could afford to cut them. Today we expect much more from our fonts: scalability, kerning, hinting, and a thousand different typefaces to choose from.