This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


A font primer for Linux

By Nathan Willis on October 12, 2004 (8:00:00 AM)

Share    Print    Comments   

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 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.


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.

Share    Print    Comments   


on A font primer for Linux

Note: Comments are owned by the poster. We are not responsible for their content.

Excellent Article

Posted by: Preston St. Pierre on October 12, 2004 09:31 PM
A good, well layed out article on something I didn't have any idea about. Thank you.


nice, but still ...

Posted by: Anonymous Coward on October 12, 2004 11:01 PM
Nice article (although nothing new there for me, I bet new stuff for most other readers).

The problem is, though: font-rendering still sucks in comparison to OS X and M$ windows<nobr> <wbr></nobr>:(


Re:nice, but still ...

Posted by: Anonymous Coward on October 12, 2004 11:22 PM
Compared to Mac OS X, yes. Not in any way compared to Windows IMHO.
I have two boxes right next to each other here, one running Fedora Core 2 (with Gnome 2.6) and one running WinXP.
The Fedora box renders fonts way better than the XP box in my opinion.


OSX OSX OSX, garbage.

Posted by: Anonymous Coward on October 13, 2004 03:44 AM
What is it with OSX that makes people fawn over it so much. I work beside a mac guy, and OSX's vaunted interface looks like a fancy version of CDE (How come no one has noticed it? Its almost identical looking!) and its fonts looked worse then mine on Linux anyway. Lousy theming support and the universes most overrated GUI.

Its not even nice looking, its just a combination of the usual Mac look and CDE. Its fonts are just the same as everyone else has, nothing new or magically better about them. Make sure your fonts are setup correctly, and take a close look. The method used to antialias might be different, but linux's renderings are by no means whatsoever inferior.



Re:nice, but still ...

Posted by: David Breakey on October 12, 2004 11:40 PM

The big difference between Linux and Windows now, as far as I can tell, is that Linux renders typefaces consistently. Windows, on the other hand, while handling anti-aliased rendering very nicely in those places where it does, still has many locations in its interface where the rendering is handled inconsistently (one example that comes to mind is the login dialog in XP).

As for which one is better, well…I'd have to marginally side with Linux on this one. Although the rendering quality on Windows is very good, it seems to me that Linux, via <A HREF="" title="">FreeType</a>, fontconfig and the like has a better aesthetic appeal, but only in more recent desktop environments that are properly configured.


Re:nice, but still ...

Posted by: Anonymous Coward on October 17, 2004 08:51 PM
Being author of the post "nice, but still<nobr> <wbr></nobr>..." all I can tell you - there is no consistency on linux in regards of font-rendering. Did you ever experience a slight difference between XFT2 and freetype? Yes, there are inconsistencies.

Of course, one can always try to keep configurations in sync or even write scripts that would do that for you<nobr> <wbr></nobr>... but - although I hate to say that - M$ did it better this time.

And yes, we have to get Apple to the point that they'll either sell individuals a license or grant the opensource scene an 'open license' (although the latter I guess will never happen).


Nice article but...

Posted by: Anonymous Coward on October 13, 2004 01:12 AM
Nice article as I knew next to nothing of these issues. However, could you write a followup article that explains how to configure/use fonts under Linux?

Is it possible to use nice Open/True Type<nobr> <wbr></nobr>/1 fonts from the console or are bitmapped fonts the best we can do?


Nice article

Posted by: Anonymous Coward on October 13, 2004 04:46 AM
Very well thoughout and written! Keep writing.


And now...

Posted by: Anonymous Coward on October 13, 2004 05:04 PM
Now that you know the theory you may want to start practising and actually use some fonts on your system:

Check out the <A HREF="" title=""></a> and the <A HREF="" title=""> </a> selections

Look up a list of other <A HREF="" title="">
open fonts out there </a>

<A HREF="" title="">
and configure them for your environment</a>.


Wow! A clueful article for a change!,

Posted by: Anonymous Coward on October 13, 2004 09:24 PM
Keep writing, keep it up, more more, give us more!


good article, ends too abruptly

Posted by: Anonymous Coward on October 13, 2004 09:58 PM
Well written--thanks. Only one confusing area where I felt and alternate example (or no example at all). But the article really should have been longer: it ends after a nice explanation of some complex matters, but needs to go on to practical application of those complex matters. Please make this a series of articles on thiese issues.


Re:good article, ends too abruptly

Posted by: Anonymous Coward on October 16, 2004 11:31 PM
I agree. It was a great read but leaves the reader wanting more... MORE I SAY!


Nice article

Posted by: Anonymous Coward on October 14, 2004 03:07 AM
Very nice article, thanks!


bytecode interpreter

Posted by: Anonymous Coward on October 17, 2004 07:31 PM
For those gentoo users out there : freetype's bytecode interpreter is available through the "bindist" USE flag.


Re:bytecode interpreter

Posted by: Anonymous Coward on October 18, 2004 08:09 AM
That would be "USE=-bindist", just to make sure<nobr> <wbr></nobr>:)



Posted by: Anonymous Coward on October 17, 2004 10:28 PM
Hey, and what are those Speedo fonts down there in my<nobr> <wbr></nobr>/usr/X11 dir?



Posted by: Anonymous Coward on October 18, 2004 06:21 PM
no, really<nobr> <wbr></nobr>:)
one of the best articles i have had a chance to read lately. added to favorites, just in case i would like to refresh my memory<nobr> <wbr></nobr>;)


PLF Provides FreeType Binaries With TT Hinting

Posted by: Shlomi Fish on October 19, 2004 04:15 PM

Hi, I just wanted to note that
<A HREF="" title="">the Penguin Liberation Front (or PLF for short)</a> - a set of packages for Mandrake, provides a FreeType package with the True Type hinting turned on.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya