|
X Windows'
lack of TrueType Font Engine Various proprietary scalable font engines were added by proprietary Unix vendors in an effort to combat the bitmap font problem. Scalable fonts contain only an outline, or description, of how the font should be drawn, as well as some hints on how to handle very small point sizes. Theoretically, scalable fonts can be displayed at any size without any of the "blockiness" inherent to their bitmapped siblings. Several of these engines were even donated back to the X Consortium, who maintained the core X Window System, as Free Software. IBM donated a PostScript Type1 font renderer, and BitStream a renderer for their proprietary Speedo type format. Unfortunately, the Type1 engine does a rather poor job with small font sizes, and the Speedo font format has largely been supplanted by other formats. As Apple and Microsoft made TrueType font technology the de-facto standard in the 1990's, Linux users were largely left out in the cold. X Windows'
Cryptic Font Configuration Model Printing
System Didn't Share Fonts The Solutions The first problem was addressed by integrating an excellent Open Source TrueType font rendering engine called FreeType. FreeType is a comprehensive library for accessing and manipulating TrueType fonts; it is not particular to X Windows. There are a number of different solutions for integrating FreeType into X, and Red Hat decided to use the xfsft system written by Juliusz Chroboczek. It maintains the most compatibility with the legacy font system, removing none of those features. Xfsft was added directly into our build of the X Window System, making it available both through the X server and xfs, an independent daemon for providing fonts. To solve the X font performance problems, Red Hat decided to make more extensive use of the X Font Server (xfs) than in the past. While originally designed as a solution for providing fonts to other X servers in a network-transparent fashion, xfs provides a number of benefits when used directly on the local host computer instead of having the X server provide fonts. First of all, when X requests fonts that have not previously been displayed, the font server can render them in parallel to the X server's own tasks, such as painting windows on the screen. Previously, while the X server was computing a font, all window system activity stopped and even the mouse became slow and jerky. The effect was especially noticeable on lower-end equipment. Xfs has solved these problems. Xfs also solves most of the X font configuration issues as well. Configuration information for the font server is stored in /etc/X11/fs/config. The most important section deals with the set of directories forming the path to search for fonts. While it is good that this buys us a location separate from the X display configuration file for font configuration, it is even better when this is updated. The server can automatically inform a running X server that fonts have been added or subtracted, transparently to the user. There is no need to muck around with xset, and the entire font path in /etc/X11/XF86Config can be a single entry pointing at a local Unix domain socket where the font server will be listening. It will never need updating. To automatically manipulate the font server's search path, Red Hat developed a utility named chkfontpath. It is very easy to use, and its behaviour is modeled after the chkconfig program, which many people are already familiar with. Chkfontpath enables a user to interactively query what directories are present in the font server's path, as well as add and remove them from the command line. Even better, it makes it easy to add The Future X still does not support font smoothing, also known as anti-aliasing. Font smoothing makes small curves in a character appear less jagged by filling in gaps with gray colors, instead of simply drawing the character in black and white. This is a physical limitation of the current X font model, but people are actively pursuing solutions to overcome this hurdle. |