Following are some of the most important problems I've encountered in trying to figure out the details of fonts and printing under WordPerfect for Linux. I don't claim this list is comprehensive, and I don't present full solutions here -- for that, see the next three sections of this document.
The downloadable version of WordPerfect 8.0 for Linux doesn't include the font installation utility, so unless you've got the xwpfi program from a previous version of WordPerfect for Linux, you won't be able to install your own fonts in this version of the program. The personal retail version of WordPerfect 8, though, does include the font installer, and in fact it works better than the installer from WordPerfect 7, so buying this version is definitely the way to go if you want to install lots of third-party fonts. Initial shipments of the personal retail version of WordPerfect 8 were missing the fonts promised on the box. If you've got one of these early shipments, you can contact Corel to have them ship you an updated CD with the fonts.
After installing new fonts, it's often the case that WordPerfect 7 will use the wrong font when an attribute (bold or italic, mainly) is selected. This is because the "automatic font change" ("AFC") feature has been set up incorrectly -- whatever algorithm WordPerfect uses to set this up doesn't work as well as it might. Fortunately, it is possible to manually edit the AFC map, so this problem can be worked around. WordPerfect 8 seldom displays this problem.
I've found that WordPerfect correctly groups variants of fonts that fall in the same font family when the variants have conventional names -- for instance, if you have fonts that are called FooBar, FooBar italic, FooBar bold, and FooBar bold-italic, they'll likely appear in WordPerfect's font menu as a single item, FooBar. You'll then be able to set the AFC map, if it wasn't set correctly initially, to have the font work as expected. If the font uses different names for its variant forms, such as "oblique" instead of "italic" or "black" instead of "bold," however, you may get multiple font entries. In some cases it's possible to map the fonts correctly for one version to call the others, so you've just got to be careful which font you select.
Adding or removing a font will cause WordPerfect 7 to re-compute its AFC mappings, which as I've said tend to be poor with version 7 of the program. So changing your selection of fonts can be a time-consuming process, as you must then fix WordPerfect's mistakes again -- for all the fonts, not just the one(s) you install. WordPerfect 8 doesn't seem to suffer from this problem, and it gets its mappings right more often than not to begin with.
Sometimes, the AFC utility will map graphics and soft fonts differently, thus producing a mis-match between the two, particularly if you select an attribute. For instance, FooBar bold may appear on screen correctly, but appear on the page as BarFoo Gothic bold. In this case, the solution is to re-do the AFC mapping.
In other cases, there may be no appropriate match between installed graphics fonts and soft fonts. I've not tried installing PCL soft fonts, so I don't know how WordPerfect handles the mapping of these fonts; but I do know that installing only PostScript soft fonts results in printing which is correct, but on-screen displays use some other font. In this case, it's necessary to install the same font twice, once as a soft font and once as a graphics font, if you want to see text on-screen in the correct font. Unfortunately, this results in the font appearing twice in the font listings, and you may get slightly different printing results depending upon which font you select.
There's also the issue of built-in printer fonts, which may or may not be mapped to reasonable graphics font equivalents. If you want to see a printer font in a WYSIWYG way, you must have an equivalent graphics font installed. If you're lucky, WordPerfect will do the mapping correctly. If not, you'll get some randomly-selected font on-screen instead, though printing should work.
If you install and use a graphics font with no matching soft font, WordPerfect will handle the rasterization of the font -- that is, it will compute which pixels will be black and which will be white (or whatever colors you're using with a color printer). WordPerfect will then either print much as Ghostscript does, by sending the file to the printer as one huge graphic; or it will download the bitmapped derivative of the font to the printer. The trouble with this approach is that, if WordPerfect has the wrong information about your printer's resolution, printing may not take full advantage of the printer's resolution. For instance, if you select a 300 dpi PostScript printer and print through Ghostscript with a graphics font, the result will be 300 dpi printing, even if you have a 1200 dpi printer.
I know of two solutions to this problem: Either install a soft font to match the graphics font you have installed, and select the soft font in your document; or select a printer with a resolution that matches that of your printer. With some printers, it may be possible to select a higher resolution without ill effects, but I can't guarantee this for all printers. I'm pretty sure this will work fine with Ghostscript.
Sometimes a WordPerfect printer driver doesn't work with your printer. This may be because your printer is incompatible, as is the case with the Epson Stylus Color 400 and WordPerfect's Epson Stylus Color driver. Sometimes it may be because your Linux print queue isn't configured correctly. Depending on how your print queue is set up, it may be necessary to use separate queues for printing via a WordPerfect driver and printing PostScript, for instance. Setting up print queues is described briefly in the non-PostScript printing and PostScript printing sections. Further details are available in the Linux Printing HOWTO, which comes with most Linux distributions and is available from most Linux ftp sites.
One minor problem I encountered with my PCL printer was a stray formfeed after each print job. This is easily corrected by adding the "sf" option to the /etc/printcap entry for the printer; but this may cause the last page of jobs from other applications to not print. This is described in more detail in the non-PostScript printing section.
I found that under some circumstances, particularly when using several soft fonts on one page, Ghostscript would crash rather than print. I don't know what the underlying cause was, but one fix I found was to increase the amount of memory that WordPerfect believes the printer has, as described in the PostScript printing section. Another option is to use graphics rather than soft fonts, though I've a feeling the same problem might occur even then if enough fonts appear on the page.
Many of WordPerfect's PostScript drivers, including most or all of the Hewlett-Packard PostScript drivers, produce PostScript output that's prefixed by a code intended to switch the printer into PostScript mode. This may confuse a print queue, either on Linux or on a networked print server, into thinking that the file is in fact ASCII text. This can create a huge and worthless printout from even a fairly small document. The easiest solution is to switch to another WordPerfect printer driver (I make suggestions in the PostScript printing section). Another solution might be to create a filter for use in the print queue that will strip away this switching code. I've not tried this approach, however. Yet a third solution, if you're printing to a true PostScript printer, might be to print via a "raw" printer queue.
Copyright © 1998, 1999 by Rod Smith, firstname.lastname@example.org