5
Font Management
The fonts used by an application need to be available to every server that might display it. This chapter discusses the issues with using fonts, installing new fonts, and converting fonts from other formats. It also discusses the X11R5 font server.
In This Chapter:
The fonts.scale File (R5 only)
Problems with Running Vendor-specific Clients
Converting from X11/NeWS to PCF or SNF
Providing Fonts Over the Network
5
Font Management
The number of fonts available under X11 is enormous, and there's no limit to adding more. Each size and orientation is treated as a different font. Furthermore, fonts are stored in several different formats, so the same font might be stored five different ways.
The administrator's role is to ensure that each server can access the fonts it needs for a given application. In Release 3 and Release 4, fonts for servers needed to be available locally—usually stored on a local disk drive or made to appear local via a NFS or AFS filesystem. In Release 5, fonts can be obtained either locally or through a font server, which allows access to fonts on more than one host on the network.
5.1 Fonts on the X Window System
In general, a client has default fonts chosen by the programmer, but administrators or users may want to change them to their own preference. The default fonts may be too small to read, unavailable for a given server, or just plain ugly. For example, the default font for xterm is usually the font fixed, a 13-pixel semi-condensed font that tends to be quite small on high-resolution monitors.
Before we discuss the administrative issues of fonts, let's talk about how fonts are designated on the X Window System. An example of a font name and its components is shown in Figure 5-1.
The field names have the following meanings:
Foundry
This is a registered name for the font “foundry” (usually a company name) that supplied the font to the X Consortium (“Adobe,” “Bitstream,” etc).
Family
The “family” or typographic style of the font (“Courier,” “Lucida,” etc).
Weight
The typographic weight or “blackness” of the font (“medium,” “bold,” etc).
Slant
The “posture” of the typeface (“Roman” is upright, “Italic” is slanted, etc).
Set Width
The horizontal width of the font (“Normal,” “Narrow,” etc).
Additional Style
An additional style that expresses information not present in the other fields (“sans,” or not specified).
Pixel Size
A height measurement in pixels at a certain point size and resolution.
Point Size
The size of the font in typographic “points” (1/72 of an inch).
Horizontal and Vertical Resolution
The horizontal and vertical resolution in dots per inch (dpi) from when the font was originally designed.
Spacing
The description of how the width affects placement of adjacent characters. A proportional (“p”) font's characters vary in width, so some characters may appear closer to each other. This is usually desirable for hardcopy, such as book. A “CharCell” (“c”) font treats each character as a little box of the same dimensions as all the other characters. These are better suited for “terminal” displays, such as in an xterm window, which would look terrible if the characters were of varying size.
Average Width
The average width of the font in tenths of a pixel.
Character Set and Encoding
The encoding standard to which the font conforms to (ISO is the International Standard Organization) and the particular character set.
The fields that are usually the most important to the X administrator are:
- The size and resolution (for controlling the size of the font on the screen).
- The spacing (for use with terminal emulators).
Fonts are specified to a client either as a resource or with the −fn option. For example, a user can put the following line in a resource file:
xterm*font: -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1
or invoke xterm with the following command line:
% xterm -fn -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1
The default resources for most clients are specified in their application defaults file. See Section D.1.2 for more information on where resources are defined.
There are several clients that deal directly with fonts. These can be used to find and list all the fonts available from the X server.
5.1.1 xlsfonts
To see all the fonts a X server knows about, run the xlsfonts command. xlsfonts accepts wildcards within the font specification and will list all the matching names. For example:
% xlsfonts -fn ‘-dec-*-*-*-*--*-*-*-*-*-*-*-*’ -dec-terminal-bold-r-normal--14-140-75-75-c-80-dec-dectech -dec-terminal-bold-r-normal--14-140-75-75-c-80-iso8859-1 -dec-terminal-medium-r-normal--14-140-75-75-c-80-dec-dectech -dec-terminal-medium-r-normal--14-140-75-75-c-80-iso8859-1
Note that only a small subset of the available fonts is appropriate for the xterm client. Only character cell fonts (with -c- in the 11th field) are recommended for use in xterm windows. Although mono-spaced -m- fonts like Courier and Lucida Typewriter can be used for xterm most of the time, some “garbage” characters may occasionally appear if you use those fonts, since mono-spaced fonts can extend outside of the character cell.
5.1.2 xfd
The xfd client will display all the characters of a particular font. It can be used as a quick test to make sure a font exists and looks okay. For example, the command line:
% xfd -fn -adobe-courier-bold-r-normal--14-140-75-75-m-90-iso8859-1
would yield the window shown in Figure 5-2.
5.1.3 xfontsel
The xfontsel client (which was new in R4) allows browsing through all the available fonts and seeing each one in turn. When you find a font that you are happy with, click on the “select” button and the selection can be pasted into a file or command line without having to type it by hand.
Consult the manual pages for xlsfonts, xfd, and xfontsel for more information.
5.1.4 The Font Path
The font path is a list of directories in which the server looks for fonts. On the X Window System, fonts are usually stored in a subdirectory of /usr/lib/X11/fonts. The MIT Release 4 distribution of X contains three subdirectories in /usr/lib/X11/fonts: 75dpi, 100dpi and misc. The dpi suffix refers to the dots-per-inch or screen resolution of the display that the server is going to use; the misc directory contains random useful fonts for the display.
The default font path for a given server is usually set when the server is built from source code. The typical MIT-derived local display server will come with the 75dpi, 100dpi, and misc directories in its font path by default. You can check the current font path at any time with the -q (query) option to the xset client. For a typical R4 server:
% xset -q FontPath: /usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/100dpi/
Release 5 includes the Speedo font directory of scalable fonts as well. (See Section 5.2.1 for more information on Speedo fonts.)
% xset -q Font Path: /usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/Speedo/,/usr/lib/X11/fonts/75dpi/, /usr/lib/X11/fonts/100dpi/
Each of these directories is searched in order for a specified font. The server will use the first match it finds when there is more than one font with the same name. Users can change the default font path with the fp option to the xset command. For example, to add a font directory to the font path, you might type:
% xset +fp /usr/lib/X11/fonts/local
This command adds the directory /usr/lib/X11/fonts/local to the current font path. The “+fp” option prepends a directory to the font path, while “fp+” appends it.
% xset -q Font Path: /usr/lib/X11/fonts/local,/usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/75dpi/, /usr/lib/X11/fonts/100dpi/
The local directory is now searched before the regular directories. If you want to redefine one of the default fonts, you can install a new one in the local directory and the server will access the new one instead.
Rehashing the Font Path
Each time the font path is changed, the server reads the fonts.dir and fonts.alias files in each directory listed in the new font path. The server then maintains a list of valid font names in memory instead of searching for a font in the filesystem every time it is requested. If a new font is added to one of the font directories and the fonts.dir or fonts.alias files are changed, you need to update the list of fonts known to your server with the command:
% xset fp rehash
The rehash command tells the server that something has changed and it should rebuild this internal list.
The xset client controls many server features. See the manual page for xset for more information.
The font path can also be specified when the server is first started. For example, on the command line:
% xinit -- -fp /usr/lib/X11/fonts/local,/usr/lib/X11/fonts/misc/, /usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/100dpi/
or in the Xservers file:
:0 local /usr/bin/X11/X -fp /usr/lib/X11/fonts/local,/usr/lib/X11/fonts/misc/, /usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/100dpi/
5.1.5 The Font Directory File
When a client requests a specified font, the server searches in each of the directories in its font path for a file called fonts.dir, as in /usr/lib/X11/fonts/75dpi/fonts.dir. The fonts.dir file maps the name of the requested font to the filename of the font as it is stored in the filesystem. If there is no match, the client reverts to its own defaults (e.g., xterm reverts to “fixed”).
The fonts.dir file is needed because some operating systems have restrictions on filenames. For example, MS-DOS, VMS, and UNIX all have restrictions on filename length or on the characters used within filenames. When installing a new font, you should choose a filename for the new font that conforms to the semantics of your operating system. The fonts.dir file contains the mapping of the font filename to the name of the font itself.
The fonts.dir file's presence is required for the server to access any fonts within a directory. It is created by the mkfontdir command. You have to run mkfontdir every time you add or delete a font from a directory to keep the fonts.dir file in sync with the actual contents of the font area. (See Section 5.3.1 for an example of how to use mkfontdir.) The fonts.dir file has a simple format—the first several lines of a sample R4 file resemble the following:
200
courBO10.snf -adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-1
courBO12.snf -adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1
courBO14.snf -adobe-courier-bold-o-normal--14-140-75-75-m-90-iso8859-1
courBO18.snf -adobe-courier-bold-o-normal--18-180-75-75-m-110-iso8859-1
courBO24.snf -adobe-courier-bold-o-normal--24-240-75-75-m-150-iso8859-1
.
.
.
The number at the top is the number of fonts in the directory. The remaining lines are pairs of filenames and font names. The .snf extension to filenames in this example indicates the format that the font is stored in—in this case, the Server Natural Format. (See Section 5.2.2 for more information on font formats.) The files may also have a .Z extension, if the server supports compressed fonts.
OpenWindows-specific Features
Sun's OpenWindows has a different system for fonts (scalable F3 format), but most of the font administration utilities parallel the MIT ones in function. The OpenWindows file Families.list is similar in function to the fonts.dir file. It is created by the bldfamily command, which should be run any time the contents of the font directory are changed, in the same manner as mkfontdir.
5.1.6 The fonts.scale File (R5 only)
In R5, the outline or scalable fonts (as described in Section 5.2.1) introduce a problem with creating the fonts.dir file. It is difficult for mkfontdir to determine the values in the font name fields for a scalable font. If there are scalable fonts within a font directory, a fonts.scale file should be created by hand. When mkfontdir is run, it will create entries in fonts.dir for each bitmap font it finds and will then append the contents of the fonts.scale file.
The Speedo fonts distributed with R5 come with a fonts.scale file that is installed along with the fonts in /usr/lib/X11/fonts/Speedo. It contains an entry for each scalable font:
8 font0648.spd -bitstream-charter-medium-r-normal--0-0-0-0-p-0-iso8859-1 font0649.spd -bitstream-charter-medium-i-normal--0-0-0-0-p-0-iso8859-1 font0709.spd -bitstream-charter-bold-r-normal--0-0-0-0-p-0-iso8859-1 font0710.spd -bitstream-charter-bold-i-normal--0-0-0-0-p-0-iso8859-1 font0419.spd -bitstream-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 font0582.spd -bitstream-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1 font0583.spd -bitstream-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1 font0611.spd -bitstream-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1
As there are no other fonts in the Speedo directory, the contents of the fonts.scale file and the resulting fonts.dir file are identical.
5.1.7 Wildcards
As shown in our xlsfonts example earlier, users don't have to use the full names of a font when specifying them. Wildcards can be used to limit the amount of typing required and provide flexibility.
Users can use asterisks (“*”) in the font specification, such as:
% xterm -fn ‘-fixed-*-*-*-*--15-140-*-*-*-*-*-*’
The asterisks will match any of the possible values for a given field in the font specification.
Notice that a font name using an asterisk as a wildcard needs to be single-quoted on the command line. This is to protect the asterisks from being interpreted by the shell.
The first font found in the font path that matches the pattern is the one that is used. If you supply the pattern to xlsfonts, you can see which fonts in your font path match the pattern:
% xlsfonts -fn ‘-fixed-*-*-*-*--15-140-*-*-*-*-*-*’ -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1 -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1
Although xlsfonts may report more than one font name, only the first font listed will be used by a client when supplied a font name using the same wildcards. If you run xfd with the same font pattern, the name of the first matching font is displayed at the top of the window:
-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1
Using wildcards could have a surprising effect, especially when a new font is installed: if an administrator adds a new font that is similar in name to an already existing font, users may end up matching the new one instead of the one they thought they were requesting. Other surprises could occur when a new version of X11 is installed, as each release has had more fonts than the previous release, leading to new matches to a wildcard.
Using wildcards can make an application more flexible, as it may still find a usable font if the intended one is missing, whereas a complete font specification may cause a failure if not matched exactly.
5.1.8 Aliases
A font subdirectory can contain a file called fonts.alias, which contains aliases for font names. An example of an alias is the default fixed font, which is defined in fonts.alias in the MIT distribution of X as:
fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
An administrator can make it easier for users to specify fonts by defining aliases for frequently used fixed-width fonts. For example, if the administrator enters the following line into the fonts.alias file:
fb15 -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1
Users can then call the 15-point fixed bold font with the command line:
% xterm -fn fb15
Font aliases can be used in resource files as well, as follows:
xterm*font: fb15
You could argue that this is a bad idea, as non-standard aliases would likely fail if you used your resource files on another server.
Aliases also add flexibility to applications, as they can be assigned to more than one font. For example, the name lucidasans-10 is aliased in /usr/lib/X11/fonts/75dpi/fonts.alias as:
lucidasans-10 -b&h-lucida-medium-r-normal-sans-10-100-75-75-p-58-iso8859-1
and in /usr/lib/X11/fonts/100dpi/fonts.alias as:
lucidasans-10 -b&h-lucida-medium-r-normal-sans-14-100-100-100-p-80-iso8859-1
Which one is used depends on which directory occurs first in the font path. In this example, the alias creates flexibility in the resolution of the display.
Another reason to alias a file is that the font name may be inconvenient to use on the command line. The “b&h” fonts shown above contain the “&” character in the font name, which will confuse the shell.
Under OpenWindows, the files Compat.list and Synonyms.list provide the alias mechanism.
5.1.8.1 The FILE_NAMES_ALIAS Alias
The “magic” alias “FILE_NAMES_ALIASES” indicates that the actual filenames of the font files, with the suffixes removed, can be used as aliases for the fonts. For example, the DECWindows fonts all have filenames that are also valid aliases when you remove the extension. If the fonts.dir file has the following entry:
terminal_wide14.snf -dec-terminal-medium-r-wide--14-140-75-75-c-120-iso8859-1
The name terminal_wide14 would be a valid alias for this font if “FILE_NAMES_ALIASES” is present in the fonts.alias file.
This method of aliasing is being downplayed by the X Consortium, as its use encourages nonstandard font names. You should not rely on this mechanism in the future.
5.2 All About Fonts
There are many different font formats in use and each vendor has made changes on its own. The first step in resolving the problems caused by this is to identify what type of font is being used. The next step is to find the right tool to make the font available to your application.
5.2.1 Bitmap Versus Outline Fonts
For MIT servers prior to R5, a separate font was required for each size of the font. For example, to display the font -b&h-lucida-bold-i-normal-sans at the point sizes of 11, 14, 17, 20, and 34, you needed a font for each:
-b&h-lucida-bold-i-normal-sans-11-80-100-100-p-69-iso8859-1 -b&h-lucida-bold-i-normal-sans-14-100-100-100-p-90-iso8859-1 -b&h-lucida-bold-i-normal-sans-17-120-100-100-p-108-iso8859-1 -b&h-lucida-bold-i-normal-sans-20-140-100-100-p-127-iso8859-1 -b&h-lucida-bold-i-normal-sans-34-240-100-100-p-215-iso8859-1
This is simply because the fonts are bitmaps and are stored as such. In R5, outline or “scalable” fonts are also available. These are stored as a description of the outline of the font and can be scaled by the server to any point size. Scalable fonts have been available in NeWS servers (Sun OpenWindows and SGI X/NeWS/GL) only prior to R5. The Speedo fonts in R5 are of the outline type. Outline fonts can be recognized by 0 values for the size fields in the font name:
-bitstream-charter-bold-r-normal--0-0-0-0-p-0-iso8859-1 -bitstream-charter-bold-i-normal--0-0-0-0-p-0-iso8859-1 -bitstream-charter-bold-r-normal--0-0-0-0-m-0-iso8859-1 -bitstream-charter-bold-i-normal--0-0-0-0-m-0-iso8859-1
When the font is requested, the size fields are filled in with the desired value:
% xlsfonts -fn ‘-bitstream-charter-bold-r-normal--12-*-*-*-*-*-*’ -bitstream-charter-bold-r-normal--12-120-75-75-p-75-iso8859-1
Some advantages to outline fonts are:
- They need only one font file per font, vastly simplifying administration and conserving disk space.
- They are more flexible, as it may be impossible to predict all sizes that might be requested by users or required by different displays.
Some advantages to bitmap fonts are:
- They usually look better than scaled fonts, as they are tuned for each size.
- They may be faster to request, as there is no scaling overhead before the font can be used.
You can convert specific sizes of an outline font into a bitmap font using the font conversion tools described in Section 5.2.3. Some vendors provide bitmap versions of outline fonts at several common sizes to boost performance.
5.2.2 Font Formats
If you are building an X11 distribution from MIT source, the fonts arrive with a .bdf suffix, indicating that they are in BDF format (Bitmap Distribution Format). BDF format has been the default format since the early releases of X. When the standard X11 distribution is built, BDF font files are converted into a format suitable for your server.
If you are not building X11 from source, the fonts are usually sent with the individual server (for example, on a font tape sent with an X terminal). The fonts will have another suffix, probably .snf, indicating that they are in SNF format (Server Natural Format). In R5, fonts default to PCF format (Portable Compiled Font), with .pcf suffixes.
Following are some common extensions and what they indicate about the font:
.bdf
Bitmap Distribution Format. This is the form most fonts will arrive in if the final destination is unknown. BDF files can be converted to most of the final formats that would be used by a server. If you want to supply someone else with a font, use the BDF format for interchange. They are ASCII files and can be edited with a normal text editor. The MIT server is able to read BDF files directly, but it is not the optimal format for storage.
.snf
Server Natural Format. This format is used by most MIT servers in Releases 2 through 4. Fonts are stored in a binary file and are host byte order dependent. This means you cannot share fonts between a big endian and little endian machine in most cases. Some vendors have servers that are smart enough to detect this and convert the font “on-the-fly.” See 7.4.1 for more information on SNF fonts and byte order dependencies.
.pcf
Portable Compiled Font. The PCF format was designed by DEC for use with DECWindows. It offers some advantages over SNF, in that it is host byte order independent. This means hosts of different byte orders can share the same font. DEC has made this format available to the X Consortium, and it is now the default for MIT Release 5. It is also used by recent versions of IRIX on the Silicon Graphics platform.
.spd
Speedo-Bitstream. These are commercial-quality outline fonts donated to the X Consortium by Bitstream Inc. They are included in MIT Release 5. They can be distinguished by the fact that they all have point sizes of 0, as they are scaled to a particular point size when they are requested.
.f3b,.fb
X11/NeWS. These formats are used by Sun Microsystem's X11/NeWS Server and older versions of the Silicon Graphics X11/NeWS/GL Server. The .f3b files are scalable F3 (formerly named “Folio”) format fonts. The .fb files are F3 format fonts scaled to certain point sizes. Some of their administration tools parallel the MIT ones and will be mentioned in context.
.ps
PostScript Type 3. Several of these fonts come with the Sun OpenWindows distribution. They can be loaded into the X11/NeWS server with the ldf program.
Compressed file. This extension indicates that the compress program has been run on the font file. This should reduce the size of the file on disk. Some servers (such as those from MIT) can read compressed fonts directly, but this is not true for all implementations.
5.2.3 Format Conversion Tools
There are several commands for converting from one format to another, as illustrated in Figure 5-4. The following are some common examples. See the manual pages for these commands for more information.
bdftosnf
Converts BDF to SNF. This command should come with any server that uses SNF, such as the stock MIT server Releases 2 through 4. Example usage:
# bdftosnf myfont.bdf > myfont.snf
bdftopcf
Converts BDF to PCF. This command should come with any server that uses PCF, such as DECWindows and MIT Release 5. Example usage:
# bdftopcf -o myfont.pcf myfont.bdf
dxfc
Converts BDF to PCF. This command is distributed with DECWindows. Example usage:
# dxfc myfont.bdf > myfont.pcf
snftobdf
Converts SNF back to BDF. This program can be found on various anonymous ftp sites and X source archives.* Example usage:
# snftobdf myfont.snf > myfont.bdf
convertfont
Converts BDF to several X11/NeWS formats and back. This command comes with Sun OpenWindows. Example usage:
# convertfont -f 32 myfont.bdf
See Section 5.3.6.3 for an example using convertfont.
fstobdf
Dumps the BDF version of any font available to the font server. See Section 5.5 for more information on the font server.
# fstobdf -s tcp/harry.ora.com:7000 -fn fixed > fixed.bdf
getbdf
Dumps the BDF version of any font available to the X server. See Section 5.3.4.2 and 5.3.5 for examples of using getbdf.
# getbdf -font 9x15 > 9x15.bdf
Converts F3 fonts into Adobe Bitmap Format. This is an intermediate format used when converting X11/NeWS fonts.
# makeafb -16 LucidaSans-Bold.f3b
Note that font files can be read by some servers in a compressed format, so administrators may be able to save space by compressing font files on their systems. Compression may cause some performance loss, as the fonts will have to be uncompressed by the server when they are read. The space savings is desirable, as you are likely to accumulate hundreds of fonts once you get the hang of it. The fonts may turn out to be the single largest consumer of disk space of all the X components.
Be aware that converting a font from one vendor's machine for use on another may be illegal, attractive as the idea might be. There may also be restrictions on how the fonts are to be used—for example, they may be licensed for screen use, but not for hardcopy. Check the copyright notices before proceeding.
5.3 Adding New Fonts
There are lots of reasons to expand the numbers of fonts available. Some applications, especially desktop publishing packages, provide new fonts as part of their installation. Clients that support languages other than English are becoming commonplace and are widely available on the Internet—these clients require large numbers of new fonts to be added.
It is possible to access fonts in your home directory by adding paths to existing font paths with the fp option to the xset command. This is useful for testing. It also means that you can have users install the fonts they want in their own home directories if you don't think everyone will want to use them.
5.3.1 Adding a Single Font
Let's step through the procedure for adding a new font in a stock MIT R3 or R4 environment. (For an R5 environment running a font server, the font may already exist on another system and you can just tell the font server where it is. See Section 5.5 for more information.)
You may come across an application that requires some non-standard fonts, say a Kanji font for the OSF/Motif demo program hellomotif.* This font is distributed in BDF format.
- Convert it to SNF (or whatever is appropriate for your server) with the bdftosnf command:
# bdftosnf -t k14-1.bdf > k14-1.snf # bdftosnf -t rkana14.bdf > rkana14.snf
The -t flag indicates that these fonts are going to be displayed on a “terminal” (such as xterm) and each character should be same size.
- Copy the SNF files into one of the font directories. For this example, the misc directory is a good candidate:
# cp k14-1.snf /usr/lib/X11/fonts/misc # cp rkana14.snf /usr/lib/X11/fonts/misc
- Rebuild the fonts.dir file with the mkfontdir command:
# mkfontdir /usr/lib/X11/fonts/misc
This command will increment by 2 the number of fonts listed on the first line of the fonts.dir file, and add two pairs of entries: the filename and the font name.
k14-1.snf -k14-screen-medium-r-normal--14-140-75-75-m-140-jisx0208.1983-1 rkana14.snf -romankana14-screen-medium-r-normal--14-140-75-75-m-70-jisx0201. 1976-0
The next step would be to add aliases to fonts.alias for convenience. In the hellomotif case, the application requests the font by its full name, not by an alias—so unless you intend to access the font from other applications, it probably isn't worth aliasing.
- Before the server can know about the new font, the font path needs to be rehashed. Otherwise, an error will be returned. For example, if you try to display the new font immediately with the xfd client, using the font name in the second column of the fonts.dir file:
% xfd -fn -k14-screen-medium-r-normal--14-140-75-75-m-140-jisx0208 .1983-1
you will get an error such as:
Warning: Cannot convert string “-k14-screen-medium-r-normal--14-140-75-75 -m-140-jisx0208.1983-1” to type FontStruct
For the modified fonts.dir file to be reread without restarting the server, you must run the xset command:
% xset fp rehash
Try xfd again to verify that it worked. If xfd can display the font, it is likely to be available for any client that requests it from your server.
Your server may cache a font, so don't expect a font to disappear immediately even if you delete the file that contains it on disk.
5.3.2 Adding Multiple Fonts
Some applications may require that a large number of fonts be added to your local font area. One example of this is the public domain TeX dvi file previewer xtex.* TeX is a popular typesetting program that runs on most systems that are around today. A dvi file is the device-independent output of the TeX program. The term previewer refers to a program that displays something on your screen to preview what it would look like on the final output, which is usually done on a laser printer or typesetter.
The xtex program expects a separate X11 font to exist for each size (magsteps, for you TeX font weenies) of each TeX font requested by a dvi file.† In a situation like this, it is probably worth creating a new directory in your font area for easier administration.
There are a few advantages to breaking up the font area into subdirectories:
- By separating the “stock”, or “vanilla” environment from the “local” areas, administration is easier. You can save a lot of time when upgrading, as you don't have to worry about trashing all your hard work if you have distinct areas that won't be overwritten by a software upgrade. This concept can be applied to other areas of X, where it may be desirable to keep files that you install in an area separate from the vendor-supplied files.
- Multiple subdirectories give you, the administrator, control over whether or not to export the font areas in a networked filesystem. You may want to give the font areas different permissions, or to give a group of users and programs permission to add new fonts without intervention of the system administrator. TeX programs are an example of this, as some are able to create fonts “on-the-fly” and want to add the newly created font to a font area so it will be there the next time it is requested.
- By breaking fonts up into multiple directories, you also make it easier to view the directory contents. The TeX example alone has several hundred entries.
The disadvantages to this approach include the fact that special knowledge is required by the end users if they want to access a font in a nonstandard directory (you could alleviate this problem by providing new users with start-up files that include these special paths).
5.3.2.1 Multiple Font Example
For the xtex example, let's create a subdirectory in the font area called tex. The xtex package describes how to create the SNF files from the BDF files in the distribution.
- Once the SNF files are created, copy the SNF files to the new directory and rebuild the fonts.dir file:
# cp *.snf /usr/lib/X11/fonts/tex # cd /usr/lib/X11/fonts/tex # mkfontdir
If you get an error such as:
Duplicate font names cmr10 cmr10.snf goof.snf mkfontdir: failed to create directory in .then there is more than one font with the same name. In this rigged example, two .snf files for the same font exist in a common directory. The solution would be to delete the one you do not want from this directory.*
- Since you are adding a new area to the font search path, you will need to tell the server where to look with the xset command.
% xset fp+ /usr/lib/X11/fonts/tex
You probably made a typo or specified an invalid pathname if you get an error such as:
X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 51 (X_SetFontPath) Minor opcode of failed request: 0 Resource id in failed request: 0x4 Serial number of failed request: 5 Current serial number in output stream: 8 - Verify your current font path using the xset command:
% xset -q Font Path: /usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/75dpi/, /usr/lib/X11/fonts/100dpi/,/usr/lib/X11/fonts/tex
Note that, in order to access the new fonts, users have to run the xset fp+ command specified above every time they start their server. Their .xsession or .xinitrc files would be an appropriate place for the command. For sites that start their X sessions from xdm, you can add local changes like this one to the xdm startup files. This will add the font path for all users who start their X sessions using xdm.
Rather than creating multiple font directories to be added to the font path of each server, you could just put all non-standard fonts into one directory, for example, /usr/lib/X11/fonts/local. Some vendor implementations (such as DECWindows) provide a “local” directory structure just for this purpose. The path is already known to the server, so you can add fonts and they will be available without further changes.
You could also define this path within the default search path when you build the X11 distribution from source (using the DefaultFontPath build flag) or supply a font path when starting the X server. See Section 8.5 for information on how to change your build flags when building X11 from source. To supply a new font path when starting the X server, most servers accept a -fp option on the command line.
5.3.3 Problems with Running Vendor-specific Clients
The fonts available to a server vary from one vendor to another. If a client requests a font from the server and it is not recognized, this may render an application unusable or just make it look strange.
Let's say you are on a Sun running an MIT Release 4 server and wish to run the DECWindows desk calendar dxcalendar off a remote Ultrix host. dxcalendar looks for specific fonts that are not available on the Sun, and the program will complain about the missing fonts:
scud% dxcalendar X Toolkit Warning: Cannot convert string “-*-MENU-MEDIUM-R-Normal -*-120-*-*-P-*-ISO8859-1” to type FontList, using fixed font X Toolkit Warning: Cannot convert string “-*-Menu-Medium-R-Normal -*-100-*-*-P-*-ISO8859-1” to type FontList, using fixed font X Toolkit Warning: Cannot convert string “-*-Menu-Medium-R-Normal -*-120-*-*-P-*-ISO8859-1” to type FontList, using fixed font
The application in this example will still run, but it doesn't look as good as it should.
The InfoExplorer utility in AIXWindows also has its own set of fonts. While InfoExplorer will run without its fonts, you can improve its appearance on a non-AIXWindows server by making these fonts available to it.
The OpenWindows cm (calendar manager) is a highly desirable program, but it, like most OpenWindows applications, will look terrible running under the MIT R4 server if you don't make its special fonts available. It will also complain about missing fonts:
h-street% cm XView warning: Cannot load font ′-b&h-lucida-medium-r-normal-sans-* -90-*-*-*-*-*-*' (Font package) XView warning: Cannot load font ‘-b&h-lucida-bold-r-normal-sans*-9 0-*-*-*-*-*-*' (Font package)
For all these examples, the solution is to make the font available to the local server. (This may cause some confusion for people new to X, as the fonts might appear to be available along with the clients on a remote host.)
Sometimes the solution to supplying a missing font may be as simple as creating an alias to it from an existing font. It is also possible to convert fonts required by a special client into a format that is recognized by your server, but this may involve some work. The getbdf program is one such font converter that may work.* getbdf can query the server for a font and dump it out in the bdf form, which can then be converted into the local font format.
In most cases, you should do the conversion from bdf to your local format on the machine where the fonts are going to reside. This should avoid any problems with byte order when the conversion takes place.
The font server introduced in MIT R5 will probably eliminate these problems, but it will take some time before the font server is available for all X servers. In the meantime, the techniques introduced here should suffice.
These examples may not match the exact problem you are having. Think of them as “case studies” that show problem solving techniques. The purpose of this section is to demonstrate that it is possible for the administrator to compensate for differences between vendor implementations.
5.3.4 DECWindows Examples
The DECWindows software contains fonts in the directory /usr/lib/X11/fonts/decwin that do not exist in the MIT X11R4 release. There are two ways to get around this problem: alias the DECWindows fonts to existing MIT fonts, or you can convert the DECWindows PCF fonts into SNF fonts that can be used by the MIT R4 server.
For an example problem, the dxcalendar program does not look quite right without the DECWindows fonts.
5.3.4.1 Aliasing
In recent versions of DECWindows documentation (UWS Release Notes), DEC supplies a fonts.alias file that maps the DEC font names to reasonable MIT equivalents. The top of the file looks like this:
-Adobe-“ITC Avant Garde Gothic”-Book-R-Normal--10-100-75-75-P-59-ISO8859-1 -Adobe-Helvetica-Medium-R-Normal--10-100-75-75-P-56-ISO8859-1 -Adobe-“ITC Avant Garde Gothic”-Book-R-Normal--12-120-75-75-P-70-ISO8859-1 -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 -Adobe-“ITC Avant Garde Gothic”-Book-R-Normal--14-140-75-75-P-80-ISO8859-1 -Adobe-Helvetica-Medium-R-Normal--14-140-75-75-P-77-ISO8859-1
The file is rather long. It also exists on various ftp sites, if you don't want to type it in.* You can append it to an existing fonts.alias in the 75dpi or misc directory on the host where you run the server from:
- In this example, the aliases are added to the misc directory:
# cd /usr/lib/X11/fonts/misc
- Make a backup copy of the original fonts.alias file:
# cp fonts.alias fonts.alias.orig
- Append the new aliases:
# cat DECwindows_on_X11R4_font.aliases >> fonts.alias
- Tell the server about the new fonts and try it out:
% xset fp rehash % dxcalendar &
5.3.4.2 DECWindows Conversion
Another option is to use a program that extracts fonts from the server and outputs them in BDF format. You can then convert them into SNF or whatever your local server requires. Once they are in your local format, you can add them to your font directory.
- Compile the getbdf program on the Ultrix host:
% cc -o getbdf getbdf.c -lX11
- On the Ultrix host, run the getbdf program to dump out the fonts into BDF format. Since fonts.alias contains the keyword FILE_NAME_ALIASES, you know that the filename of the font is also a valid name for the font. You can use this fact to automate the conversion process. If you are using csh, the following commands will convert each font in the directory:
# cd /usr/lib/X11/fonts/decwin/75dpi # foreach goo (*.pcf) ? set foo=`basename $goo .pcf` ? getbdf $foo > $foo.bdf ? end
The sh equivalent would be:
# cd /usr/lib/X11/fonts/decwin/75dpi # for goo in *.pcf > do > foo='basename $goo .pcf' > getbdf $foo > $foo.bdf > done
- Make a directory on the target machine for the new fonts:
# mkdir /usr/lib/X11/fonts/decwin
- Copy all the BDF files to the new directory on the target machine or access them via NFS. On the target machine, convert the BDF fonts to local format (SNF in this example) for your server. This example also uses csh:
# foreach goo (*.bdf) ? bdftosnf $goo > basename $goo .bdf`.snf ? end
The sh equivalent would be:
# for goo in *.bdf > do > bdftosnf $goo > `basename $goo .bdf`.snf > done
- Create the fonts.alias file:
# echo FILE_NAMES_ALIASES > fonts.alias
- Create the fonts.dir file:
# mkfontdir
- Add the new directory to your font path:
% xset fp+ /usr/lib/X11/fonts/decwin
- Try out a program that needs DECWindows fonts:
% dxcalendar &
5.3.5 AIXWindows Example
The InfoExplorer utility on the IBM RS/6000 running AIX also has its own set of fonts. The InfoExplorer fonts are in the directory /usr/lpp/info/X11fonts. As in the Ultrix example, you need to convert the fonts into BDF format and then into the native format of your server. You can use the same font conversion trick here that we used in the DECWindows conversion. In this example, the target server uses the SNF format.
- Compile the getbdf program on the AIX host:
% cc -o getbdf getbdf.c -lX11
- Use the getbdf program to dump the fonts into BDF format. Since the fonts.alias file contains the keyword FILE_NAME_ALIASES, you know that the filename of the font is also a valid name for the font. You can use this fact to automate the conversion process. This example is using csh:
# cd /usr/lpp/info/X11fonts # foreach goo (*.snf) ? set foo=`basename $goo .snf` ? getbdf $foo > $foo.bdf ? end
The sh equivalent would be:
# cd /usr/lpp/info/X11fonts # for goo in *.snf > do > foo=`basename $goo .snf` > getbdf $foo > $foo.bdf > done
- Make a new directory on the target machine for the new fonts:
# mkdir /usr/lib/X11/fonts/aixwin
- Copy all the BDF files to the new directory on the target machine or access them via NFS. You will also need fonts.alias file from the AIX machine:
% cp /usr/lpp/info/X11fonts/fonts.alias aixwin.alias
- On the target machine, convert the BDF fonts to SNF format for your server. If you are using csh, the following commands will convert each font in the directory:
# foreach goo (*.bdf) ? bdftosnf $goo > `basename $goo .bdf` .snf ? end
The sh equivalent would be:
# for goo in *.bdf > do > bdftosnf $goo > `basename $goo .bdf` .snf > done
- Copy in the fonts.alias file:
# cp aixwin.alias fonts.alias
- Create the fonts.dir file:
# mkfontdir
- Add the new directory to your font path:
% xset fp+ /usr/lib/X11/fonts/aixwin
5.3.6 OpenWindows Example
The cm desktop calendar program in the Sun OpenWindows 2.0 distribution does not work properly under MIT R4 without the fonts it needs. To demonstrate the problem, try running the cm program without the aliases.
The dates on the calendar are missing, because the necessary fonts are missing.
5.3.6.1 Aliasing
Most of these types of font problems can be handled by a few aliases. Aliases can be added to an existing fonts.alias file, such as the one in /usr/lib/X11/fonts/75dpi/. This example adds the necessary fonts to the fonts.alias file so you can run cm under an MIT R4 server. Simply append the following lines to the fonts.alias file:
-b&h-lucida-medium-r-normal-sans-9-90-75-75-p-58-iso8859-1 -b&h-lucida- medium-r-normal-sans-10-100-75-75-p-58-iso8859-1 -b&h-lucida-bold-r-normal-sans-9-90-75-75-p-58-iso8859-1 -b&h-lucida- bold-r-normal-sans-12-120-75-75-p-79-iso8859-1
Next, tell the server about them:
% xset fp rehash
Now, run cm again, this time with the aliases (see Figure 5-8.)
5.3.6.2 OpenWindows Conversion
An alternative to aliases would be to convert the OpenWindows X11/NeWS fonts into a form usable by the MIT server.* Since this procedure is unique to OpenWindows, it deserves an explanation.
The X11/NeWS fonts are outline fonts that are scaled to a requested size before rendering. These are stored with the .f3b extension. Some examples of the Lucida family of fonts are:†
LucidaBright-Demi.f3b LucidaSans-BoldItalic.f3b LucidaBright-DemiItalic.f3b LucidaSans-Italic.f3b LucidaBright-Italic.f3b LucidaSans-Typewriter.f3b LucidaBright.f3b LucidaSans-TypewriterBold.f3b LucidaSans-Bold.f3b LucidaSans.f3b
There is some overhead involved in scaling a font. In order to reduce this, some commonly used fonts can be pre-scaled. Pre-scaled fonts have the extension .fb. Some examples for the LucidaSans-Bold font are:
LucidaSans-Bold10.fb LucidaSans-Bold14.fb LucidaSans-Bold6.fb LucidaSans-Bold12.fb LucidaSans-Bold18.fb LucidaSans-Bold8.fb
These fonts are scaled at the point sizes of 6, 8, 10, 12, 14, and 18.
5.3.6.3 Converting from X11/NeWS to PCF or SNF
It is possible to convert the X11/NeWS format into BDF and then into the local format for your server. As an example, if you need a “Lucida-Sans-Bold” font in 10 point:
- Find the pre-scaled X11/NeWS version. It will have a .fb extension and have the point size as part of the name:
# cd /usr/openwin/lib/fonts # ls LucidaSans10.fb LucidaSans-Bold10.fb
- Convert the font into BDF format. The convertfont program understands a variety of formats: the -x flag tells it to output the font in BDF format. The -d flag specifies the directory where the BDF version of the font will be written and the -s flag specifies the point size.
# convertfont -x -d /tmp -s 10 LucidaSans-Bold10.fb LucidaSans-Bold10.fb->/tmp/LucidaSans-Bold10.bdf
- Convert the font into the native format of your server (in this example, SNF).
# bdftosnf LucidaSans-Bold10.bdf > LucidaSans-Bold10.snf
5.3.6.4 More Conversions
You may want to generate pre-scaled OpenWindows fonts at new point sizes. These can be used under the OpenWindows server or converted for use by the MIT server.
For this example, let's assume you want to generate a 16-point version of LucidaSans-Bold. There are several steps needed to do this:
- Convert the F3 format font (.f3b) into an Adobe ASCII format bitmap font (.afb) at the size you require (16). The -M flag suppresses generation of an Adobe ASCII format metric file (.afm):
# makeafb -16 -M /usr/openwin/lib/fonts/LucidaSans-Bold.f3b Creating LucidaSans-Bold16.afb
- Convert Adobe ASCII format bitmap font into X11/NeWS format:
# convertfont -b LucidaSans-Bold16.afb LucidaSans-Bold16.afb->./LucidaSans-Bold16.fb
- In order for the OpenWindows server to be able to use the font, you have to rebuild the Families.list file with the bldfamily command.
# cd /usr/openwin/lib/fonts # bldfamily * Terminal-Bold /usr/openwin/lib/fonts/TerminlB.ff (Encoding: latin) * Terminal /usr/openwin/lib/fonts/Terminal.ff (Encoding: latin) ... * ni12 /usr/openwin/lib/fonts/ni12.ff (Encoding: unknown) * k14 /usr/openwin/lib/fonts/k14.ff (Encoding: unknown) ...
Error messages such as:
cat: ./Compat.list: No such file or directory
or:
* .... .....ff (Encoding: unknown)
can be ignored. The Compat.list and Synonyms.list files are optional, much in same manner as fonts.alias.
The font is now ready to be used by the OpenWindows server or converted to a MIT format using the method described in Section 5.3.6.3.
5.4 Providing Fonts Over the Network
Diskless workstations and X terminals present a new set of problems for font administration. For an X server to display text on a diskless workstation or X terminal, it has to have access to fonts on a remote host, since X terminals don't have any local permanent storage. X terminals will typically come with a small set of fonts (usually fixed, at the minimum) that are stored in ROM, but need to read additional fonts over the network to be useful.
TFTP access is often needed for X terminals to boot off the remote host. When an X terminal is initially powered up or rebooted, it broadcasts a request for boot services over the network and a designated host downloads a kernel or server to the X terminal. See Section 7.4 for more information on fonts and X terminals.
Fonts can also be downloaded using the same mechanism after the X terminal is up and running, but a more flexible approach is to NFS-mount the fonts from a remote host. The server can then add fonts “on-the-fly” after booting. Unfortunately, this also implies all the normal administration problems associated with NFS, such as access control, network loading, and server failures. When using NFS, X terminals become closer to the diskless workstations that they were designed to replace, as they are subject to the same problems. See Section 7.4.3 for more information.
5.5 The R5 Font Server
Previous to Release 5, fonts on the X Window System needed to be available on local disk or provided over the network via TFTP or NFS. Starting with R5, fonts can be requested from a font server.
The font server is a program that runs on a host somewhere on the network and provides fonts to your X server. This makes font administration easier, as you can have several sources for a given font, which makes font access more reliable and less dependent on a single host. It also separates font problems from TFTP and NFS problems.
The font server can understand several different font formats. This means that all you have to do to make a font available is to run the font server on the host where the font resides. You no longer have to copy over the font and convert it to a format recognized by your local server. This is great for multi-vendor environments where you have many different font formats, as clients can run under any server and are still able to access special fonts they may require.
There is a host-based security mechanism to limit font access to a group of hosts. This can be used when making licensed fonts available with the font server. The number of simultaneous connections to the font server can be controlled, preventing the font server host from being overloaded. Font requests can also be passed onto other font servers if the current one becomes overloaded.
The font server program supplied in MIT R5 is called fs and is usually installed as /usr/bin/X11/fs. The font server is described in the manual page for fs. If you have access to the MIT source code, the file mit/doc/fontserver/FSlib.doc describes the font server library functions and mit/doc/fontserver/design.ms provides a detailed description of the font server design.
5.5.1 The Configuration File
The font server's operation is controlled by a configuration file, usually named /usr/lib/X11/fs/config. If you are building R5 from the MIT source code and want to use the font server, you may want to enable the InstallFSConfig flag in your config/site.def file. Setting the flag to YES will copy a sample font server configuration file into /usr/lib/X11/fs/config when the make install is performed. See Section 8.5.1 for more information on configuring X11 at build time.
The syntax of the configuration file is pretty simple. The following is a sample file that contains every option:
# font server configuration file (kitchen sink version) # cache-size = 2000000 # alternate-servers = pepper.ora.com:8000,bigbird.ora.com:8001 # catalogue = /usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/Speedo/, /usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/100dpi/ # client-limit = 10 # clone-self = on # default-point-size = 120 # default-resolutions = 75,75,100,100 # error-file = /var/log/fs # port = 7000 # trusted-clients = pepper,bigbird # use-syslog = off #
Any line starting with a “#” is treated as a comment and ignored.
The following keywords are defined in the configuration file:
cache-size
This is the number of bytes of memory that the font server will allocate in its font cache. The cache speeds up font access, as any recently requested font should still be in the cache and immediately available (otherwise, it would have to be read from a file on disk or scaled from an outline font). If the font server is running on a host that has lots of memory, make the cache size larger. The cache size is approximately 2 megabytes in this example.
This is a list of alternate font servers for this font server. If the current font server is unable to service the request, it supplies a list of alternate-servers to the X server, permitting the X server to try again at one of the alternate font servers. The name of an alternate server is a hostname and port number pair separated by a colon. The alternate servers are referred to as delegates in the MIT documentation. The primary server will supply a client with a list of alternate servers that it knows about. This example has two alternate servers, one on the host pepper and the other on bigbird.
catalogue
A list of font directories available from this server.* This example lists all the standard MIT R5 font directories. These can be stored in any format recognized by the font server. The font server currently understands the PCF, Speedo, SNF, and BDF formats, described in Section 5.2.2. This keyword should not be confused with the catalogue-list component of the font server name (see Section 5.5.6 for an explanation).
client-limit
The number of clients that the font server will allow before cloning itself or rejecting the connection. If the clone-self flag is set to off and a client attempts a connection, the font server will send back a reply listing other font servers that it knows about. These are specified in the alternate-servers list.
clone-self
Whether the font server should attempt to clone itself or use delegates when it reaches the client-limit. In this example, it is set to on and the font server would spawn another copy of itself if it received more than 10 (the client-limit) connections.
default-point-size
The default point size (in tenths of a point) for font requests that don't specify this value. These are called decipoints in the MIT documentation. The example value of 120 indicates a 12 point size.
default-resolutions
Default resolutions supported by the server. The numbers are pairs of horizontal and vertical resolutions per inch. Resolutions of 75x75 and 100x100 are specified in the example.
error-file
The filename of the error log file. You can use this if your system does not support the syslog() facility. This file would normally be the first place you would look when debugging the font server configuration file. Leave out this keyword if you have use-syslog enabled.
The TCP port number on which the font server will listen for client connections. Since the font server does not use a privileged port, a user can start up her own font server at any time. As you can choose the port number yourself, you can test the font server without disturbing other servers by selecting a unique port number. The MIT examples all use port 7000. This is a safe distance from port 6000, which is what the X server uses.
use-syslog
Whether syslog() is to be used for error logging. If set to on, font server errors will be sent to the LOG_LOCAL0 syslog facility. You will need to add a line to your /etc/syslog.conf file to capture the error messages in a file. If you log other messages to the directory /var/log, the following entry will add logging for the font server:
local0.debug /var/log/fs
This will log errors to the file /var/log/fs. See the manual page on syslog.conf(5) for more information on setting up syslog. If you want to use the error-file keyword, set use-syslog to off.
trusted-clients
The names of hosts the font server will supply fonts to. This can be used to restrict fonts to a certain group of hosts for licensing reasons. An empty list indicates that any host can make a connection to the font server.
You probably won't need to specify most of these options for your site. The MIT-supplied configuration file /usr/lib/X11/fs/config should be good enough to start with:
# font server configuration file # $XConsortium: config.cpp,v 1.7 91/08/22 11:39:59 rws Exp $ clone-self = on use-syslog = off catalogue = /usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/Speedo/,/usr/lib/X11/fonts/75 dpi/,/usr/lib/X11/fonts/100dpi/ error-file = /usr/lib/X11/fs/fs-errors # in decipoints default-point-size = 120 default-resolutions = 75,75,100,100
5.5.2 Installing the Font Server
If you wish to have the font server running all the time (as you probably do), you can add it to a system start-up file, such as /etc/rc.local. However, you probably should not add it to any system files until you are satisfied that it will work correctly. You can test it “by hand” by starting it on the command line.
5.5.2.1 Testing By Hand
The -config flag can be used to test a configuration file that is not yet installed or when you do not have write permission to /usr/lib/X11/fs:
# fs -config ./test-config &
If the font server dies with the error:
Error: Binding TCP socket: Address already in use Error: Fatal server error! Error: Cannot establish any listening sockets
there is probably another font server (or some other program) running with the same port number. You can specify a number other than 7000 (the default) with the port keyword in the configuration file or on the command line with the -port flag:
# fs -config ./test-config -port 7001 &
The SIGUSR1 signal will cause the server to reread the configuration file. Use this if you have edited the file and wish your changes to take effect without having to kill and restart the font server.
The SIGUSR2 signal will cause the server to flush the font cache. This may be desirable if you want the server to get a fresh copy of a font instead of using a cached version that may be out-of-date.
The SIGHUP signal is used to reset the server, closing all active client connections and rereading the configuration file.
You can kill the font server at any time by sending it the SIGTERM signal.
For example, under BSD UNIX:
# kill -TERM fs pid
Under System V:
# killall -TERM fs
When you are satisfied with the font server's configuration, it can then be added to the system boot files, which will automatically start it upon the next reboot.
5.5.2.2 Changing BSD Boot Files
In the BSD world, the /etc/rc.local file is the usual place to add new daemons. You will want to locate the entry for the font server before any other X11-related daemons (such as xdm), if they are going to need fonts from the font server.
For SunOS 4.x, an example /etc/rc.local entry would look like this:
#
# start up X font server
#
if [ -f /usr/bin/X11/fs ]; then
/usr/bin/X11/fs & echo -n ' fs’
fi
#
Under Ultrix, it would look like:
[ -f /usr/bin/X11/fs ] && {
/usr/bin/X11/fs ; echo ' fs’ >/dev/console
}
Examine your system's startup files and mimic the other daemon entries when adding the font server. The if or [ test syntax it designed to allow the system to continue the boot process without errors if the fs executable is missing.
5.5.2.3 Changing System V Boot Files
System V systems usually have a separate file for each daemon that is started when the system boots. Under IRIX (the Silicon Graphics System V derivative), adding the font server would take several steps:
- Create a shell script to control the font server in /etc/init.d. Check the current contents of this directory and pick a name for the script that describes it (fs is a good choice):
# cd /etc/init.d # ls MOUNTFSYS acct bsdlpr cron nck perf uucp README audio cdromd.2 1p netls savecore winattr RMTMPFILES autoconfig configmsg mail network sysetup xdm
The easy way to create a new script is to copy an existing one and modify it:
# cp xdm fs # edit file...
This script is copied from xdm and modified for the font server:
#!/bin/sh # # Start X Font Server # IS_ON=/etc/chkconfig FS=/usr/X11R5/bin/fs case “$1” in ‘start’) if test -x $FS; then if $IS_ON fs; then $FS & fi fi ;; ‘stop’) /etc/killall -TERM fs ;; *) echo “usage: /etc/init.d/fs {start|stop}” ;; esac - Create symbolic links to /etc/init.d/fs from the /etc/rc0.d and /etc/rc2.d directories. The format of the symbolic link name is either a “S” (for start) or a “K” (for kill), followed by a sequence number that determines the order of the file execution, followed by the name of the file in /etc/init.d. To determine the sequence number, you need to see what numbers are already in use. Here is a listing from a sample IRIX 4.0 system:
% ls /etc/rc2.d s01MOUNTFSYS S30network S50mail S70uucp S88configmsg S20sysetup S40nck S58RMTMPFILES S75cron S95autoconfig S21perf S45netls S60lp S78winattr S97cdromd S22acct S48savecore S61bsdlpr S83audio S98xdm
The S98xdm entry is for the xdm daemon. Since xdm may require the font server to be running before it starts, you should move it to the next highest number:
# mv S98xdm S99xdm
And then make a link to the file /etc/init.d/fs file:
# ln -s /etc/init.d/fs S98fs
Repeat the process for the /etc/rc0.d entry:
# ls K15cron K20mail K25lp K30netls K40network K90sysetup k18uucp K22acct K26bsdlpr K35nck K78winattr
In this case, there isn't a sequence number conflict with an existing script:
# ln -s /etc/init.d/fs K98fs
- The final step is to add an entry to the /etc/config directory to enable the script at boot time:
# /etc/chkconfig -f fs on
5.5.2.4 Changing AIX Boot Files
AIX is a combination of System V and BSD. Starting the font server consists of adding a line to /etc/rc.tcpip:
# Start font server start /usr/bin/X11/fs “” #
5.5.3 Font Server Name Syntax
Any client wishing to use the font server must be supplied with the name of the host where the font server is running and the port number that the font server is listening on. These two components uniquely identify a particular instance of the font server:
transport/hostname:port
The following are example font server names:
tcp/harry:7000 tcp/ruby.ora.com:7000 tcp/128.197.2.1:7001 tcp/fonts.ora.com:7002
The font server name can be specified on the command line with the -server option or set with the FONTSERVER environment variable. For example:
% setenv FONTSERVER tcp/harry:7000 % fsinfo
is equivalent to:
% fsinfo -server tcp/harry:7000
5.5.4 Debugging the Font Server
The fsinfo client gives a quick way to check if the font server is running or not. In this example, the font server is running on port 7000 on the host harry:
harry% fsinfo -server tcp/harry:7000
name of server: harry:7000
version number: 1
vendor string: MIT X Consortium
vendor release number: 5000
maximum request size: 16384 longwords (65536 bytes)
number of catalogues: 1
all
Number of alternate servers: 0
number of extensions: 0
The fsinfo client will also display any alternate servers known to the current server:
...
Number of alternate servers: 2
#0 bigbird:8001
#1 pepper:8000
...
If the font server is not running or if you have incorrectly specified the name of the font server, fsinfo will fail:
harry% fsinfo -server tcp/foo:1234 fsinfo: unable to open server “tcp/foo:1234”
If you have specified the host and port number correctly, make sure the font server program is still running. The ps command can be used to check for this.
Under BSD UNIX:
% ps agx | grep fs | grep -v grep 4237 ? IW 0:01 /usr/bin/X11/fs
% ps -ef | grep fs | grep -v grep root 169 1 0 Jan 2 ? 0:00 /usr/bin/X11/fs
If the process doesn't show up, there probably is a serious error in the configuration file or something else is wrong with your system.
If the font server has reached its client limit, a connection to it may fail with:
FSlib: connection to “rock:7000” refused by server FSlib: name of server: rock:7000 fsinfo: unable to open server “rock:7000”
Turning on the clone-self keyword or raising the client-limit are possible solutions.
If you have the error-file flag specified in the configuration file, all font server error messages will appear in the /usr/lib/X11/fs/fs-errors file (or the file specified with the error-file parameter). If the use-syslog flag is enabled, the errors will be logged in the file specified in /etc/syslog.conf for the LOG_LOCAL0 facility.
Any error message prefixed with CONFIG: has something to do with the configuration file. A typical error might be:
Error: CONFIG: can't open configuration file “/usr/lib/X11/fs/config”
/usr/lib/X11/fs/config is the default location of the configuration file. Make sure that the file exists and is readable. You can specify another location for the config file with the -config option to fs. (You might use this option if you are running your own private font server.)
If you get the following error:
Error: Can't open error file “/usr/lib/X11/fs/fs-errors”
the font server probably does not have write permission to the error file. Any errors will be sent to the controlling terminal or the console. You can specify a different file with the error-file keyword in the font server configuration file.
5.5.5 Font Server Clients
Once you have verified the existence of the font server, try requesting a font from it. There are several clients that have names that start with fs, indicating that they are for use with the font server.
The fslsfonts client is analogous to xlsfonts in that it lists the names of all available fonts or just those specified on the command line. It understands the same wildcard syntax you use when specifying fonts elsewhere.
Try a font that you know should be available from the server:
harry% fslsfonts -server tcp/harry:7000 -fn “fixed” fixed
fslsfonts: pattern “goof” unmatched
the font server configuration file probably has an error in one of the pathnames, or you have specified a non-existent font name.
The fstobdf client is used to produce a BDF version of a font requested from a font server. Using the fixed font as an example:
harry% fstobdf -server tcp/harry:7000 -fn fixed > fixed.bdf
This BDF file can then be converted to different formats for use by your server.
As the fstobdf client can be used to “steal” fonts from another host, you might want to use the trusted-clients parameter to restrict fonts that are licensed to specific hosts.
5.5.6 The Font Path and the Font Server
One or more font servers can be added to your font path in the same manner as font directories. These font servers will then be searched in the order they appear in the font path whenever a font is requested. This is the best way to add the font server functionality to clients, as it does not require any changes in the way clients are used.
To add a font server to your font path, just append or prepend it to the font path as you would do for a font directory. The syntax for naming a font server within the font path is simple. For example:
% xset fp+ tcp/harry:7000
The general syntax for TCP/IP networks is:
tcp/hostname:port-number[/catalogue-list[+catalogue-list]]
For DECnet it is:
decnet/nodename::font$objname[/catalogue-list[+catalogue-list]]
- The tcp or decnet string is the network transport or protocol used by the font server.
- The hostname (or DECnet nodename) is the name of machine where the font server is running.
- The port number is the port that the font server is listening on.
- The optional catalogue-list can specify a subset of the available catalogues available from that font server. Catalogue lists are separated by the “+” character. The term catalogue has two different meanings in the font server documentation, which may be confusing. The catalogue keyword in the font server config file specifies a list of directories and the catalogue-list in the font server is used to divide up all the available fonts into groups (or catalogues). The only catalogue currently supported by the font server is all. To enable a font server to access all the available catalogues (as you would normally want to do), just omit the catalogue list.
The following example has a font server running on the host harry.
First, check the current font path with xset:
% xset -q Font Path: /usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/100dpi/
Add the font server entry:
% xset fp+ tcp/harry:7000
Check the new path:
% xset -q Font Path: /usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/100dpi/, tcp/harry:7000
If you get the following error from xset:
X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 51 (X_SetFontPath) Value in failed request: 0x6 Serial number of failed request: 5 Current serial number in output stream: 8
either you made an error in the font server name, or the font server specified in the font path is no longer running.
Here are some more examples of valid font path entries:
tcp/harry:7000 tcp/aixfonts:8000,tcp/decfonts:7000 DECnet/SRVNOD::FONT$DEFAULT decnet/44.70::font$special/symbols
Font path additions can specified anywhere you would normally put them, such as in a user's .xsession or .xinitrc file:
... xset m 2 2 xset b 10 100 10 xset fp+ tcp/decfonts.ora.com:7000 xrdb $HOME/.Xdefaults xmodmap $HOME/.xmodmaprc twm & ...
This example assumes the font server will be running before the user's X session is started. If it is not running, the xset command will fail with the BadValue error shown previously.
5.5.7 Hostname Aliases
Using a hostname alias such as fonts.ora.com is a clever way to simplify font administration for a group of hosts. The name could be moved to another host without requiring configuration changes to the hosts that are requesting the fonts.
/etc/hosts
On a host using /etc/hosts just add the alias to /etc/hosts:
140.186.66.2 rock.ora.com rock decfonts decfonts.ora.com
NIS
If you are using NIS, the entry will have to be added on the NIS master for the NIS domain. Add an entry similar to the one described above and push the NIS hosts map.
DNS
On a host running DNS, add the following alias to the name server database:
decfonts IN CNAME rock.ora.com.
and tell the name server to reload the database.
You could use a separate font server to supply each group of fonts and have aliases for each of them. For example, a decfonts alias could be for DECWindows applications, an aixfonts alias could be for AIXWindows applications, and a texfonts alias could be used by TeX applications. Users can then select the font server according to the application and its font requirements regardless of what X server they are using.
5.5.8 A Font Server Example
The xtrek game provides a good example for using the font server.* It requires a special font, named xtrek, that normally has to be installed for every X server that the xtrek client is going to be displayed on. For local display servers running on workstations, this means that you have to copy the font into a local directory on each machine and run the mkfontdir command on every one of these hosts. A far better solution is to install the font on one host and run a font server that makes the xtrek font available to anyone wanting to play.
Let's assume you are on the host nugget and you want to start a game on the host rock.
You try to run xtrek, but it fails, as the font is not found by nugget's server:
nugget% xtrek rock Display: nugget:0.0 Login: eap Name: Dead Meat Adding player 0 on ‘nugget:0.0’. Not all fonts available on nugget:0.0.
To fix this problem, let's turn the host rock into a server for the xtrek font:
- The xtrek font supplied with source code is in the BDF format. Convert the font into a format recognized by your X server. In this example, the MIT R5 server expects the PCF format:
- Copy the font into the font area. In this example, the font will have its own directory, /home/eap/xtrek/fonts:
rock% mkdir /home/eap/xtrek/fonts rock% cp xtrek.pcf /home/eap/xtrek/fonts
- Create the fonts.dir file:
rock% mkfontdir /home/eap/xtrek/fonts
- Create a font server configuration file. The easiest way to do this is to copy and then edit the MIT example file /usr/lib/X11/fs/config:
rock% cp /usr/lib/X11/fs/config /home/eap/xtrek/fs-config rock% edit file...
The edited file now contains the following:
clone-self = on use-syslog = off error-file = /home/eap/xtrek/fs-errors catalogue = /home/eap/xtrek/fonts
- Start the font server:
rock% fs -config /home/eap/xtrek/fs-config &
- Go back to the host nugget and add the font server to the font path:
nugget% xset +fp tcp/rock:7000
- Now try running xtrek again:
nugget% xtrek rock Display: nugget:0.0 Login: eap Name: Dead Meat Adding player 0 on ‘nugget:0.0’. game starts successfully...
Note that this entire procedure can be performed by unprivileged users.
5.6 Related Documentation
The font clients are described in the manpages for xfd, xlsfonts, and xfontsel.
The font server clients are described in the manpages for fsinfo, fslsfonts, and fstobdf.
The OpenWindows font programs are described in the manpages for convertfont, makeafb, bldfamily, and the OpenWindows documentation set.
A technical description of X fonts is in the file mit/doc/XLFD/xlfd.tbl.ms (the PostScript version is mit/hardcopy/XLFD/xlfd.PS.Z).
For more information on the font server, see the manpage for fs and the original design document mit/doc/fontserver/design.ms. Beware of differences between this paper and the version of the font server included in the R5 distribution.
The Font Server Protocol is described in the file mit/doc/fontserver/FSlib.doc (PostScript version is mit/hardcopy/FSProtocol/fsproto.PS.Z).
“The X Administrator: Font Formats and Utilities,” by Dinah McNutt and Miles O'Neal, published in The X Resource, Issue 2, O'Reilly and Associates Inc., Spring 1992.
Section 5.5 of this chapter also appeared as an article entitled “The X Administrator: Managing Font Servers,” by Eric Pearce, published in The X Resource, Issue 3, O'Reilly and Associates, Inc., Summer 1992.
*One ftp site is export.lcs.mit.edu in contrib/snftobdf.tar.Z.
*OSF/Motif source can be purchased from the Open Software Foundation.
*xtex can be ftp'd from foobar.colorado.edu. It is part of a larger package called SeeTeX.
†The xdvi program also previews TeX dvi files, but is able to read TeX fonts directly without converting them to an X11 format. xdvi is available via ftp from export.lcs.mit.edu in /contrib.
*You could also change the name of the font in the BDF file before converting it into SNF, but something is probably wrong if you are having a name conflict.
*getbdf is available via anonymous ftp to larry.mcrcim.mcgill.edu as X/getbdf.c.
*One such ftp site is export.lcs.mit.edu, in contrib/DECwindows_on_X11R4_font.aliases.
*If you have a full OpenWindows distribution, BDF versions of the Lucida fonts can be found in the directory /usr/openwin/share/src/fonts/{100dpi,75dpi,misc}. They can be converted directly to your local server format using bdftosnf or bdftopcf.
†The pathnames listed in this example are from OpenWindows version 3.0. In Open Windows 2.0, the font names are abbreviated. For example, LucidaSans-Bold in version 3.0 was LcdS-B in 2.0.
*You may notice that the syntax described here differs from the paper “Font Server Implementation Overview,” (mit/doc/fontserver/design.ms) where a prefix of the font format, such as pcf or Speedo, is used in front of the font directory list. This feature is not used in the MIT R5 font server.
*xtrek is available via anonymous ftp as export.lcs.mit.edu:/contrib/xtrek.tar.Z.