Running an Expanded Font Server

Unfortunately, X's font handling is fairly primitive by the standards of most desktop OSs at the start of the 21st century. Most users notice this in the awkward methods required for adding fonts and in poor font displays in many programs, particularly if the font path isn't set up correctly or if the system uses the default fonts, some of which aren't as good as their counterparts in other OSs. At least as important, though, is the fact that X's font system wasn't designed for integrating screen fonts with printer fonts. This fact, and other design limitations in X's font handling, make the task of creating a smooth interface between screen fonts and printed fonts difficult for applications in which this is important, such as word processors and desktop publishing packages. For this reason, there are various alternatives to traditional font servers available in Linux. Many of these are implemented internally to specific programs, but at least one is a full-fledged font server that can be used by many programs.

The most notable expanded font server for Linux is known as FontTastic (http://www.bitstream.com/categories/developer/fonttastic/). This is a commercial program that functions as an X font server and provides additional capabilities to applications that are written with FontTastic in mind. Specifically, FontTastic can deliver information such as an outline representation of a font, the raw font data, and kerning information. This information isn't readily obtained through a traditional font server, or from fonts handled directly by the X server. This information allows programs to do things that they might not otherwise be able to do, at least not without some other way around X's font-handling limitations. For instance, consider a word processor. If a word processor uses X's conventional font handling, a user may specify a standard X font for use in a document. When it comes time to print, though, the word processor must somehow tell the printer about the font in question. Assuming the printer is a PostScript printer, this means either telling the printer to use one of its built-in fonts or downloading the font to the printer. If the font chosen by the user is some non-standard font, though, the only way the word processor might be able to send the font is as a bitmap, because that's how it's delivered to X applications. Without knowing the printer's resolution, the word processor may have to guess what resolution to use, request characters at that resolution from the font server, and paste the results together. The result probably won't be very good.

With FontTastic, on the other hand, the word processor can request the raw font data to embed in the document, which is a superior solution because it produces a higher-quality output with less effort. (If the font is a TrueType font, the word processor might be able to convert it to a Type 42 font if it knows the PostScript printer can handle this format, or it may need to request the font in raw outline form and effectively reconstruct the font. This is more work, but will produce a cleaner result than would an attempt to print with bitmaps.) The word processor can also utilize improved information on character sizes, spacing, kerning, and so on to produce better-looking output.

Because of its commercial nature, FontTastic hasn't been widely adopted as a standard tool in the Linux community. It is used, however, by at least two major commercial programs for Linux: Corel's WordPerfect Office 2000 (which has now been discontinued) and VistaSource's ApplixWare Office (http://www.vistasource.com/products/axware/). If you run either of these programs, the package installs FontTastic and runs it automatically when its master program runs. You can create a configuration that allows other computers to use FontTastic as a conventional font server, thus simplifying your overall network font configuration requirements. (Studying the details of FontTastic's implementation may take some effort, though.)

FontTastic isn't the only way around the problem of the disconnect between the screen and the printer. Some tools, like TeX, avoid the problem by focusing on the printer, and leaving screen fonts to fall where they may ”TeX is a page description language, so TeX users edit documents using text editors that may or may not display the document in anything resembling the ultimate fonts. Other programs integrate screen and printer fonts by ignoring X's font handling. For instance, WordPerfect 8 used a very different model than its successor; version 8 of the program requires users to install fonts in WordPerfect, instead of or in addition to installing them in X. WordPerfect, not X or a font server, rasterizes fonts for display on the screen. WordPerfect can then download the fonts to a printer or create bitmaps that it downloads to the printer.

Another approach is to tell the program where the original font files are located. The program can then send those files to the printer for use in rendering files that X renders for the screen. This approach is simple, but X's lack of support for some of the finer font-handling features can still cause on-screen displays to have awkward spacing, and if the application doesn't use the appropriate information from the original font files, the printout will suffer from this problem, as well. None of these approaches is particularly network-oriented, so I don't cover them in any depth in this book; I mention them only because they're alternatives to the network-capable FontTastic, and because they may still use a network font server for on-screen font display.