filenames for fonts

[karl@cs.umb.edu (Karl Berry)]

This is a pretty long article, in response to Damian Cugley's recent
posting, and Liam Quin's response thereto, about a font naming scheme.
It has lots of quotes from those articles.  Sorry.

Damian> If we stick to the 6- or 8-character [font] names we have to resort to
> outrageous abbreviations
This much is true.  8 characters are not enough to unambiguously
represent all (perhaps even most) fonts, as my TUGboat article points
out.

Since we are stuck with 8 character filenames, however, we have to make
the best of it.  I think there is some value, however, to trying to
semi-rationalize the naming schemes for the actual files, even if we
adopt some name mapping scheme like yours.  So I am going to continue to
maintain the lists for 8 character filenames.  (This is not anything
against another scheme for longer names; in fact, I suggested a somewhat
similar scheme a couple months ago, and asked DEK if it was ok to
introduce font mapping files into TeX [he said yes]).

> Certain combinations of long suffixes, long <optional size>s and
> 3-letter font names might be able to lead to <cut>s more than 8 chars
> long.  This can be avoided by using a Univers-style numeric system
> ("68c" for semibold condensed italic caps-&-s.caps instead of
> "sbcicsc"), or simply shoved under the carpet...
I don't think this leaves us any better off than the current situation.
It's useless to try to make anything fit in 8 characters; it won't.  We
have to give up 8 characters (and therefore introduce mapping files) to
get complete unambiguity.

> The munging of file names is part of the system-dependent part of TeX.
> All this system requires is that "-" be given a special meaning.  What
> meaning exactly depends on implemntation.  
As above, I don't think it's plausible to map fontnames given to TeX
directly onto the filesystem, although it's a nice idea, and might work
in some cases.  For one thing, I personally don't like to have lots of
subdirectories for my fonts; instead, I put all the Adobe fonts, all the
CM fonts together, and so on.  So any prescriptive mapping of `-' to
`/' (i.e., directories) under Unix will make me unhappy, either at the
fontname end or the filename end.

>  \\ A Creton-X50 has a flat name space *and* short names.  All fonts are
>     given a code number when installed and are put in files with names
>     f0000, f0001, f0002, ...; a "directory file" contains a list of font
>     names and font code numbers.  <foundry>s and <families> have
>     associated directory files referenced from the top level directory
>     file.  In other words, the hapless Creton-X50 implementors have to
>     "roll their own" directory structure.  (This is why I limited <font
>     name>s to three <component>s.)
I don't think we lose much by making everybody ``roll their own''
directory structure, and require ``directory files'' (what I've been
calling mapping files, and we gain a lot (I think) by getting rid of the
limitation of <fontname>s to three components (as Lee said).

Lee> Note that it is useful to separate weight (bold, medium) from face
Lee> (roman, oblique, slanted, italic), so that using "cbo" for
Lee> Courier-Bold-Oblique is probably bad.

Damian> I am combining the "face" info into one word for several
Damian> reasons: firstly, TeX has no useful way to treat weight, width,
Damian> slant etc. separately;
TeX doesn't have a useful way to treat the variants differently, but
people do (it helps them parse; also, it could help programs parse).
Also, such combinations will lead to ambiguity once you try to come up
with a reasonably complete set of variants (believe me, I know).

> secondly, it's shorter; 
True, but if you're already saying Adobe-NewCenturySchoolbook, length is
already clearly not much of an issue.  As always, it's tradeoff:
convenience (short names) for completeness (unambiguous names)  It's
been ``convenience'' ever since the TeX project began (no reflection on
the designers, of course); if short names were good enough, then we
wouldn't be discussing this issue right now!

Damian> thirdly, it allows the old fonts -- cmr12 etc. -- to remain unchanged.
Also true, but I think the old fontnames are horrendous, and we
shouldn't cripple ourselves trying to be compatible with them.

Damian> the XLFD name
> -Adobe-New Century Schoolbook-Medium-I-Normal--24-240-75-75-P-136-ISO8859-1
I don't think we want the X naming scheme unchanged.  In particular, I
don't think the pixel parts of the name are relevant.

Damian> The extra "c" at the front is so that Courier doesn't get
> called "Adobe-Courier-", with nothing after the final "-".  
There's nothing wrong with this, in my mind.

Lee> I don't see any advantage in limiting font names to three components.

Damian> My scheme isn't supposed to classify every aspect of fonts in their
> names, (not useful IMO) but to help divide the huge namespace of possible
> fonts into useful chunks:
Fair enough, but I think one of the ways a font naming scheme can help
users is by giving users some kind of consistency between fonts --
Helvetica foo-bar-baz and Times foo-bar-baz should mean the same thing.
Too many fonts will fall into the ``miscellanous'' category if you use
single letters (that's what's happening to me).

(End of quotes.)

Also, there is another advantage to having consistent names -- then one
can write TeX macros which take advantage of the consistency to build
the names, without having to special case everything in sight (as, say,
lfonts.tex does).  TeX's handling of fonts has always been bad for
users; they just want to replace Computer Modern with Times by saying
something like
\typefacefamily = Times (or ptm, or something)
\resetfonts

Up to now, though, every new font family to come out requires new macros
to get at them.  I'm very sorry that I didn't require variant letters to
be alphabetical in my ``short filename'' scheme; now there are some
fonts which have the same variants but give them in different orders
(because Adobe did it that way).

My own proposal for a naming scheme goes like this :

  <foundry>-<family>-<weight>-<variants>-<expansion>-
    <script>-<encoding>--<size>

The <foundry> is the usual `Adobe' (I don't know if the names should be
case-sensitive or not) or the like.  Could also be `unknown', `pd', or
`weird' -- the latter meaning the rest of the name is nonstandard.  Or
maybe the <foundry> could be optional, and a leading `-' mean ``public
domain''.

<family> is the usual `Computer Modern' and the like.  Probably spaces
should be eliminated, leading to `ComputerModern', to make TeX macros
easier to write.

Everything else is optional.  The `--' before the <size> lets one
specify a name with, say, weight and variants, but then to skip the
<expansion>-<script>-<encoding>, and still give a size.

The <weight> and <expansion> are the usual thing.

I think each of the <variants> should be separated with some character
besides a - (=, say), thus: `Lucida-Bold-Sans=Typewriter--10'.
I guess that `raw' (needed for virtual fonts) can be a variant.

<script> is e.g., Greek.  Maybe `math' should be a script.

<encoding> is the font_coding_scheme -- `TeXextended' or `ISOLatin1' or
whatever. 

I suppose the <script> and <encoding> could be made into more variants.
I just felt somehow that those were independent of the more ``fontish''
qualities I saw as variants.

---

I don't know, upon rereading all the mail, and looking at the various
schemes people have proposed, I am feeling somewhat like the whole
problem just isn't worth it, and that struggling along with the current
scheme, where filenames are used directly as font names, might be good
enough.

karl@cs.umb.edu