[TAG] Confusion about linux fonts

[Thomas Adam]

On Wed, Jun 28, 2006 at 02:24:21PM +0530, J. Bakshi wrote:
> Dear list,

Hello,

> I am really confused that where does Linux actually search for fonts  
> ? I have flipped through my system (debian - sarge) and get two       
> locations                                                             
>
> 1] /etc/fonts and 2] /usr/share/fonts where the #1 location has three
> html files and #2 has fonts file.

You're probably running the latest version of X11.  They (as in
distributions) decided to change the location of some of the X11 paths,
most noticeable the deprecation of /usr/X11R6/bin, to further policy with
respect to the LSB (bollocks if you ask me, since doing this sort of
thing is always going to break stuff).

Note that with location 2 above that's probably containing some
true-type fonts that fc-cache(1) and friends look for (although see
below).

> I have true-type font server called xfs-xtt. below is the part of
> fonts from my XF86config-4

OK, I am going to explain all of this to you, in the hope that you then
realise why you don't need a font server at all.

Taking a typical system that doesn't use a font server, font definitions
are a property of the XServer, that is, it knows and keeps track of
which fonts are on your system.  X11 defaults to looking in the
following location for them:

``
/usr/lib/X11/fonts/*
''

... And indeed, this is what your FontPath definitions in your X11
config file refer to.  An application can request a font to display, and
the XServer will obligingly look for it in the hash of directories it
stores.   As you have found out, the command:

``
xset q
''

Will list that information [1], and indeed font paths can be added to with
the command:

``
xset +fp /some/location/
''

But that does nothing more than append the directory definition.  In
order for the XServer to become aware of the fact that a new location
has been added, one has to rehash that with the command:

``
xset fp rehash
''

There's a convenience mechanism within X11 fonts, and that is to alias
font names.  If we ignore true-type fonts for the moment, the command
xlsfonts(1) 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
''

Let's take one of them as an example -- here's what each part does:

``
     family	      width pixels  horiz res  average width
	|	       |       |      |		|
	|	       |       |      |		|
-adobe-courier-bold-o-normal--17-120-100-100-m-100-iso10646-1
   |		|   |		  |	  |  |	      |
   |		|   |		  |	  | spacing   |
foundry	    weight slant	points	vert res    char set
''

That's a lot of information, right?  Well, yes it is, but it contains 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 weight is the display of
the font (which also includes normal).  The family refers to the font
type.  The various pixels and points refers to the size of the font with
respect to the resolution of the displayed font (so 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 fonts is 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:

``
foo -fn '*courier-bold-o-*-120*'
''

What happens here is that the XServer then has to go and 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.  What happens here is the XServer 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 found within the list of fontpaths, even if two
or more fonts are matched by the wildcard.

Aliasing is a 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
''

(I've added the manual "\" for clarity).   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
XServer will search each font directory in turn which associates itself
with that font.  This has the added ability that a font can specify
aliases for other fonts in other directories as well.

Now, associated with a fonts.alias file, is a fonts.dir file.  You can
think of this file as a massive database 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 XServer 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.

Now onto Font Servers.  You don't need them.  Really.  Unless you're in
some large MNC which has hundreds of workstations connecting to an
XServer with different vendors.  In the R5 release of X11 what they were
used for was uniformity, to ensure that font names remained consistent
so that applications could load fonts, thus _sharing_ fonts.  What
happens is something like the following (excuse the ASCII art):

```
Server
+----------------------------------------+
| |Apache | |Exim   |  |      X11      | |
| |Service| |Service|  |   Font Server | |
+----------------------------------------+
			|   ^
	     +----------+   |
	     |Font Names    |
	     |		    | List Fonts
Workstation  v		    |
+---------------+	    |	+--------+
|   Xserver     | ----------+	|	 |
|		| <----------->	| Display|
|   XClient	|    Load Font	|	 |
+---------------+		+--------+
''

The machine "Server" has a number of services running on it --
including the XFS (X Font Server).  The local XServer 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 XServer on the client with a
list of font names applications (XClients) can the load and display on
the screen (under the hood there's a lot which goes on, but I'll skip
that).   Note here the "role reversal".  The XServer 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 show in the above diagram).

Does that help?

-- Thomas Adam

[1] Programatically, this can be achieved via the XSetFontPath()
    call.
[1] Note the hard quotes here, so as not to perform globbing at the
    shell.
-- 
"If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat." -- Incredible String Band.