How Fonts Interact with the X Server and X Clients
By Thomas Adam
[ The following is taken from a reply the author sent to TAG in response to a question about fonts. Some of the answers in TAG are so good that they simply deserve to be made into articles. :) -- Ben ]
Introduction
Behind the scenes, there's a fair amount that happens when an application requests the use of a font. Because many default installations include both the X server and their respective clients on the same machine, a lot of the functionality is masked. However, the X server plays a pivotal role in managing the fonts stored under it.
There are usually two different mechanisms at work, as far as fonts are concerned: one of them makes use of a font server, the other does not.
Fonts and their location
Taking a typical system that doesn't use a font server, font definitions
are a property of the X server; that is, it knows and keeps track of which
fonts are on your system. X11 defaults to looking for fonts in
/usr/lib/X11/fonts/*.
Typically, a standard definition from /etc/X11/XF86Config-4 (and newer xorg.conf) files might look like:
Section "Files"
FontPath "unix/:7100" # local font server
# if the local font server has problems, we can fall back on these
FontPath "/usr/lib/X11/fonts/misc"
FontPath "/usr/lib/X11/fonts/cyrillic"
FontPath "/usr/lib/X11/fonts/75dpi/"
FontPath "/usr/lib/X11/fonts/100dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/sgi"
FontPath "/usr/lib/X11/fonts/Type1"
FontPath "/usr/lib/X11/fonts/CID"
FontPath "/usr/lib/X11/fonts/100dpi:unscaled"
FontPath "/usr/lib/X11/fonts/75dpi:unscaled"
An application can request a font to display, and
the X server will obligingly look for it in the hash of directories it
stores (much like the one above). The command 'xset q'
will list that information [1], and indeed font
paths can be added to with 'xset +fp /some/location/'.
However, that does nothing more than append the directory definition.
In order for the X server to become aware of the fact that a new location
has been added, one has to rehash that with 'xset fp rehash'.
Font descriptions
There's a convenience mechanism within X11 fonts, and that is to alias font names. If we ignore TrueType fonts for the moment, the command 'xlsfonts' lists fonts like this:
-adobe-avant garde gothic-book-o-normal--0-0-0-0-p-0-iso8859-1 -adobe-courier-bold-o-normal--17-120-100-100-m-100-iso10646-1 ... [ Many more lines elided ]
Let's take one of them as an example — here's what each part does:
Figure 1: Structure of a typical font.
That's a lot of information, right? Well, yes, it is, but it's a lot of very useful information. Roughly (and off the top of my head) here's what each part means:
- Foundry refers to the company that produced the font (Adobe in this case).
- The family refers to the font type.
- The weight is the display of the font (which also includes normal).
- The various pixels and points refer to the size of the font with respect to the resolution of the displayed font (that's horizontal and vertical resolutions.)
- Spacing refers to whether the font is monospaced (m) or proportional (p).
All of this is very dull and boring, and of course it would be a nightmare if one had to remember all of that information in one go. This is where aliasing and wildcarding become useful.
Most X11 applications that use the X11 Resource Database (XRDB) allow various resources to be set with an appropriate font. Example:
*xterm.font: *courier-bold-o-*-120*
That should be pretty self-explanatory, right? That's analogous to the often used command-line [2] of:
<program> -fn '*courier-bold-o-*-120*'
The X server then has to look up that font, expanding the wildcard as it goes. This is largely left down to the user to ensure that the correct placement of any wildcards is accurate, since it will on many occasions match nothing or unintentional fonts due to it. The X server will traverse whatever is in its fontpath, in the order the directories are listed, until a matched font is found. I cannot stress the order enough — it's analogous to the way a binary is searched for, in one's $PATH. The first matching font is whatever is found within the list of fontpaths, even if two or more fonts are matched by the wildcard.
Aliasing is slightly different, in that rather than the user relying on wildcard matching, a "font.alias" file holds short names for fonts (alternate names, if you will). Here's a snippet of one:
lucidasans-bolditalic-8 -b&h-lucida-bold-i-normal-sans-11-80-100-100-p-69-iso885 9-1
Essentially, it's a two column file, with the alternate name in column one, and the actual font name in the second column. As before, if you use an alias to load a font, the X server will search each font directory in turn. This has the added benefit of being able to specify aliases for fonts in other directories.
A fonts.alias file is also associated with a fonts.dir file. You can think of this file as a massive database that the XServer uses. It's a bit like font.alias, except that this file lists the following:
Actual Font Name Font Name
When you ask the X server to search for a font, it will look in fonts.dir to ascertain the font based on either the long name, or the alias (since the alias is mapped before the fonts.dir is looked in.) If you've ever used the mkfontdir(1) command, this is what it does — creates font.dir files in each and every fontpath listed.
Font Servers
Now onto font servers: You don't need them. Really — unless you're in some large multinational corporation that has hundreds of workstations connecting to an X server with different vendors. In the R5 release of X11, they were used for uniformity, to ensure that font names remained consistent, so that applications could load fonts, thus sharing them. What happens is something like the following:
Figure 2: How XFS interacts with the X server and X client(s)
The machine "Server" has a number of services running on it -- including the XFS (X Font Server). The local X server running on a client is hence told to use a font server (which is typical of the line):
FontPath "unix/:7100"
The font server responds by supplying the X server on the client with a list of font names applications (X clients) can load and display on the screen. (Under the hood there's a lot which goes on, but I'll skip that.) Note the "role reversal" here [3]: the X server is the client with respect to the font server — hence it is itself a "font client" — other examples include a printer, which would also talk to the font server, where necessary (although not shown in the above diagram).
Old versions of Red Hat used to insist on running a TrueType font server, for no other reason than presumably to annoy everyone.
[1] Programatically, this can be achieved via the XSetFontPath() call.
[2] Note the hard quotation marks here, so as not to perform globbing at the shell.
[3] Rick Moen comments: Unix newcomers are often confused by the notion of applications being X11 clients and the graphical display being driven by a server process, which somehow is opposite to people's expectations. They think: surely the applications are serving up display data, thus making them servers, which the graphical display is receiving, thus making it a client. However, what's being served up, to both local applications and remote ones via X11 network access, is the graphical display software's drawing services, as a central system facility for all applications that need it. Thus the applications are, for that purpose, clients.
Talkback: Discuss this article with The Answer Gang
I used to write the long-running series "The Linux Weekend Mechanic", which was started by John Fisk (the founder of Linux Gazette) in 1996 and continued until 1998. Articles in that format have been intermittent, but might still continue in the future. I currently write occasional articles for LG, whilst doing a few things behind the scenes for it. I'm also a member of The Answer Gang.
I was born in Hammersmith (London UK) in 1983. When I was 13, I moved to the sleepy, thatched-roofed, village of East Chaldon in the county of Dorset. It is very near the coast, and Lulworth Cove, which is where I used to work. Since then I have moved to Southampton, and currently attend University there, studying for a degree in Software Engineering.
I first got interested in Linux in 1996 having seen a review of it in a magazine (Slackware 2.0). I was fed up with the instability that the then-new operating system Win95 had and so I decided to give it a go. Slackware 2.0 was great. I have been a massive Linux enthusiast ever since. I ended up with running SuSE on both my desktop and laptop computers. Although I now use Debian as my primary operating system.
I am actively involved with the FVWM project, writing documentation, providing user-support, writing ad-hoc and somewhat esoteric patches for it.
Other hobbies include reading. I especially enjoy reading plays (Henrik Ibsen, Chekhov, George Bernard Shaw), and I also enjoy literature (Edgar Allan Poe, Charles Dickens, Jane Austen to name but a few).
I am also a keen musician. I play the piano in my spare time.
Some would consider me an arctophile (teddy bear collector).
I listen to a variety of music.
