Unix Font Rendering FAQ
(c) 2002 David Turner
Table Of Contents
- what is a font ?
what is a bitmap font ?
what is a “char cell” font ?
what is a scalable font ?
what is font hinting ?
what is TrueType hinting ?
what is Postscript hinting ?
what is Auto-hinting ?
what font formats are supported by X11 ?
how does X11 render text ?
does X11 support anti-aliased text ?
how does anti-aliased text work then ?
why do my fonts look crap ?
why some anti-aliased TrueType fonts do not look good ?
Basic Font Rendering FAQs
X11 Font Rendering FAQs
This FAQ covers many common questions regarding the rendering of text on a typical Unix desktop (i.e. Linux, BSD and legacy systems like Solaris, etc…). Note that it doesn’t deal with various other topics likefont installation, printing and international text layout. These may be the subject of other documents in the near future, but don’t hold your breath 🙂
Basic font rendering FAQs
What is a font ?
Glad you asked 🙂 The term “font” is often used in very different ways and it’s hard to define what it really means without context. Generally speaking, one has to distinguish the following elements:
- typographic families are defined as groups of graphical character images that share the same important visual properties, though can vary in style. “Arial”, “Times New Roman” or “Courier New” are well-known font family names used in the Windows world, for example.
- typographic faces corresponds to different “styles” in a given family. For example, “Arial”, “Arial Italic”, “Arial Bold” and “Arial Bold Italic” correspond to different faces of the “Arial” family.
- font files are used to store character images. A given font file may contain one or more faces, even from distinct families, depending on its format. Moreover, a single face is only defined by the use of several font files, in certain cases.
Depending on context, the term “font” will designate either a family or a face. For example, when selecting a “font” within a word processor dialog box, you usually first really choose a family, then its style (regular,italic,bold,italic,wathever). But when you look at font files themselves, these usually only contain one face per file (though more complex cases exist).
We will thus try to avoid the term “font” in the rest of this document, except when the context makes it explicit.
What’s in a font file ?
It contains character images (called glyphs), as well as metrics used to layout text correctly. It may also contain more advanced tables to support sophisticated layout operations (like ligatures)
A font file may contain data for one or more faces or families, depending on its format. It may also only contain partial information related to a given face, and should then be used in association with other files.
What is a bitmap font ?
It’s usually a font file that contains character images stored directly as bitmaps (either monochrome, coloured or anti-aliased). Note that bitmaps are specific to a single character size, which may limit the use of the font file to certain surfaces. A bitmap font file might contain images for one or more character sizes, as well as data for one or more faces and/or families.
Sometimes, the term “bitmap font” refers to a collection of bitmap font files, used to implement various character sizes of the same face.
What is a “char cell” font ?
It’s a bitmap font file where all glyph bitmaps have exactly the same size (and much probably the same metrics). These font formats are simple to write and process; however, they are very inefficient in terms of memory use, except in certain specific cases. For example, any PC BIOS contains a small char cell font used by the system to display text at boot time
This is not to be confused with a monospace font, where all glyphs have the same metrics, like “Courier”, even if their images may have distinct dimensions.
What is a scalable font ?
It’s a font file whose glyph images are not stored as bitmap, but as vectorial “shapes”, called outlines, that are usually described through line segments and bezier arcs (though other scalable geometric models exist too). The advantage is that the same “master” glyph image can easily be scaled to any character size. Or it can be rotated, sheared, stroked, dashed, etc…
On the other hand, they’re significantly slower to process (each scaled outline needs to be converted into a bitmap before being displayed, and this takes time), and do not generate legible results at small pixel sizes without hinting.
What is font hinting ?
This is again an ambiguous term, whose meaning differs slightly with context. Fact is that simply scaling outlines found in a scalable font will nearly never produce pleasant text, due to the discrete nature of the pixel grid (or the doth mesh on a paper when printing).
To significantly improve the appearance of scaled glyphs, a specific process is needed to distort the vectorial outline in order to align it to the pixel grid. This process is generally called grid-fitting and it is also generally described as hinting.
However, knowing how to distort the outline optimally is a really hard problem that hasn’t been completely automated to date. Instead, font designers must manually include with each glyph of its font file some additional information, called “hints”. The process of adding this data is also called font hinting by professional typographer.
Hints are used to help the font engine perform optimal grid-fitting, and their nature differ greatly with the font format. They’re usually difficult to get right the first time, or even understand without the help of additional tools. Which means that creating them can be extremely time consuming.
both interpretations are absolutely critical to outputting legible and pleasant text from scalable font files, be it on screen on on paper (except for very high printer resolutions). However, it is dependent on the quality of the hints themselves. Which means that a poorly-hinted font will always look bad.
What is TrueType hinting ?
In the TrueType format, the glyph hints are actually small programs encoded with a specific bytecode written for an abstract little stack-based virtual machine !! Each program is in charge of distorting the outline using geometric-specific operators that directly affect its control points.
As a result, the hints have extreme control about the end result and can be tailored to look absolutely gorgeous at any size, if the font designer takes the time to write them correctly. Very unfortunately, creating those programs is also very time consuming, even when graphical tools are used to do it. and they can take significant room within the font file.
As an example, we’ve been told that MonoType took about 12 man-years to design the “Times New Roman” family (i.e. its 4 faces) for Microsoft !! The difficulty of properly hinting TrueType fonts certainly explains why, while there are still a few gems whose quality is unmatched, so few TrueType fonts available today have any decent look on screen.
Another important annoyance with TrueType hinting is the fact that it is patented, and thus cannot be used freely.
What is Postscript hinting ?
In the Postscript format, the glyph hints are much, much smaller, since they only describe high-level “features” of the glyph outline, i.e. “stems” and “top/bottom edges”. It is up to the font engine to use them intelligently to optimize grid-fitting.
Depending on the cleverness of the algorithm being employed, this results in text quality that can range from poor to good, but will generally never exceed the capabilities of a highly-hinted TrueType fonts. However, these hints are generally much easier to design, making the font designer’s work much more enjoyable.
In short, creating high-quality hinted Postscript fonts is a lot easier than with TrueType, even if it still takes time.
What is auto-hinting ?
It is the process of automatically determining the best “hints” for a given scalable font file. This is usually done by performing global analysis of the set of glyph images available, as well as decomposition of individual glyph outlines in more high-level typographic “features”, like “stems”, “bows”, “serifs”, etc…
In all cases, it’s an algorithm that can be applied either at font design time (several font editors provide auto-hinting capabilities today) to ease a font designer’s work, or even at run-time (the FreeType 2 font engine is capable to automatically analyze glyph outlines at load time)
The quality of auto-hinted text depends entirely on the algorithm’s intelligence to guess good values. It also depends on the target output format, since one should not try to hint monochrome and anti-aliased text in the same way.
The advange of such technique is that no additional work is required from the font designer that can focus on drawing and metrics adjustments instead. On the other hand, the quality is not always as good as it could be when manually hinted, especially with complex glyphs (like asian ideographs).
X11 font rendering FAQs
What font formats are supported by X11 ?
First of all, the X11 protocol doesn’t deal with font files directly. It simply considers that a “X11 font” is simply a set of monochrome bitmaps, for a given face and character size (among other things). And that’s the end of it !!.
The bitmaps themselves are exclusively provided by the X11 Server, which may generate them itself (when it includes a font engine), or query the X11 Font Server to do that. In all cases, standard X11 applications have strictly no way to know where the glyph bitmaps come from or how they were generated.
So, knowing which font formats are supported, or where font files are installed/located depends on the implementation of your X11 Server, or of the X11 Font Server, which itself depends on your system’s setup.
If you’re using XFree86 display and font server (which is the case for all Linux and BSD systems), you’ll be able to use fonts in the following formats: PCF (bitmap), BDF (bitmap), Postscript Type 1, Postscript CID-keyed, Speedo (an obsolete scalable format). Additionally, certain builds of recent XFree86 servers can support TrueType fonts as well.
For other servers, your mileage may vary greatly 🙂
How does X11 renders text ?
Well, the X11 Server can render all font bitmaps itself when it includes its own font engine(s). Another alternative is when the X11 Display Server calls an independent X11 Font Server whose role is to produce the bitmaps. Note that in both cases, the resulting bitmap will still be monochrome.
The quality of these bitmaps depends on the font engines being used to render them. For example, XFree86 includes a Type 1 rasterizer which is known to produce mediocre results, while Sun’s OpenWindows does a decent job with the same font files.
For a long time, a good way to improve text quality was to use a TrueType font engine with good fonts in this format, either by incorporating it directly in the display server (XFree86 can be built with a copy of the FreeType 1 sources, for example), or use a TrueType-aware font server (XfsFt or Xfstt). Ignoring all patent issues, of course 🙂
Does X11 support anti-aliased text ?
The X11 protocol does not support anti-aliased text, and modifying it to do that would be difficult. This is due to the fact that the standard X11 rendering model is only capable of performing logical operations (like AND/XOR/OR/NOT) on pixel values, while arithmetic ones (ADD/SUB/MUL) are needed to implement anti-aliased text, as well as translucency, correctly.
The “Render” XFree86 extension was created to add this type of capabilities to the X11 Server. While the extension isn’t finished yet, it’s still sufficiently workable to allow anti-aliased text to be displayed, as long as the applications or toolkits do not use the standard X11 text calls but something different !!.
The only way for a legacy application to display anti-aliased text through standard X11 calls is to have a “hacked” X11 Server that performs text drawing operations differently. See this page for an example. Such technique is non standard-conformant and even likely to break certain (rare) applications however.
How does anti-aliased text work then ?
As said before, applications that want to display aa text needs to call something different than standard X11 font APIs, because these are simply too limited. There are several ways to perform this from a developer’s point of view:
- do everything yourself
which means calling a font engine (like T1Lib, FreeType 1, FreeType 2 or anything else) to render glyph images directly in your application. You’ll then be able to render individual anti-aliased glyph bitmaps. However, these cannot be sent directly to the X11 server (remember, its rendering model doesn’t support additive composition).
instead, you’ll end up performing all of the composition within your application, which will probably be slow, and require vast bitmap transfers between you and your program. It may seem impressive, but it works quite well with the horse-power of current machines.
This is the way programs like Ghostscript, FrameMaker, XPDF, and many others deal with aa text from the very start. One big problem with this approach is that you need to implement everything yourself, including font installation and matching. Each application having its own way to “install” and “list” fonts makes for a rather unpleasant user experience.
- use a patched X11 Font Server
one way to solve the font installation/matching problem is to use a patched X11 Font Server that is also capable of producing anti-aliased glyph bitmaps, through additional APIs. You’ll still perform composition and caching within the application, but will be able to share, in theory, the list of installed fonts with other applications.
the problem with this approach is that it may not be possible to change the default font server on certain systems, especially Unix ones. There are also many different problems with fonts that cannot be solved by this setup too. Well, some companies still try to sell this “solution” though but it certainly isn’t going to be a standard !.
- use the “libXft” library
- it uses FreeType 2 to render all anti-aliased glyphs (hence the stupid library name 🙂
- it provides its own font installation and matching APIs which, among other things, allows applications to directly access the font files when they need to.
- it uses the “Render” extension to draw the glyphs. Each glyph image it sent only once to the server where it stays in a cache. All composition operations are performed in the server and may be hardware-accelerated.
“libXft” is the first version of a library written by XFree86 to use the “Render” extension in order to display aa-text easily. It has now been replaced by “libXft2″n described below but describing it is important. It does the following:
“libXft” is special because all aa bitmap generation is done in application space, while glyph composition is performed in the server. Note also that it requires the “Render” extension in the X11 server to display aa text. It will default to “core” (i.e. standard) monochrome fonts otherwise.
Though it still works, it has been deprecated by libXft2.
- use “libXft2” and “fontconfig”
“libXft” was recently rewritten and splitted into two distinct sub-systems named “fontconfig” and “libXft2” respectively. This was done to separate the font installation/matching APIs from the rendering APIs.
This has the benefit of allowing non-graphical applications (like the Ghostscript interpreter, for example) to access the list of installed fonts without an X Windows installation. Making thus unified font installation a possibility, once every important toolkit and program uses “fontconfig” to perform this task.
Meanwhile, “libXft2” now contains code to deal with aa-text display when the X11 Server doesn’t have a “Render” extension. It does so by performing composition within the application space itself, allowing applications that use it to display correctly (though slowly) even on “legacy” systems like Solaris where changing the X11 Server isn’t possible for most users.
Note that in all recent Linux and BSD distributions, anti-aliased text is always rendered through the FreeType 2 library (whose purpose is only rendering, not installation or text layout). For monochrome text, things are still vastly different based on the platform and distribution.
Why do my fonts look crap ?
First of all, it may be because your fonts are simply crap. Yes, this happens (for example, some version of the “Nimbus” fonts distributed with Ghostscript contain buggy or invalid hints). Otherwise, it really depends on which code is generating the glyph bitmaps, which depends on the application you’re using:
- if it’s a legacy X11 application, you should blame either the X11 Server, or its Font Server, for doing a poor job. You’ll need to upgrade either one to get better text. With a few good luck, you might be able to get a TrueType-patent-enabled server to render correctly your Windows fonts.
the same is true for a GTK 1 and Qt 1 applications, where everything is done through normal X11 calls.
- if it’s a recent GTK 2, Qt 2, Qt 3 application, chances are that they will be using “libXft” to render text. Meaning that you should update your version of FreeType 2 to get better text. Try release 2.1.3 or beyond, it’s a nice one 🙂
- if the application renders text itself, like GSView, GGV, XPDF, KPDF, Sketch, AbiWord and many others, you’ll need to wait that they update their font engines, or start using “fontconfig” and “libXft2” when needed.
Hopefully, every significant application should use “fontconfig” and/or “libXft2” in the near future, which means that font rendering quality (as well as font installation and matching) will finally be controlled in a single place on a Unix system. In such cases, simply upgrading your version of FreeType 2 should be enough to “improve” your fonts, whenever possible.
In the meantime, good luck with the current mess 🙂
Why anti-aliased TrueType fonts do not look good ?
If your build of FreeType 2 has the TrueType bytecode enabled, you may notice that certain characters exhibit unpleasant artefacts.
The reason is that the hints contained in the TrueType fonts are generally written to optimize monochrome text by font designers. Given the pain of writing correct TrueType hints, that’s understandable. What you’re seeing are “defects” that are generally never visible from monochrome text, but revealed by the high number of gray levels used for anti-aliasing. Under Windows, anti-aliasing is only enabled for relatively big character sizes, so font designers have no point in optimizing “small” ones for anti-aliasing.
There is unfortunately nothing we can do, since we cannot modify the fonts. An alternative, however, is to simply disable the bytecode interpreter and use FreeType 2’s auto-hinter to render TrueType fonts in anti-aliased mode. (In most cases, this simply means loading the latest version of the library, building and installing it). While the quality of monochrome text will lower, in many cases the auto-hinter will be able to produce results that are significantly better anti-aliased !!