Font rendering and text layouting
|Line 39:||Line 39:|
</noinclude><includeonly>See also [[Font_rendering_and_text_layouting|this article]] for additional information.</includeonly>
<includeonly>See also [[Font_rendering_and_text_layouting|this article]] for additional information.</includeonly>
Revision as of 10:02, 26 June 2008
Modern text rendering is a complex process that involves many components:
- font files,
- a font discovery and substitution library,
- a font rasterizer library,
- a text layouter library,
- the settings the application passes to those components, sometimes taken from Xorg.
It all works roughly that way:
- application passes:
- a string of unicode points,
- language information,
- target media dot density, DPI (used to convert font sizes in universal units like points to measures in number-of-dots)
- desired font (name, variant, size)
- the font discovery and substitution library is used to find the requested font, and complete it/replace it with other fonts if needed (typically, requested font not present or lacking some of the glyphs needed to render the unicode string). If this library is misconfigured non-optimal substitutions will happen.
- the text layouter library positions the glyphs based on the language information, in-font information tables, and internal library rules. It can choose to replace some glyphs with others (ligatures, etc)
- the font rasterizer library renders those glyphs to the target media dot density. Unfortunately computer screens typically do not have a pixel density high enough to do direct glyph scaling without getting human-visible rounding artifacts. The rasterizer library must distort glyph shapes so they fit as much as possible in the pixel grid. This distortion process uses either in-font instructions (hints) and a patented algorithm, or on FLOSS systems like Fedora a process called autohinting.
The root cause of a text rendering problem can occur at any of those stages, in any of the components involved. Identifying the problem and getting it fixed will therefore often require interaction with the font designers and the developers of several of those software components. While not overly difficult or long, QA process on text rendering is not for fly-by bug reporters.
The FreeType library is used for virtually all font loading and rendering within the Fedora desktop. It contains supports for a great variety of Fonts formats, from Type1, to TrueType/OpenType, and bitmap formats like PCF and BDF. Nowadays Fedora converges on OpenType (TTF/OTF) fonts in Unicode encoding, and no efforts should be wasted on legacy formats.
Moving one layer up from FreeType, once we've taken a font outline and converted it into an image, we have to send the image to the screen. The Xft library is designed to do this. On modern X servers, it uses the RENDER extension to draw fonts to the screen. For older X servers, it contains fall-back code to do the same rendering through the core X protocol, though less efficiently.
While virtually everything in Fedora renders fonts using the FreeType library and Xft, there is much more diversity in how text layout is done. Text layout for scripts such as Latin or Cyrillic is relatively straightforward. The simple capabilities built into Xft are almost sufficient. But languages such as Arabic and Hindi require more intricate handling. The characters in the input string interact with each other and sophisticated processing is required to determine the right set of glyphs to be drawn to the screen. Right-to-left languages like Arabic and Hebrew are also challenging.
Currently, the Pango library is used by GNOME and other programs based on the GTK+ toolkit for text layout. KDE and other programs based on the Qt toolkit use code built into Qt for the same purpose. OpenOffice.org uses layout code from the ICU library. Nevertheless the current Qt code and the OpenOffice.org layouter are increasingly inadequate.
If text layouting is approaching at last typographer requirements, modern "smart" fonts are several orders of magnitude more complex than previous fonts (and people make use of the new features and expect them to work). The code needed to interpret those fonts is correspondingly more complex. In fact it's getting at the level of complexity big projects are dropping their own text layouters fast and trying to converge on a common text layout library. HarfBuzz will probably dominate free desktops in the coming years.
<ref>tags exist, but no
<references/>tag was found