Font name mapping: success on a smaller scale

["Thomas J. Reid" <X066TR@TAMVM1.BITNET>]

During the development of TeXrox, a DVI driver for Xerox printers, I had
to resolve the problem of mapping font names (as given in a DVI file)
into font names for the printer.  Although this is not the same same
problem being faced by the current discussion on this list, it may be
constructive to review what I have done and see what ideas, if any, can
be applied to the current problem.
 
TeXrox can use fonts in two different ways: fonts can be resident on the
printer; or TeXrox will build a bitmap image of characters from fonts
which are not resident.  Resident fonts are considerably more efficient
than bitmapped ones.  However, the names of these resident fonts had to
be made to fit Xerox naming conventions.  Specifically:
 
   o Names can be from one to six characters consisting of letters or
     digits only
 
   o Separate resident fonts are required for different orientations
 
   o Separate resident fonts are required for different magnifications
 
   o For larger fonts, it is necessary to split a single "DVI font" (what
     TeX and the DVI file see as a single font) into multiple resident
     fonts
 
   o The names of the fonts need to be kept distinct from the names of
     other fonts already on the printer.
 
The input to my name mapping is, of course, the font name from a DVI file
(exclusive of the area portion).  At the time I devised my scheme (1986),
the input name was effectively unbounded (255 or fewer characters).
 
What I did was to declare that it was not practical to devise a formula
to map the names.  Instead, the program which converts PK/GF/PXL files
into Xerox fonts assigns the names using a sequential counter.  The format
of the name is:
 
   TFxxxo
 
where "xxx" is a three "digit" hexadecimal number assigned by the conversion
utility and "o" indicates the orientation (P for portrait, L for landscape,
I for inverse portrait, and J for inverse landscape).  "TF" stands for
TeX font which distinguishes the font from others on the printer.
 
If the "DVI font" requires multiple Xerox fonts because of size, the
conversion program outputs multiple fonts assigning different numbers
to the "xxx" portion of the name.
 
To make this mapping of names and handling of split fonts transparent to
the TeX user, the font conversion program also outputs an index file
under the name and magnification of the font as known by TeX which gives
the Xerox name or names.  TeXrox uses the index files to do all mapping
which makes the process transparent to the TeX user.
 
(Another feature of the index file is that it remaps character codes.
This was necessary since codes 0x00 through 0x0f are reserved for
Xerox fonts.)
 
This system has been successful because one program (the PK/GF/PXL to
Xerox font converter) assigns the Xerox names automatically.  Further,
the Xerox names are hidden from the user (unless one looks at the
resultant XRX file---which is only slightly more readable than a DVI
file).
 
Further, since maintenance of system files for the printers is already
centralized, the use of a central authority to define the mapping of
TeX/DVI names to Xerox names does not impose any burden.  Users can still
create and use their own fonts (TeXrox will bitmap them); they just can't
make them printer-resident without going through the central authority.
 
Trying to apply this type of a scheme to mapping "user font names" to
"internal names" does introduce some problems:
 
   o The need arises for a central authority to assign and distribute the
     font name mappings.
 
   o Changes to TeX and associated programs to use the mapping file
     need to be made and widely distributed.
 
   o It is difficult to insulate the end-user from the assigned (and
     generally meaningless) names.
 
   o Users will have difficulties creating their own fonts unless they
     register the names or some escape mechanism exists to allow them
     to use non-standard names.
 
However, some advantages can also be found:
 
   o A naming scheme of a letter followed by five letters or digits
     could easily be used to encode 1.57 thousand million font names;
     this should be sufficient ;-) and only uses six characters (of
     course, the dirty words need to be filtered out :-).  Other schemes
     are also possible giving millions of possible names in eight
     characters or less.
 
   o Having a font name mapping file allows a relatively non-system-
     specific utility to be written to let the user determine what fonts
     are available.
 
There are, I'm sure, many other pros and cons.  Of course, many of the
disadvantages and the second advantage will be seen regardless of how
the "internal" names are derived.
 
---Tom Reid