As more typeface families become available for use with TeX, the need for a consistent, rational naming scheme for the font filenames concomitantly grows. What follows is somewhat related to and a simplification of Mittelbach's and Schoepf's article in TUGboat, volume 11, number 2 (June 1990). The document you are now reading is an update of my article published in TUGboat 11(4) (November 1990), pages 512--519. Finally, Mittelbach wrote another article criticizing the scheme below in TUGboat 13(1) (April 1992), pages 51--53; most of his points are well-taken, but I saw no alternative then, and see no alternative now. Other of his points are addressed in the appropriate sections below.
Here are some relevant facts about fonts:
I know that these tables are incomplete. Please send me, by electronic
mail to karl@cs.umb.edu, any additions or corrections, as well as
any other comments you may have. There is also a (low-volume) mailing
list concerned with fonts and TeX in general (this scheme was
developed after discussions on that list, in fact):
tex-fonts@math.utah.edu.
Many people have contributed to this proposal. I would like to acknowledge in particular Barbara Beeton, Rocky Bernstein, Berthold K.P. Horn, Sebastian Rahtz, and Jean Rivlin. Tom Rokicki and Russell Lang gave it its first real test when they adapted it to Tom's DVI-to-PostScript translator, dvips.
Here is how I propose to divide up the eight characters (the spaces between the parts are only for readability, and of course should not be in the filename!):
S TT W V E DD
where
See the section on virtual fonts (towards the end) for an exception to the above.
The weight, variant, and width are probably all best taken from the original source of the typeface, instead of trying to relate them to some external standard.
Before giving the lists of abbreviations, let me point out some problems. I don't know of a good solution for any of them. Please let me know if you have ideas about any of them.
Minion-SwashDisplayItalic, which translates to the name
`pmnrwdi', seven letters long. If Adobe did proper design sizing,
the name would be nine letters long already--and the font isn't even
bold!
Minion-SwashDisplayItalic font mentioned above could also be
specified as `pmnrdiw'. This can be alleviated by always giving
the variant abbreviations in alphabetical order.
Second, two fonts can be given the same name. For example,
fcmrtc could be either Computer Modern typewriter condensed or
Computer Modern typewriter small caps. This problem can be alleviated
by adding `r' (or possibly `rr', in pathological cases) to the
end, meaning "normal width. But that will make the name too long in
many cases, and always specifies what should be redundant information.
Ideally, the various parts of the
name would be separated by something other than the empty string.
If you adopt this proposal at your installation, and find that you have fonts with some property I missed, please write to me (see the end of the article for various addresses), so I can update the lists. You can get the most up-to-date version of these lists electronically, by anonymous ftp from the host `ftp.cs.umb.edu', in the directory `pub/tex/fontname'. I will also send them to you by electronic mail, if necessary.
Graham Asher (`gasher@cursci.co.uk') has written a C routine to demangle these fontnames. See `fnget.h' and `fnget.c' in this distribution.
I give the letters in lowercase, which I think should be used on systems where case is significant. The lists are in alphabetical order by the abbreviation.
You should use the letter here which matches the vendor you obtained the font from. This doesn't necessarily mean that vendor is the original source; for example, Avant Garde was designed by Herb Lubalin for ITC, but Adobe also sells it. The name of the font that you get from Adobe should start with `p'.
Fonts that are distributed without any real attribution to the creator or by individuals who don't plan to start their own digital type foundries (Computer Modern, for example) can use `f'. People sometimes create their own personal fonts, not intended for distribution; for those, it doesn't make any difference what the name is.
It's unfortunate that the "bizarre" source `z' is needed; but some fonts just don't fit well into the naming scheme. Such fonts should be prefixed by `z' (in addition to the real source).
The source `r' is also unfortunate; it would be better to simply specify the encoding of the font, or whatever the virtual font changed or added, eliminating the rather artificial distinction between "raw" and "virtual" fonts.
In the introduction, I alluded to the fact that the same typeface design is often (in fact, usually) offered under different names by different vendors. This is because typeface names can be protected in many countries, including the United States, via trademarks. But typeface designs can be easily protected in only a few countries. (Incidentally, who the trademark belongs to doesn't necessarily have anything to do with who actually did the original design; in the case of Helvetica, it was the Swiss letterform designer Max Miedinger for, I believe, the Haas foundry.)
For an excellent article (still mostly up-to-date) on typeface protection, see `Notes on typeface protection' by Charles Bigelow in TUGboat volume 7, number 3 (October 1986). I have tried to summarize that article, and events since then, in the `Legal issues' section of the GNU fontutils manual.
This all leads to massive confusion for a typeface buyer, who knows what, say, Helvetica (a trademark of Allied Corporation) looks like--but probably doesn't know, or care, that Monotype's marketing department called one of their versions of Helvetica `Arial'. Rather than perpetuate this confusion, I believe it will be better to use the same name for the same design, in contrast to always using the vendor's name. (For one thing, this will help in conserving the number of typeface families, which, given the limited number of letters, is a desirable goal.)
In order to help users who may only know their vendor's name, and not the original name, I am maintaining the following table of typeface name aliases, organized alphabetically by typeface name.
The vendor who perpetrated the alias is given in parentheses, where known.
In order of lightest to heaviest (more or less):
hairline, extra light, light, book, regular, medium, demibold, semibold, bold, extra bold, heavy black, ultra, poster
Unfortunately, "variants" include scripts (Greek, Cyrillic) and font encodings (Adobe standard, alternate, expert), as well as true typeface variations (italic, typewriter).
Mittelbach in TUGboat 13(1) suggests that `typewriter' and `sans' should be identified as part of the typeface name, because there are few typeface families with these variants. I feel the typeface namespace is already too cluttered, and that logically they are variants.
If the variant is `r', and the width is also normal, both the variant and the width are omitted. When the normal version of the typeface is sans serif (e.g., Helvetica), `r' should be used, not `s'. Use `s' only when the typeface family has both serif and sans serif variants.
The variant `8' is marked "escape": this means the next character is also to be taken as a variant letter (and gives us another 36 characters). Here is the table for the escaped variants:
In order of narrowest to widest (more or less):
ultra compressed, extra condensed, compressed, condensed, narrow regular, extended, expanded, wide
Expansion or compression of fonts is sometimes done automatically (as
by the PostScript scale operator), and sometimes done by
humans. I chose `narrow' and `expanded' to imply the former, and
`condensed' and `extended' to imply the latter, as I believe this
reflects the most common usage. (Of course there is no general consensus.)
In concert with releasing TeX version 3.0 and Metafont version 2.7, Don Knuth wrote two new utility programs: VFtoVP and VPtoVF, which convert to and from "virtual" fonts. Virtual fonts provide a general interface between the writers of TeX macros and font suppliers. In general, therefore, it is impossible to come up with a general scheme for naming virtual fonts, since each virtual font is an individual creation, possibly bringing together many unrelated fonts.
Nevertheless, one common case is to use virtual fonts to map plain TeX's accent and other character code conventions onto a vendor-supplied font. For example, the DVI-to-PostScript translator Dvips (written by Tom Rokicki) does this for fonts given in the PostScript "standard encoding". In this case, each font consists of a "virtual" tfm file, which is what TeX uses, a "raw" tfm file, which corresponds to the actual device font, and a vf file, which describes the relationship between the two.
This adds another dimension to the font namespace, namely, "virtualness" (or rather, "rawness", since it is the virtual tfm files that the users want to see, and thus the one that should have the "normal" name, as given by the tables above). But we have already used up all eight characters in the font names (more, in fact).
The first solution, adopted in dvips, was this: prepend `r' to the raw tfm files; the virtual tfm files should be named with the usual source prefix. For example, Adobe's virtual Times Roman tfm file is named `ptmr', as usual; the raw Times Roman tfm file is named `rptmr'. To prevent intolerable confusion, I promise never to give a foundry the letter `r'.
But now, years after, I think there is a better solution: ignore the virtual/raw distinction in favor of the font encoding or other distinguishing characteristics. For example, the raw Times Roman font, using Adobe's encoding, could be named `ptmr0'; the virtual font, with the ersatz CM encoding, would be just `ptmr'.
This chapter gives two examples. Other examples (including the entire Adobe font catalog as of early 1991) are available by ftp or email (see section Introduction).
The fonts in the Univers typeface family were assigned numbers by its designer, Adrien Frutiger. (You can see the scheme on, for example, page 29 of The Art of Typo.icon.ography, by Martin Solomon.)
The names given here have to be prefixed with a source letter to actually be usable. Since my purpose here was just to demonstrate the correspondence between typeface variations and the naming scheme, I left the source out.
Here are names for the 35 standard PostScript fonts:
AvantGarde-Book
AvantGarde-BookOblique
AvantGarde-Demi
AvantGarde-DemiOblique
Bookman-Demi
Bookman-DemiItalic
Bookman-Light
Bookman-LightItalic
Courier-Bold
Courier-BoldOblique
Courier
Courier-Oblique
Helvetica-Bold
Helvetica-BoldOblique
Helvetica-NarrowBold
Helvetica-NarrowBoldOblique
Helvetica
Helvetica-Oblique
Helvetica-Narrow
Helvetica-NarrowOblique
NewCenturySchlbk-Bold
NewCenturySchlbk-BoldItalic
NewCenturySchlbk-Italic
NewCenturySchlbk-Roman
Palatino-Bold
Palatino-BoldItalic
Palatino-Italic
Palatino-Roman
Symbol
Times-Bold
Times-BoldItalic
Times-Italic
Times-Roman
ZapfChancery-MediumItalic
ZapfDingbats
As pointed out earlier, eight characters is not enough to unambiguously represent all fonts. To do that, we have to allow ourselves very long filenames. Right now, such a scheme could only be implemented on a few kinds of systems. But with a simple change to TeX, it could be used on all systems.
At the moment, most implementations of TeX look up a TFM file (as
part of the \font command), by searching for a file with the name
given by the user (possibly in any of series of directories). But if it
looks the name up first in another file, which specifies the
actual filename, the fontname given in the TeX source could be almost
anything at all, of any length.
In version 5.851d of Web2C, I implemented this mapping file. It has an
straightforward format: each line specifies the filename and the TeX
name for one font, separated by whitespace. Extra information on the
line is ignored; then more information could be specified for the
benefit of DVI-reading programs in the same file. Comments start with
% and continue to the end of the line, as usual.
Besides allowing long names, the mapping file could have additional advantages. The TeX source files could become more nearly system-independent, because the same font names could work on every system. Also, when combined with a consistent naming scheme, macros could be written to access any of a number of fonts. Right now, each font family has to have specialized macros written to deal with it.
Incidentally, Professor Knuth has approved this change as a legitimate "system-dependent" adaptation; a TeX with such a feature can still be called "TeX".
Once we allow ourselves long names, we can construct a naming scheme to handle arbitrary fonts without much difficulty. Here is one proposal:
source-family-weight-variants- width-encoding--size
The source is the usual Adobe or Autologic or
whatever, as well as unknown, pd, or weird---this
last meaning the rest of the name is nonstandard. If the
source is missing, i.e., the name starts with a -,
"public domain" is assumed. For fonts made by individuals, the
initials of the designer are probably a good source.
The family is ComputerModern or Times or whatever.
Everything else is optional. The -- before the size lets
one specify a name with, say, a weight and variants, but then skip the
width and encoding, but still be able to
give a size.
The weight and width are as described earlier.
If there is more than one variant, they are separated with some
character other than -, say =:
BigelowHolmes-Lucida-Bold-Sans=Typewriter--10
The encoding is what Metafont calls the
font_coding_scheme---the layout of the characters in the font.
For example, TeXExtended or ISOLatin1 or
AdobeAlternate. Perhaps this should be mandatory, as a font is
useless if you do not know its encoding.
Names are case-sensitive, for consistency with the rest of TeX and with PostScript, etc. Spaces cannot be used in the name, to make it easier for TeX to parse. Likewise, characters with default category codes other than letter or other should not be used.
Another possibility is to forget all the above, and simply use the
vendor's name (perhaps prefixed by the vendor):
Adobe-Times-Roman, say.