2. Why Fonts on Linux Aren't Straight Forward ?
Jump to Section 3 if you just want to fix your desktop fonts fast. Read this section if you are interested in the details on how and why make it.
Fonts are used on the screen and for printing. These medias differ a lot in DPI resolution: screens have 72 to 96 DPI, while modern printers use to have 300 DPI. So low-resolution medias as the screen need better font rendering algorithms to workaround the media's limitations.
To get optimal fonts on the screen you need:
Good fonts designed for low resolution media.
True Type font technology evolved to be the best thing you can get nowadays. But for optimal screen beauty, you also need fonts that were designed for this purpose. We found that Tahoma and Verdana are the best fonts you can get for the screen.
A good font renderer.
Current Linux distributions include the excelent and very mature FreeType font renderer library.
A .ttf file contains information to draw the characters at any size, so you eventually can convert a text into a scalable outline drawing (built from line segments and quadratic bezier arcs) with tools like OpenOffice.org or CorelDraw.
Font drawing algorithms are extremely complex because they have to decide which pixels to highlight based on the mathematical equations inside the .ttf file. When you need text in big sizes like 48 or 60, one or two pixels these algorithms "forget" to highlight doesn't make much difference, but when you need text at size 8pt or 11px, each pixel counts. And these use to be the text size for KDE and Gnome widgets, text for web browsing, and almost everything else we see on the screen.
To solve this problem more efficiently, beside of the mathematical equations inside a .ttf file, a font designer (a human being with a font creation software) also put some extra information to help the font renderer make correct decisions for this small size text. This process is called grid-fitting or hinting.
The point is: the technologies to interpret this hinting information are patented by Apple, and they are commonly called True Type Byte Code Interpreters (or simply BCI in our document, from now on).
With reverse engineering, the Freetype Project has implemented a byte code interpreter, but due to legal issues in some countries, some Linux distributions disable it at compilation and packaging time. This is a list of distributions that are known to enable or disable BCI. Please send us updates.
Table 1. FreeType Bytecode Interpreter Status per Distribution
| Support | No Native Support |
|---|---|
| Conectiva | Mandrake |
| Gentoo | Red Hat, Fedora |
| SUSE |
FreeType tries to workaround this legal issues developing autohinting algorithms, but in our tests, BCI algorithms gave us much better font rendering results on the screen.
2.1. X.org Font Subsystems
At the present time, X.org and XFree86 use two font subsystems, each with different characteristics:
The original (15+ year old) subsystem is referred to as the "core X font subsystem". Fonts rendered by this subsystem are not anti-aliased, are handled by the X server, and have names like:
-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1
The newer font subsystem is known as "fontconfig", and allows applications direct access to the font files. Fontconfig is often used along with the Xft library, which allows applications to render fontconfig fonts to the screen with antialiasing. Fontconfig uses more human-friendly names like:
Luxi Sans-10
Over time, fontconfig/Xft will replace the core X font subsystem. At the present time, applications using the Qt 3 or GTK 2 toolkits (which would include KDE and GNOME applications) use the fontconfig and Xft font subsystem; most everything else uses the core X fonts.
In the future, Linux distributions may support only fontconfig/Xft in place of the XFS font server as the default local font access method.
 | An exception to the font subsystem usage outlined above is OpenOffice.org (which uses its own font rendering technology). |