[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
commands very soon, otherwise you can forget about this).

Rainer