What's in a name?

[XITIJSCH@DDATHD21.BITNET]

There were lots of postings on the coding of mode_def's in file
names. Rocky explained that he want to code the mode_def rather
cryptic in some file name part. I'm strongly opposed to this
proposal, an explanation follows. The explanation is a little bit
longer :-)
 
 
 
STRUCTURE OF FONT NAMES
=======================
 
Mode_def parts in font file names concerns only GF or PK (partly VF)
format. MF will not produce these mode_def parts. (At least it does
not do it up to now. Furthermore it will be difficult to alter it's
behaviour in a portable [e.g., covering more than UNIX directories]
fashion.) The move of the MF output to a different place is usually
done by a font generation script, or MF is already started at the
location where the font shall reside.
 
The software piece which must deal mainly with font names are DVI
drivers. As a member of the DVI standards committee I want to
summarize a long discussion on this topic. (For further reading you
may get the original postings to driv-l from different TeX archives.)
 
Complete font file names consist of three to four parts, which may
be, but are not necessarily, ordered like below:
 
 1. A base location where all fonts for a specific device reside.
        This may not be one place (e.g., one directory), there may be
    a list of different places to look at. But the places have in common,
    that all fonts which reside there may be used for this output device.
 
 2. A size specification.
        This is often called the scaling factor, the magnification, or
    the resolution.
 
 3. The type name.
        E.g., cmr10.
 
 4. The font file format.
        A coding for the format (PK, GF, ...). This part is optional as
    font codings may be detected from the magic numbers within the font
    files.
 
Please note that Rocky's UNIX example
 
    .../tex/fonts/300dpi/...
 
is not covered by the scheme above, item 1 is missing.
 .../tex/fonts will not be a practical valid specification for a
specific device.
 
There was the proposal that the base location includes the mode_def
name (somehow). (E.g., .../tex/fonts/canon_cx might be a valid base
location: Here reside fonts used for printers based on the Canon CX
print engine.) But this proposal assumes that the mode_def hints to a
device, not to the mode_def implementation.
 
I.e., show the specification, not the implementation.
    For me, it's just the usage of a well known principle
    of software engineering.
 
 
 
MODE_DEF PARTS IN FONT FILE NAMES MUST BE SPECIFIC TO PRINT ENGINES
===================================================================
 
All drivers assume that all fonts at a given base location will be
usable for one output device. It is possible that different fonts for
one device are created by different mode_def's. Then all these fonts
must be collected at one place. (Note that `place' here is not
identical to directory; `place' might be a directory list.)
 
A driver is otherwise not able to discover which fonts shall be used.
Of course we could have a separate fontname mapping which tells which
fonts are to be used with which output device.
    But why?
    We have such a mapping: It's our file system!
    Please don't make things more complicated as they are!
        Keep them plain and simple :-)
 
 
 
 
FONT FILE NAMES MUST BE UNDERSTANDABLE BY HUMANS
================================================
 
A TeX administrator wants to know which fonts are available in which
sizes for a device. He wants to do this fast, not searching through a
bunch of files which explains which XYZZY fonts and what GAGTGE
fonts are used for a Canon CX engine! (XYZZY and GAGTGE are
``constructed mode_def names.'')
 
Just have a look in the file system and say ls, dir, listc; whatever
your operating system supplies.
 
 
For a TeX user (well, we should not forget them :-) the same holds:
Have you ever met a user who wanted to know which fonts he may use?
I've met a lot of them.
    Then I explain the file structure and they may just look at the
files -- something they know already how to do it. I don't want to
explain them how they shall combine a constructed mode_def with an
external file to discover which fonts are available.
 
 
 
 
SUMMARY
=======
 
 -- We must collect fonts for different devices at different places,
    and then we may choose device-specific names for these places.
 
 -- These names should be understandable for humans, as they will look
    at the files.
 
 
 
 
Comments? Suggestions?
    Please don't forget the drivers!
 
 
--
Joachim
 
===========================================================================
Joachim Schrod
Secretary of the TUG DVI driver standards committee
Driver coordinator of DANTE
 
                        Email: xitijsch@ddathd21.bitnet