Word Processor Font Issues

X was designed with displaying fonts on the screen in mind; the core X protocols give little consideration to mapping screen fonts to printed fonts. In some cases, this isn't a big deal. For instance, a web page can usually be displayed on the screen or on a printout using almost any font, so the screen and print fonts don't need to match. In the case of a WYSIWYG word processor, though, screen and printer fonts must match. The best way to achieve this effect is to use the same font files for both on-screen display and printing. X's font model, though, doesn't give word processors direct access to the source font files; X delivers font bitmaps to applications, even when the font is an outline font. This break means that applications are limited in what they can do with a font. For instance, to download a font to a printer, the application would have to know the printer's resolution, request the font in a size appropriate to create output at that resolution, and send the resulting bitmap to the printer. X applications may not know the printer's resolution, though. Even if they did, X doesn't provide the precise font spacing information that's often needed to produce the best-looking displays at printer resolutions.

In order to work around these problems of linking display to printed fonts, word processors have adopted various strategies. Each strategy is unique, but there are certain commonalities. The strategies include:

Mapping Display and Printer Fonts One approach is to create detailed and explicit maps between the fonts that X provides and the fonts in the printer or installed in the word processor for delivery to the printer. For instance, if you choose to use Times, X delivers a bitmap Times to the word processor, which tells the printer to display its version of Times. Times is one of the standard PostScript fonts, so the printer has it available. If you pick a font that's not available in the printer, X still displays the font correctly, and the word processor downloads its own copy to the printer. In both cases, the X font and printing font may not derive from the same source, which can cause printed and displayed fonts to not match if the fonts are misconfigured. AbiWord and KWord both use this approach, but their implementation details differ substantially.

In-Application Font Handling In order to avoid mismatched screen and printer fonts, some word processors have taken the task of font handling entirely upon themselves. You install your fonts in the application, which displays text on the screen without using X's font-rendering code. The application then sends the font to the printer when it's time to print. OpenOffice.org is one package that uses this approach.

Decoupling Screen and Printer Fonts Some programs ignore font matching. LaTeX and LyX, for instance, don't make any attempt to have screen and printer fonts match. This approach may make it hard to judge how a final printed page will look, but it greatly simplifies screen font configuration. These programs still require you to install fonts for printing, though.

Using an Expanded Font Server A font server is a program that delivers font data to one or more computers. Some Linux distributions, such as Mandrake and Red Hat, use local-only font servers as their X font delivery mechanism. Some commercial programs, such as Anyway Office (http://www.vistasource.com/page.php?id=7) and WordPerfect Office 2000, use an expanded commercial font server, Bitstream's FontTastic, to deliver outline font data as well as bitmaps. This solution enables the programs to display X fonts on the screen but still deliver outline fonts to the printer. Unfortunately, there's no open source expanded font server similar to FontTastic, so no open source word processor uses this approach.

Xft Another solution is Xft. This library is a new font-handling tool that's being used by the latest versions of KDE and GNOME and by some other applications. Xft can deliver both bitmaps and outlines for a font, so the word processor can use Xft to display text and to send an outline font to a printer. As I write, KWord is the only major word processor that can use Xft in this way, but others are likely to follow. Chapter 16 covers Xft configuration in more detail.

Note Some word processors use variants or multiple techniques. For instance,

OpenOffice.org, although best thought of as using in-application font rendering, can map its fonts to standard printer fonts.

All of these approaches to font handling have one feature in common: In order to use a font in a word processor, you must install that font in the word processor or in an affiliated application. In the case of decoupled fonts, the installation affects only printed fonts; and in the case of expanded font servers and Xft, the font must be installed in the font server or Xft rather than the word processor perse. Nonetheless, this fact makes word processor font configuration another hassle. If you want to use a font both in a standard X application (say, your web browser) and in a word processor, you must install it both in X and in the word processor. Indeed, the mapping approach requires that you install the font in both X and the word processor even if you only want to use the font in the word processor. In the future, Xft is likely to simplify matters, as many applications will use Xft. Xft is still new enough that this simplification is only beginning; and as Chapter 16 details, Xft's configuration has itself undergone changes, which has added to confusion in the short term.

0 0

Post a comment