<< . .

. 39
( : 45)

. . >>

the display-size ˜ ™.
318 Appendix F: Font Metric Information

TEX builds up large delimiters by using “extensible” characters, which are extensible
speci¬ed by giving top, middle, bottom, and repeatable characters in an extensible
command. For example, the extensible left parentheses in cmex10 are de¬ned by charlist command
extensible oct"060": oct"060", 0, oct"100", oct"102"; labeled code
extensible command
this says that character code oct"060" speci¬es an extensible delimiter constructed
four codes
from itself as the top piece, from character number oct"100" as the bottom piece, and ,
from character number oct"102" as the piece that should be repeated as often as nec- ,
essary to reach a desired size. In this particular example there is no middle piece, but
headerbyte command
characters like curly braces have a middle piece as well. A zero value in the top, middle, headerbyte
or bottom position means that no character should be used in that part of the con- :
fontdimen command
struction; but a zero value in the ¬nal position means that character number zero is the fontdimen
repeater. The width of an extensible character is taken to be the width of the repeater. :
byte list
The ¬rst eight di¬erent sizes of parentheses available to TEX in cmex10, when
the user asks for ˜\left(™, look like this: numeric list
«« ,
¬ ¬¬


According to what we know from the examples of charlist and extensible above, the
¬rst four of these are the characters in positions oct"000", oct"020", oct"022", and
oct"040". The other four have character oct"060" on top; character oct"100" is at the
bottom; and there are respectively zero, one, two, and three occurrences of character
oct"102" in the middle.
Here is the formal syntax:
charlist command ’’ charlist labeled code
labeled code ’’ code
| label labeled code
extensible command ’’ extensible label four codes
four codes ’’ code , code , code , code
Notice that a label can appear in a ligtable, charlist, or extensible command. These
appearances are mutually exclusive: No code may be used more than once as a la-
bel. Thus, for example, a character with a ligature/kerning program cannot also be
extensible, nor can it be in a charlist (except as the ¬nal item).
The last type of information that appears in a tfm ¬le applies to the font as a
whole. Two kinds of data are involved, bytes and numerics; and they are speci¬ed in
“headerbyte” and “fontdimen” commands, according to the following general syntax:
headerbyte command ’’ headerbyte numeric expression : byte list
fontdimen command ’’ fontdimen numeric expression : numeric list
byte list ’’ code
| byte list , code
numeric list ’’ numeric expression
| numeric list , numeric expression
Appendix F: Font Metric Information 319

We shall defer discussion of header bytes until later, because they are usually unneces- font slant
sary. But fontdimen commands are important. Numeric parameters of a font can be
font normal space
speci¬ed by saying, e.g., isolated
italic correction
fontdimen 3: 2.5, 6.5, 0, 4x font normal stretch
font normal shrink
which means that parameters 3“6 are to be 2.5, 6.5, 0, and 4x, respectively. These are
the parameters that TEX calls \fontdimen3 thru \fontdimen6. (Parameter numbering font x height
is old-fashioned: There is no \fontdimen0.) x-height
font quad
The ¬rst seven fontdimen parameters have special signi¬cance, so plain - font extra space
has seven macros to specify them symbolically, one at a time: design size
at size
font slant (\fontdimen1) is the amount of slant per point; TEX uses this
information when raising or lowering an accent character.
font normal space (\fontdimen2) is the interword spacing. If the value is
zero, all characters of this font will be considered to be “isolated” in math
mode, so the italic correction will be added more often than otherwise.
font normal stretch (\fontdimen3) is the stretchability of interword spac-
ing, as explained in The TEXbook.
font normal shrink (\fontdimen4) is the shrinkability of interword spacing,
as explained in The TEXbook.
font x height (\fontdimen5) is the height of characters for which accents
are correctly positioned. An accent over a character will be raised by the
di¬erence between the character™s charht and this value. The x-height is also
the unit of height that TEX calls one ˜ex™.
font quad (\fontdimen6) is the unit of width that TEX calls one ˜em™.
font extra space (\fontdimen7) is the additional amount added to the nor-
mal interword space between sentences, depending on the “spacefactor” as
de¬ned in The TEXbook.
Parameters are zero unless otherwise speci¬ed.
Math symbol fonts for TEX are required to have at least 22 fontdimen param-
eters, instead of the usual seven; math extension fonts need at least 13. Appendix G of
The TEXbook explains the precise signi¬cance of these additional parameters, which
control such things as the placement of superscripts and subscripts.

The design size of a font is not one of the fontdimen parameters; it™s an internal
quantity of that is actually output among the header bytes as explained
below. When a TEX user asks for a font ˜at™ a certain size, the font is scaled by the ratio
between the “at size” and the design size. For example, cmr10 has a design size of 10 pt;
if a TEX user requests ˜cmr10 at 15pt™, the result is the same as ˜cmr10 scaled 1500™
(or, in plain terms, cmr10 with mag=1.5).
What does the design size really mean? It™s an imprecise notion, because there
need be no connection between the design size and any speci¬c measurement in a font.
Typographers have always been vague when they speak about “10 point” fonts, because
some fonts look larger than others even though the horizontal and vertical dimensions
are the same. It™s something like dress sizes or shoe sizes.
In general, the design size is a statement about the approximate size of the
type. Type with a larger design size generally looks bigger than type with a smaller
design size. Two fonts with the same design size are supposed to work well together;
320 Appendix F: Font Metric Information

for example, cmr9 and cmtt9 both have 9 pt design size, although the uppercase letters designsize
of cmtt9 are quite a bit smaller (˜A™ versus ˜A™).
check sum
The designsize must be at least 1pt #. And, as with all tfm dimensions, it Ramshaw
must be less than 2048pt #. Any other value is changed to 128pt #. Xerox
font coding scheme
looks at the value of designsize only when the job ends, so you font identi¬er
needn™t set it before characters are shipped out. At the end of a job, when the tfm ¬le substring
BCPL strings
is being written, checks to make sure that every dimension of the font is
less than 16 times the design size in absolute value, because this limitation is imposed
by the tfm ¬le format. Thus, for example, if the design size is 10 pt, you cannot have
a character whose width or height is 160 pt or more. If one or more dimensions prove
to be too big, will tell you how many of them had to be changed.
The headerbyte command is similar to fontdimen, but it gives 8-bit code
data instead of numeric information. For example,
headerbyte 33: 0, 214, 0, "c"
says that bytes 33“36 of the tfm ¬le header will be 0, 214, 0, and 99. The ¬rst four
header bytes (numbers 1“4) are automatically set to a check sum, unless you have
speci¬ed other values for at least one of those bytes. (This check sum will match a
similar value in the gf ¬le, so that other typesetting software can check the consistency
of the di¬erent ¬les they use.) Similarly, the next four header bytes (numbers 5“8) are
set automatically to the design size times 220 , unless you have speci¬ed something else.
TEX looks only at the ¬rst eight header bytes, so you needn™t use the header-
byte command if you are simply producing a font for standard TEX. But other soft-
ware that reads tfm ¬les may have a need for more header information. For example,
the original tfm format (developed by Lyle Ramshaw at Xerox Palo Alto Research
Center) included font coding scheme information in bytes 9“48 of the header, and
font identi¬er information in bytes 49“68. The design size of certain fonts was also
packed into byte 72. Each font in the “Xerox world” is uniquely identi¬ed by its font
identi¬er and its design size, rather than by its font ¬le name.
The “font coding scheme” is merely a comment that can be used to help
understand large collections of fonts; it™s usually a nice thing to know. Some of the
coding scheme names in common use are
TeX text TeX math italic
TeX typewriter text TeX math symbols
XEROX text TeX math extension
ASCII TeX extended ASCII
The coding-scheme string should not include parentheses.
Here are macros that can be used, if desired, to convert plain ™s
font identi¬er and font coding scheme into the format required by Ramshaw™s
original tfm ¬les:
def BCPL_string(expr s,n) = % string s becomes an n-byte BCPL string
for l:=if length(s)>=n: n-1 else: length(s) fi: l
for k:=1 upto l: , substring (k-1,k) of s endfor
for k:=l+2 upto n: , 0 endfor endfor enddef;
Appendix F: Font Metric Information 321

inner end; outer
def bye = if fontmaking>0:
headerbyte 9: BCPL_string(font_coding_scheme_,40); end
font metric command
special "codingscheme " & font_coding_scheme_;
headerbyte 49: BCPL_string(font_identifier_,20); WILDE
special "identifier " & font_identifier_;
headerbyte 72: max(0, 254 - round 2designsize); fi
end enddef;
outer bye,end;
These macros could be included among the local.mf extensions to plain.mf at partic-
ular installations. When a user says ˜bye™ instead of ˜end™, the additional headerbyte
documentation will then be automatically inserted into the tfm ¬le.
Let us now conclude this appendix by summarizing what we™ve learned. A
programmer can provide various types of information about how to typeset
with a font, by using font metric commands. Simple versions of these commands,
su¬cient for simple fonts, are standard operations in plain ; examples have
appeared in Chapter 11 and the beginning of Appendix E. The general cases are
handled by ¬ve types of font metric commands:
font metric command ’’ ligtable command
| charlist command
| extensible command
| fontdimen command
| headerbyte command
This completes the syntax of that was left slightly un¬nished in Chapter 26.

Such things induced me to untangle the chaos
by introducing order where it had never been before:
I think I may say I have had the good fortune to succeed
with an exactness & a precision leaving nothing more to be desired,
by the invention of Typographic points.
” PIERRE FOURNIER, Manuel Typographique (1764)

One should absorb the color of life,
but one should never remember its details.
Details are always vulgar.
” OSCAR WILDE, The Picture of Dorian Gray (1890)
(page 322)

Appendix G: Generic Font Files 323

™s main output goes into a gf or “Generic Font” ¬le, so-called because gf
device driver
it can easily be translated into any other digital font format, although it does dvi
not match the speci¬cations of any “name brand” manufacturer. The purpose day
of this appendix is to explain exactly what kinds of information go into the gf year
¬le, and under what circumstances puts things there. time
Special commands
A gf ¬le is a compact binary representation of a digitized font, containing all
the information needed by “device driver” software that produces printed documents proo¬ng
from TEX™s dvi ¬les. The exact internal representation scheme of gf ¬les doesn™t proofrule
concern us here, but we ought to know what type of data is encoded.
The ¬rst thing in a gf ¬le is a string that explains its origin.
writes strings of the form

METAFONT output 1986.06.24:1635

based on the values of the internal quantities day , month , year , and time when the
gf ¬le was started. (In this case day = 24, month = 6, year = 1986, and time =
16 — 60 + 35 = 995.)
After the opening string, the gf ¬le contains a sequence of “special” commands
interspersed with shipped-out character images. Special commands are intended to
provide a loophole for future extensions to ™s set of primitives, so that
itself will not have to change. Some specials are prede¬ned, but others
will undoubtedly be created in years to come. (TEX has an analogous \special
command, which puts an arbitrary string into a dvi ¬le.)
A special command gets into the gf ¬le when you say ˜special string ™ or
˜numspecial numeric ™ at a time when proo¬ng ≥ 0. A special string should come
before numspecial, and it should either be a keyword all by itself or it should consist
of a keyword followed by a space followed by additional information. Keywords that
specify operations requiring numeric arguments should be followed by numbers pro-
duced by numspecial. For example, the ˜proofrule™ macro in Appendix B expands
into a sequence of ¬ve special commands,

special "rule";
numspecial x1 ; numspecial y1 ;
numspecial x2 ; numspecial y2 ;

this represents a rule on the proofsheet that runs from point (x1 , y1 ) to point (x2 , y2 ).
If you say ˜grayfont gray5™, the grayfont macro in Appendix B expands to ˜special
"grayfont gray5"™. Software that reads gf ¬les will examine all of the special strings,
until coming to a space or to the end of the string. If the resulting keyword isn™t
known to the program, the special string will be ignored, together with all numspecials
that immediately follow. But when the keyword is known, the program will be able to
determine the corresponding arguments. For example, the GFtoDVI program described
in Appendix H knows about the plain keywords ˜rule™ and ˜grayfont™.
might also create special commands on its own initiative, but
only when proo¬ng is strictly greater than zero. There are two cases: (1) When a
title statement occurs, the special string ˜"title " & title ™ is output. (This is how
the phrase ˜The letter O™ got onto your proofsheets in the experiments of Chapter 5.)
(2) Just before a character image is shipped out, implicitly executes the
324 Appendix G: Generic Font Files

following sequence of instructions: xo¬set
if round xo¬set = 0: special "xoffset"; numspecial round xo¬set ; ¬ shipout
if round yo¬set = 0: special "yoffset"; numspecial round yo¬set ; ¬
A shipout command sends a digitized picture to the gf ¬le, if proo¬ng ≥ 0, chardp
but nothing is output if proo¬ng < 0. Furthermore the current values of charwd , chardx
charht , chardp , charic , chardx , and chardy are stored away for the current charcode ; chardy
these values are stored in all cases, regardless of the value of proo¬ng . The current charexists
character code is henceforth said to “exist.” picture
When a picture is shipped out, its pixels of positive value are considered to be
“black,” and all other pixels are considered to be “white.” The pattern of blacks and oriental
whites is encoded in such a way that doubling the resolution approximately doubles bye
the length of the gf output, in most cases.
reports its progress by typing ˜[c]™ on the terminal when character hppp
code c is being shipped out. (The ˜[™ is typed before output conversion begins, and ¬le name
design size
the ˜]™ is typed after; hence you can see how much time output takes.) If charext is check sum
nonzero, after being rounded to an integer, the typed message is ˜[c.x]™ instead; for charwd
example, ˜[65.3]™ refers to character 65 with extension code 3.
TEX allows only 256 characters per font, but extensions of TEX intended for
oriental languages will presumably use the charext feature. All characters with the
same code share the same width, height, and depth, but they can correspond to distinct
graphics if they have di¬erent extension codes.
A special command generally refers to the picture that follows it, rather than
the picture that precedes it. Special commands before the ¬rst digitized picture might,
however, give instructions about the font as a whole. Special commands that follow
the ¬nal picture invariably refer to the font as a whole. (For example, the ˜bye™ macro
at the end of Appendix F creates two special strings that will appear after the ¬nal
character of a font.)
No gf ¬le will be written unless a character is shipped out or a special com-
mand is performed at a time when proo¬ng ≥ 0, or unless a title statement is encoun-
tered at a time when proo¬ng > 0. When one of these things ¬rst happens, the gf
¬le receives its name. If no input commands have yet occurred, will set
the job name to ˜mfput™; otherwise the job name will already have been determined.
The full name of the gf ¬le will be ˜ jobname . resolution gf™, where the resolution
is based on the current value of hppp . (If hppp ¤ 0, the resolution will be omitted;
otherwise it will be converted to an equivalent number of pixels per inch, in the hori-
zontal dimension.) Subsequent input operations or changes to hppp will not change
the name of the gf ¬le.
The end of a gf ¬le contains a bunch of numeric data needed for typesetting.
First come the design size and the check sum; these match precisely the data in the
tfm ¬le, unless the header bytes of the tfm have explicitly been set to something else.
Then come the values of hppp and vppp . (These are the values at the end of the job,
so hppp might not agree with the resolution value in the gf ¬le name.)
Finally, the gf ¬le gets the charwd , chardx , and chardy of each existing char-
acter code. The values of chardx and chardy represent desired “escapements” when
characters are typeset on a particular device (cf. Chapter 12). The charwd values are
identical to the widths in the tfm ¬le.
Appendix G: Generic Font Files 325

The check sum is based entirely on the charwd data; two fonts with the same device driver
character widths will have the same check sum, but two fonts with di¬erent character
widths will almost never have the same check sum.
The purpose of check sums can be understood by considering the following
scenario: A font named cmr10 might be generated by at any time, pro-
ducing a tfm ¬le called cmr10.tfm and a gf ¬le called, say, cmr10.300gf. A document
named doc, which uses cmr10, might be generated by TEX at any time, producing a
dvi ¬le called doc.dvi; TEX had to read cmr10.tfm in order to produce this dvi ¬le.
Now on some future date, a “device driver” program will be used to print doc.dvi,
using the font cmr10.300gf. Meanwhile, the font may have changed. If the current
gf ¬le doesn™t match the tfm ¬le that was assumed by TEX, mysterious glitches will
probably occur in the printed document, because dvi information is kept concise by
the assumption that the device driver knows the tfm widths of all characters. Potential
problems are kept to a minimum if TEX puts the assumed design size and check sum
of each font into the dvi ¬les it produces; a device driver can then issue a warning
message when it ¬nds a gf ¬le that is inconsistent with TEX™s assumptions.

But if our Letter-Cutter will have no Forge,
yet he must of necessity accommodate
himself with a Vice, Hand-Vice, Hammers,
Files, Small and Fine Files (commonly called Watch-makers Files)
of these he saves all, as they wear out.
” JOSEPH MOXON, Mechanick Exercises (1683)

The natural de¬nition lists all possible generic characters.
” LINNÆUS, Philosophia Botanica (1751)
(page 326)

Hardcopy Proofs
Appendix H: Hardcopy Proofs 327

A font cannot be proved correct like a mathematical theorem; a font must be GFtoDVI
seen to be believed. Moreover, if some characters of a font are faulty, the best proof
way to ¬x them is to look at diagrams that indicate what went wrong. Therefore smoke
is incomplete by itself; additional programs are needed to convert low resolution proofs
the output of into graphic form. special
gray font
The purpose of this appendix is to discuss two such auxiliary programs, labels
which serve as examples of many others that could be devised. The ¬rst of proo¬ng
these, called GFtoDVI, takes gf ¬les and converts them into dvi ¬les, which can
be printed just like the output of TEX. Each character image in the gf ¬le will
have a printed page to itself, with labeled points and with bounding boxes just as
in the illustrations we have seen throughout this book. (Indeed, the illustrations
in this book were produced by GFtoDVI.) The second auxiliary program to be
discussed below is TEX itself; we shall look at a set of TEX macros designed to
facilitate font testing.
1. Large scale proofs. The gf ¬les produced by plain when it is in proof
mode or smoke mode can be converted to annotated diagrams by running them through

<< . .

. 39
( : 45)

. . >>