WordPerfect originated in the days when top-of-the-line printers were daisywheel impact devices requiring manual intervention to change fonts, and when on-screen displays were restricted to a single monospaced font. Particularly flexible dot-matrix printers included half a dozen fonts.
In this environment, it made sense for a word processor to give the user a limited choice of fonts, which would be printed but not displayed in anything resembling a WYSIWYG ("what you see is what you get") fashion. WordPerfect, in particular, adopted a strategy, consistent with its code-based design, of embedding font change codes in the document. WordPerfect maintained a database of character widths for various fonts, which it used to compute the ends of lines. WordPerfect also maintained an extensive set of printer drivers, which, in terms of font support, served as a means of telling the printer to switch from one font to another. All of this was simple on an individual-printer basis, and effective, but crude by today's standards. It also required a massive library of printer drivers.
With the arrival of popular GUIs (mainly the Mac and Windows), as well as more flexible printer font handling, things changed. The demand for WYSIWYG word processing led to the emergence of a new font and printer strategy, where the word processor relied upon the underlying OS for font handling, both for the on-screen display and the printer. In the conceptually simplest case, the word processor goes to the OS with a font request, and the OS then displays text in the desired font. When it comes time to print, the OS uses the same font file to print to the printer. Because the Mac and Windows include printer driver support in the OS, it's possible in these environments to strip away the extensive collection of printer drivers from the word processing application. This makes co-ordinating on-screen and printer fonts relatively simple, at least from the word processor's point of view.
Of course, the details of such an arrangement can become tedious, especially when mixing font types (say, TrueType fonts in the OS, but a PostScript printer requiring Type 1 fonts). The word processor, however, needn't concern itself with most of these details; the tedium is handled by the OS and its drivers. Unfortunately, X doesn't directly provide printer support, so this approach doesn't work in Unix.
Presumably in order to maintain compatibility with its older and non-GUI versions, WordPerfect adapted to the demands for WYSIWYG word processing in its 5.x versions for Windows and OS/2 by taking a kitchen-sink approach: Retain the existing base of printer drivers and add support for OS-driven fonts and printer drivers. (Mac versions of this era were more OS-centric, and Unix versions owed more to the old text-mode heritage, as I'll describe.) With version 7.0 for Windows, WordPerfect switched to an OS-centric view, but that's not the case with versions 7.0 or 8.0 for Unix. This makes for a confusing hodge-podge of options, and adapting the old text-mode approach to a WYSIWYG product makes for yet more added complexity. As this document is about WordPerfect for Linux, I'll describe only those adaptations that are implemented in this version.
Basically, WordPerfect adds both screen fonts and downloadable printer fonts, and attempts to match the two up. As described in the font management section, it's possible to add two types of fonts to WordPerfect: "graphics" fonts and "soft" fonts. The former are PostScript Type 1 (aka "ATM") fonts used for display on the screen, and can also be used to produce font bitmaps for printing. Soft fonts are downloaded to and processed by the printer, and are not used for screen display purposes. In the case of a PostScript printer, soft fonts are also Type 1 fonts, and so you can have the same font installed twice, once for screen display and once for printing. In the case of PCL printers, it's possible to install PCL-specific fonts, so the printer and display fonts may not match up exactly. This is one of the problems described in the problems section.
So, in the end, you must install a font in WordPerfect for it to display text in that font (it doesn't seem to use the fonts installed in X itself). WordPerfect can use these same fonts for printing, or you can install the same fonts again or install different fonts to be used for printing. In the latter case, WordPerfect manages the mapping of display and printer fonts, in an attempt to keep the two matched up. It doesn't always succeed, though.
Copyright © 1998, 1999 by Rod Smith, email@example.com