By any measure, StarOffice 5.1 is an unparalleled boon for organizations hoping to cut down on software licensing costs. Chances are that you’ve already tried StarOffice and its high-quality word processing program, StarWriter. In our previous Daily Drill Down, “Migrating from Microsoft Word to StarOffice: Look before you leap ,” we examined the pros and cons of migrating users from Microsoft Word to StarWriter, and you may conclude that it’s worth a try. As users migrate to StarWriter, however, you’ll hear plaintive cries: “Are these the only fonts that I can use?”
Here’s the situation: Although StarOffice comes equipped with a few standard fonts, the program’s built-in font repertoire is woefully undersized compared to anything that you’d find on a Windows or a Macintosh system. Unless you add more fonts, including TrueType fonts, users aren’t likely to be happy—and that’s especially true, as you’ll discover, when they start trying to exchange documents with Microsoft Word users. If you import a Word document containing fonts that StarWriter doesn’t have, StarWriter falls back on its default fonts, and the result may be so ugly that users will spend inordinate amounts of time reformatting the imported documents. Even if StarOffice has what appears to be the same font, the program can’t import Word’s “smart quotes” and other special characters properly. In places of quotes, apostrophes, em dashes, and other characters common in Word boxes, users will see ugly blank boxes in important Word documents. Worse, each of them is marked as a misspelling. And StarOffice is supposed to be able to exchange documents with Microsoft Word transparently!
Obviously, Star Office’s font capabilities need fixing, but be forewarned: the repair job is a lot of work, and StarOffice is almost unbelievably fussy about fonts that don’t measure up to its standards. You may not be able to get StarOffice to recognize all of the fonts that are available on your system, and the whole process is rather tedious. In addition, everything that’s described here is completely undocumented and unsupported, which means that a new StarOffice version could suddenly change the rules of the game and your font modifications may no longer work. Worse, the font upgrade described here works just fine on GNOME systems, but StarOffice doesn’t cooperate consistently when it’s running under KDE—even when the added fonts have been installed properly and they’re available to other KDE applications. Still, assuming that you’re willing to give it a try and put up with the possibility of disappointing results, the payoff’s worth it. In my line of work, I must exchange documents with Word users on a daily basis, and most of these documents use Word’s special characters, such as smart quotes. It’s a pleasure to see them on-screen in StarOffice!
The StarOffice font de-uglification project involves three articles:
- Part 1 (this Daily Drill Down) shows you how to add additional Type 1 (also called PostScript) fonts to StarOffice so that they show up on-screen and print beautifully. This part of the project is a must for all StarOffice users.
- Part 2 (upcoming) shows you how to modify fonts so that they can display the non-standard characters in Microsoft Word documents. This part of the project is a must for any user who exchanges documents with Microsoft Word users.
- Part 3 (also upcoming) shows you how to get TrueType fonts working on your Linux system so that they’re available for display and printing within StarOffice.
Typically, this type of Daily Drill Down starts out with step-by-step instructions. They’re coming, but I’m a big believer in starting out with a solid conceptual foundation. In particular, you need to understand what’s right—and what’s wrong—with fonts in the Linux environment.
Fonts, Linux, and X: An introduction
Let’s start off with the unpleasant truth: The X Window System may have some good points, but its font-handling capabilities aren’t one of them. The X Window System—or X, for short—provides the basic graphical user interface and windowing system for Linux applications.
Since X is designed to work with a huge variety of display devices (including some very primitive bit-mapped displays), the system doesn’t use the scalable font technology that you’ll find on today’s Windows and Mac systems. A scalable font, also called an outline font, is represented by means of a complex mathematical formula, which enables the display technology to vary the size, position, and other font characteristics. Scalable fonts are vastly superior to bit-mapped fonts, which look just fine as long as you’re viewing them at their default size. If you try to enlarge them, you’ll see ugly, stepladder distortions—called “the jaggies” by unappreciative users—which derive from aliasing errors.
If X could display nothing but bit-mapped fonts, it wouldn’t have much of a chance of success in the desktop market. Happily, you’re not stuck with bit-mapped fonts when you’re using the most recent version of X, called X11R6. Today’s X Window System doesn’t use font-scaling technology to display scalable fonts on-screen. Nevertheless, X can work with such fonts by reading them and rasterizing them on the fly. When X rasterizes a scalable font, it reads the font file and translates it into a bit-mapped representation at the requested font size; the resulting display font is called a font instance. This solution isn’t terribly efficient, but it works—up to a point. X can’t handle some font transformations that you can pull off on a Windows or a Mac system, such as free font rotation. That’s why desktop publishers aren’t exactly rushing to the Linux environment. Another limitation is that X can work with Type 1 scalable fonts, but it can’t work with TrueType fonts—at least, it can’t without modification.
By means of the on-the-fly rasterization technique, X can approach the typographic quality of a Windows or a Macintosh system, but that’s true only when you’re displaying fonts on-screen. The greatest of all X deficiencies lies in this unfortunate fact: there’s absolutely no inherent relationship between what’s viewed on-screen and what comes out of the printer. In an X environment, printing is a separate process. It isn’t a problem with most applications, which use fonts only for screen display purposes. But you won’t see the same fonts when you print the document. For example, you can set up X fonts (or even TrueType fonts) in such a way that a browser like Netscape will display the fonts that are specified by a Web page’s author. But Netscape falls back on its default fonts for printing. Perhaps that’s OK for Netscape, but it won’t wash in a full-featured, professional word processing program.
How X handles fonts
Here’s a quick overview of how X handles fonts on typical Linux systems. As you know, X is divided into two major components: the X server, which is tailored to work with a specific system’s display technology, and various X protocols and utilities, which enable applications to communicate with the X server. When an application needs to display a font, the program requests this service from the X server, and, if all goes well, you see the font on-screen.
How does the X server know which fonts are installed on the system? You provide this information by modifying the X server configuration file, which is called XF86Config on most Linux systems. (You’ll find this file in the /etc directory.) In the “Files” section, there’s an area called FontPath, which contains a comma-delimited list of directories containing X-compatible fonts. This list is called the default font search path.
Specifying the default font search path isn’t enough to get fonts to work, though. Each directory must also contain files called fonts.scale (for scalable fonts) and fonts.dir (for all fonts). These files contain information about each font in the directory, including the font’s name, the name of the foundry, and the type of character encoding that’s used to generate the font. This information must be listed in accordance with the X Logical Font Description Convention (XLFD). Since it would be rather tedious to type the required information manually, utilities are available (such as type1inst and mkfontdir) that generate the required font directory files automatically.
Some Linux systems, notably those that run Red Hat 6.0 and 6.1, are configured to use the X font server (xfs) instead of the X server. The X font server was developed to enable organizations to provide a central repository of fonts on a local area network (LAN); unlike the X server, the X font server can respond to requests from applications that run on other computers. You can verify if your system is configured to run xfs: take a look at XF86Config and see if FontPath is set to “unix/:-1” (which will disable the X server’s font capabilities). If you’re running xfs, specify the default search path in the xfs configuration file (on Red Hat systems, this file is located in the /etc/X11/fs directory). Separated by commas, the directories with fonts are listed in the area called “catalogue.”
To see which fonts are currently available on your system, open a terminal window and type xlsfonts | less and press [Enter]. You’ll see a list of fonts in the XLFD font-naming format.
Whether you’re serving fonts with the X server (XFree86) or the X font server (xfs), you’ll find the same, glaring deficiency: what you see on-screen isn’t necessarily what you get when your document prints. And that’s precisely why StarOffice offers its own solution to the font printing problem.
How StarOffice deals with the font printing problem
When a desktop environment fails to provide system-level solutions to font display and printing, application authors take matters into their own hands, and that’s precisely what happened with StarOffice. In general, StarOffice can display any font that’s made available by the X server or X font server, but the program can print only those fonts that have been installed deliberately with the program’s Printer utility.
By default, StarOffice uses only those fonts that are present in its default font directories, /fonts/type1 (Type 1 fonts for printing), and /fonts/75dpi (corresponding bitmapped fonts for screen display). It’s a meager selection at best. Worse, these fonts aren’t integrated well with the rest of your system. As you may have noticed, the StarOffice fonts aren’t available to other applications because they’re not included in X’s default font search path. In addition, StarWriter doesn’t enable you to choose any of the non-StarOffice fonts that are made available to X; they don’t appear on the program’s font menus. An exception occurs when you load a document that contains non-StarOffice fonts. Suddenly, the whole list of available fonts appears. But these non-StarOffice fonts won’t do you much good. Although you can use them to display fonts on-screen, they won’t print—at least, not in the way that they look on-screen. If you try to print a document that contains fonts other than the ones StarOffice is configured to print, the program falls back on its default printing fonts.
To improve StarOffice’s font capabilities, you should do the following:
- Add the StarOffice font directory to the default font search path so that the StarOffice fonts are available to other applications.
- Add additional Type 1 fonts to the list of fonts that StarOffice can print.
The following sections detail these procedures.
Making the StarOffice fonts available to X
To make StarOffice fonts available to other X applications, perform the following steps:
- Determine the full pathname of the directory where StarOffice stores its Type 1 fonts. If you installed StarOffice in your home user directory (such as /home/linda), this directory will be named something like /home/linda/Office51/fonts/type1. (Note that this directory already contains the two essential directory files: fonts.scale and fonts.dir.)
- Open a terminal window and switch to superuser.
- Open your text editor and do one of the following:
a) For systems that use the X server to serve fonts (without xfs), open XF86Config. On Red Hat systems, you’ll find this file in /etc/X11.
b) For systems that use the X font server (xfs) to serve fonts, including Red Hat 6.0 and 6.1, open the file called config in /etc/X11/fs.
- Add the StarOffice font directory to the appropriate area (the FontPath area of XF86Config or the catalogue area of /etc/X11/fs/config). Carefully type the directory name on its own line and type a trailing comma (unless the directory that you are adding is the last in the list).
- Save the modified file and restart X. Now, the StarOffice fonts should be available to other X applications. Type xlsfonts | less to determine if the StarOffice fonts are available (for StarOffice version 5.1, they’re listed with Sun as the foundry).
Adding Type 1 fonts to StarOffice
Now that you’ve made the StarOffice fonts available to other X applications, it’s time to return the compliment by making additional Type 1 fonts available to StarOffice. Chances are that your system contains many additional Type 1 fonts; check out /usr/X11R6/lib/X11/fonts and /usr/share/fonts. You also can download dozens of free Type 1 fonts from the Web. A widely distributed collection is called freefont. (Note that this collection contains numerous fonts with various license restrictions. You should examine the licenses and copyrights carefully before you use them.)
A given Type 1 font may be supplied in as many as three separate files, each with exactly the same filename but with different extensions:
- ASCII font file (*.pfa): This is the version of the font file that the X server needs to display the font on-screen.
- Binary font file (*.pfb): This is the version of the font file that’s downloaded to a PostScript-compatible printer.
- Font metric file (*.afm): This file contains information about the font.
To install Type 1 fonts in StarOffice, you must have the *.pfa and *.afm files. Both of these files must have exactly the same filename. (For example, bodoni.pfa and bodoni.afm can be installed—but only if both of these files are present and if “bodoni” is typed in exactly the same way.)
If you downloaded additional Type 1 fonts, make sure that your Type 1 fonts are installed correctly by following these steps:
- Log in as root user and create a new directory for your fonts (such as /usr/share/fonts/newfonts).
- Copy the fonts to the directory. The directory should contain at least the *.pfa and *afm versions of each font.
- In the directory containing the Type 1 fonts, run the Perl script type1inst. If your system lacks this script, you can download it . This script creates the fonts.scale file.
- In the directory containing the Type 1 fonts, run mkfontdir. This utility reads fonts.scale and creates the fonts.dir file.
- Open a terminal window and switch to superuser.
- Start your favorite text editor and open /etc/X11/XF86Config (for systems that serve fonts with the X server) or /etc/X11/fs/config (for systems that serve fonts with xfs).
- Add the Type 1 font directory that you created to the appropriate area (the FontPath area of XF86Config or the catalogue area of /etc/X11/fs/config). Carefully type the directory name on its own name and type a trailing comma (unless the directory that you are adding is the last in the list).
- Save the modified file and restart X. Now, the fonts should be available to other X applications. Type xlsfonts | less to see if the fonts are available.
Installing new Type 1 fonts in StarOffice
Are your Type 1 files installed correctly? Follow these steps to install them in StarOffice:
- Log in with your ordinary user account. Do NOT perform the following actions as superuser.
- If StarOffice is running, exit the program.
- In the StarOffice font directory, create a new subdirectory called newtype1. To do so, open a terminal window, switch to the StarOffice font directory (Office51/fonts), type mkdir newtype1, and press [Enter].
- Copy the Type 1 files to the directory that you just created. To do so, switch to the directory that contains the Type 1 files and type cp *.afm, followed by the full pathname of the directory that you just created (such as /home/linda/Office51/fonts/newtype1/). Type cp *.pfa, followed by the same directory name, to finish copying the necessary files.
- Within the directory you just created, run type1inst.
- Now run mkfontdir within the same directory.
- Within the StarOffice directory, switch to the /bin directory. If you installed StarOffice in your user directory with the program defaults, this directory will be located in Office51/bin. (If your home directory is called /home/linda, the full pathname to this directory—again, assuming that you installed StarOffice with the program’s defaults—is /home/linda/Office51/bin.)
- Type ./spadmin and press [Enter]. You’ll see the Printer Installation dialog box.
- Click Add Fonts. You’ll see the Font Path dialog box.
- Click Browse. You’ll see the Select Directory dialog box.
- In the Directory textbox, type the full pathname of the newfonts directory (such as /home/linda/Office51/fonts/newtype1). You also can use the directory navigation window to locate and select this directory.
- Click OK. In the Font Path dialog box, you’ll see the directory that you’ve selected.
- Click OK to close the Font Path dialog box. The utility scans for new fonts and displays them in a list; click OK to install these fonts. Next, you’ll see a dialog box informing you, incorrectly, that the new font directories will be added to the default X font path. Click OK to dismiss this dialog box.
- Important: Click Edit Font Attributes. You cannot print with the fonts that you’ve added until you convert all the metric files for printing purposes.
- In the Fonts dialog box, click Convert All Metric Files.
- Click Close until you see the terminal window again.
- Restart X.
Note: If you can’t restart your X server after you add the directory name to the default font search path, check the X server’s error message. If you see a message that the X server was unable to load a fixed font, it means that one of the fonts in the new directory is corrupt. To solve this problem, use a text editor to remove the directory name from the configuration file’s font directories list. Then, you can delete the fonts one by one until you’ve found the corrupted one.
To make sure that all has gone well, start StarOffice, open a new text document, and determine if the new fonts are available in StarOffice’s font menus. If some fonts aren’t available, I suggest that you don’t waste your time trying to figure out why; there are dozens of possible explanations, and you’d spend days tracking them down. (Trust me, I just did.) You’ll find plenty of fonts that will install without problems, and you’ll be wise to stick with them.
Next week, watch for part 2 of this series. After reading it, you’ll know how to display smart quotes and other imported Microsoft Word characters within StarOffice.
Bryan Pfaffenberger, a UNIX user since 1985, is a University of Virginia professor, an author, and a passionate advocate of Linux and open source software. A Linux Journal columnist, his recent Linux-related books include Linux Clearly Explained (Morgan-Kaufmann) and Mastering Gnome (Sybex; in press). His hobbies include messing around with his home LAN and sailing the southern Chesapeake Bay. He lives in Charlottesville, VA. If you’d like to contact Bryan, send him an e-mail .
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.