# TeX font hierarchies.

```   From: karl@cs.umb.edu (Karl Berry)

I don't think any one scheme will suffice at all sites.  (Clearly some
schemes are worse than others, on the other hand.)  Personally, I have
top-level directories named for the typeface family, e.g., `cm' and
`euler' or sometimes foundry (`adobe').  Then I put the font files under
there, since I don't have to support very many devices.  This makes
maintenance very easy (according to my way of thinking, I realize other
people think differently).  No one mentioned that alternative at all
(unless I missed it).

Instead, I believe drivers should not care what the names of the
directories are; instead, they should search subdirectories
automatically, to (perhaps) N specified levels.  (You definitely don't
want to do it fully recursively, because the bottom level always has a
zillion files, which you don't want to look at to discover they're not
directories.)  One of the Unix ports of TeX, web2c, does this for one
level now.  Then the installer can set up the directories however s/he
wants.

But this does not work if you have different devices, with different
mode_def parameters, but the same resolution, unless you have the name
of the device in your font file name.

Let me state the three guiding principles that led to my proposal:

1. In a Metafont run, I specify three fundamentally different
parameters:

- the font
- the output device
- the magnification factor

Therefore I propose that the structure of the .pk directories
reflect this.  Don't forget that the majority of all users are not
experts, and having the same structure on all levels is easier to
understand.

Since it is not possible to mix .pk files for different output
devices, it seems the easiest way to have different directories for
them.

2. I think that the prevailing convention of using

<font name>.<resolution times magnification>

as a .pk file name is inferior to using

<font name>.<magnification>

on the simple grounds that a given font specification in a TeX run
always maps to the same font file name in the latter convention,
irregardless of the output device.  Again, I think it is easier to
understand for a non-expert.

3. Since we have only 8+3 characters in an MS-DOS file name
one has to put part of information into the directory names.

Now, I hadn't thought before of putting different foundries into
different directories, but I find it very reasonable.

Finally, I think we should try to get rid of those drivers that assume
fixed directory structures or file names, and that do not support
font substitution.

(And, of course, we need them to conform to one standard for \special