<< Ļšåä. ńņš. ńņš. 6(īįłåå źīėč÷åńņāī: 45)ĪĆĖĄĀĖÅĶČÅ Ńėåä. ńņš. >>
What are the height and width of the bounding box described in the beginchar
command on line 9 of io.mf, given the parameter values deļ¬ned on line 2? Give
Each beginchar operation assigns values to special variables called w,
h, and d, which represent the respective width, height, and depth of the current
characterā™s bounding box, rounded to the nearest integer number of pixels. Our
36 Chapter 5: Running

example ļ¬le uses w and h to help establish the locations of several pen positions endchar
penlabels
(see lines 12, 13, and 21 of io.mf). def
subroutine
EXERCISE 5.2 **
Continuing the previous exercise, what will be the values of w and h if there are mf
ļ¬le names
exactly 3.6 pixels per point?
Thereā™s a quoted phrase "The letter O" at the end of line 9; this is
simply a title that will be used in printouts.
The ā˜endcharā™ on line 16 ļ¬nishes the character that was begun on line 9,
by writing it to an output ļ¬le and possibly displaying it on your screen. We will
want to see the positions of the control points z1 , z2 , z3 , and z4 that are used in its
design, together with the auxiliary points (z1l , z2l , z3l , z4l ) and (z1r , z2r , z3r , z4r )
that come with the penpos conventions; the statement ā˜penlabels(1,2,3,4)ā™
takes care of labeling these points on the proofsheets.
So much for the letter O. Lines 17ā“23 are analogous to what weā™ve seen
before, except that thereā™s a new wrinkle: They contain a little program enclosed
by ā˜def...enddefā™, which means that a subroutine is being deļ¬ned. In other
words, those lines set up a whole bunch of commands that we will
want to execute several times with minor variations. The subroutine is called
test I and it has three parameters called code , trial stem , and trial width (see
line 17). The idea is that weā™ll want to draw several diļ¬erent versions of an
ā˜Iā™, having diļ¬erent stem widths and character widths; but we want to type the
program only once. Line 18 deļ¬nes stem # and stem , given a value of trial stem ;
and lines 19ā“23 complete the program for the letter I (copying it from Chapter 4).
Oopsā”weā™ve been talking much too long about io.mf. Itā™s time to stop
rambling and to begin Experiment 2 in earnest, because it will be much more
fun to see what the computer actually does with that ļ¬le.
Are you brave enough to try Experiment 2? Sure. Get
going again, but this time when the machine says ā˜**ā™ you should say ā˜ioā™, since
thatā™s the name of the ļ¬le you have prepared so laboriously. (The ļ¬le could also
be speciļ¬ed by giving its full name ā˜io.mfā™, but automatically adds
ā˜.mfā™ when no suļ¬x has been given explicitly.)
If all goes well, the computer should now ļ¬‚ash its lights a bit andā”
prestoā”a big ā˜ ā™ should be drawn on your screen. But if your luck is as good
as the authorā™s, something will probably go wrong the ļ¬rst time, most likely
because of a typographic error in the ļ¬le. A program contains lots
of data with comparatively little redundancy, so a single error can make a drastic
change in the meaning. Check that youā™ve typed everything perfectly: Be sure
to notice the diļ¬erence between the letter ā˜lā™ and the numeral ā˜1ā™ (especially in
line 12, where it says ā˜x1lā™, not ā˜x11 or ā˜xllā™); be sure to distinguish between
the letter ā˜Oā™ and the numeral ā˜0ā™ (especially in line 9); be sure to type the
āunderlineā characters in words like ā˜mode_setupā™. Weā™ll see later that -
can recover gracefully from most errors, but your job for now is to make
sure that youā™ve got io.mf correct.
Chapter 5: Running 37

Once you have a working ļ¬le, the computer will draw you an ā˜ ā™ and it ASCII
*
will also say something like this: end
GFtoDVI
(io.mf penpos
The letter O [79]) labels
overļ¬‚ow labels
*
What does this mean? Well, ā˜(io.mfā™ means that it has started to read your
ļ¬le, and ā˜The letter Oā™ was printed when the title was found in line 9. Then
when got to the endchar on line 16, it said ā˜[79]ā™ to tell you that it
had just output character number 79. (This is the ASCII code for the letter O;
Appendix C lists all of these codes, if you need to know them.) The ā˜)ā™ after
ā˜[79]ā™ means that subsequently ļ¬nished reading the ļ¬le, and the ā˜*ā™
means that it wants another instruction.
Hmmm. The ļ¬le contains programs for both I and O; why did we get
only an O? Answer: Because lines 17ā“23 simply deļ¬ne the subroutine test I ; they
donā™t actually do anything with that subroutine. We need to activate test I if
weā™re going to see what it does. So letā™s type
test_I("I",5/6,1/3);
this invokes the subroutine, with code = "I", trial stem = 5 , and trial width =
6
1
. The computer will now draw an I corresponding to these values,* and it will
3
prompt us for another command.
Itā™s time to type ā˜endā™ now, after which should tell us that it
has completed this run and made an output ļ¬le called ā˜io.2602gfā™. Running this
ļ¬le through GFtoDVI as in Experiment 1 will produce two proofsheets, showing
the ā˜ ā™ and the ā˜ ā™ we have created. The output wonā™t be shown here, but you
can see the results by doing the experiment personally.
Look at those proofsheets now, because they provide instructive exam-
ples of the simulated broad-edge pen constructions introduced in Chapter 4.
Compare the ā˜ ā™ with the program that drew it: Notice that the penpos2 in
line 10 makes the curve slightly thicker at the bottom than at the top; that
the equation ā˜x1l = w ā’ x3l = curve sidebar ā™ in line 12 makes the right edge
of the curve as far from the right of the bounding box as the left edge is from
the left; that line 13 places point 1 slightly lower than point 3. The proofsheet
for ā˜ ā™ should look very much like the corresponding illustration near the end of
Chapter 4, but it will be somewhat larger.
Your proof copy of the ā˜ ā™ should show twelve dots for key points; but only
ten of them will be labeled, because there isnā™t room enough to put labels on
points 2 and 4. The missing labels usually appear in the upper right corner, where it
might say, e.g., ā˜4 = 4l + (-1,-5.9)ā™; this means that point z4 is one pixel to the left
and 5.9 pixels down from point z4l , which is labeled. (Some implementations omit this
information, because there isnā™t always room for it.)

* Unless, of course, there was a typing error in lines 17ā“23, where test I is deļ¬ned.
38 Chapter 5: Running

The proofsheets obtained in Experiment 2 show the key points and the **
backslash
bounding boxes, but this extra information can interfere with our perception of smoke
the character shape itself. Thereā™s a simple way to get proofs that allow a viewer magniļ¬cation
to criticize the results from an aesthetic rather than a logical standpoint; the
creation of such proofs will be the goal of our next experiment.
Hereā™s how to do Experiment 3: Start as usual, then type
\mode=smoke; input io
in response to the ā˜**ā™. This will input ļ¬le io.mf again, after establishing
āsmokeā mode. (As in Experiment 1, the command line begins with ā˜\ā™ so
that the computer knows you arenā™t starting with the name of a ļ¬le.) Then
complete the run exactly as in Experiment 2, by typing ā˜test_I("I",5/6,1/3);
endā™; and apply GFtoDVI to the resulting ļ¬le io.2602gf.
This time the proofsheets will contain the same characters as before,
but they will be darker and without labeled points. The bounding boxes will be
indicated only by small markings at the corners; you can put these boxes next
to each other and tack the results up on the wall, then stand back to see how
the characters will look when set by a high-resolution typesetter. (This way of
working is called smoke mode because itā™s analogous to the āsmoke proofsā that
punch-cutters traditionally used to test their handiwork. They held the newly
cut type over a candle ļ¬‚ame so that it would be covered with carbon; then they
pressed it on paper to make a clean impression of the character, in order to see
whether changes were needed.)
Incidentally, many systems allow you to invoke by typing a one-
line command like ā˜mf ioā™ in the case of Experiment 2; you donā™t have to
wait for the ā˜**ā™ before giving a ļ¬le name. Similarly, the one-liners ā˜mf \relaxā™ and
ā˜mf \mode=smoke; input ioā™ can be used on many systems at the beginning of Experi-
ments 1 and 3. You might want to try this, to see if it works on your computer; or you
might ask somebody if thereā™s a similar shortcut.
Experiments 1, 2, and 3 have demonstrated how to make proof drawings
of test characters, but they donā™t actually produce new fonts that can be used
in typesetting. For this, we move onward to Experiment 4, in which we put
ourselves in the position of a person who is just starting to design a new typeface.
Letā™s imagine that weā™re happy with the O of io.mf, and that we want a āsans
serifā I in the general style produced by test I , but we arenā™t sure about how
thick the stem of the I should be in order to make it blend properly with the O.
Moreover, we arenā™t sure how much white space to leave at the sides of the I.
So we want to do some typesetting experiments, using a sequence of diļ¬erent Iā™s.
The ideal way to do this would be to produce a high-resolution test font
and to view the output at its true size. But this may be too expensive, because
ļ¬ne printing equipment is usually available only for large production runs. The
next-best alternative is to use a low-resolution printer but to magnify the output,
so that the resolution is eļ¬ectively increased. We shall adopt the latter strategy,
because it gives us a chance to learn about magniļ¬cation as well as fontmaking.
Chapter 5: Running 39

After starting again, you can begin Experiment 4 by typing plain base
localfont
*
\mode=localfont; mag=4; input io
upto
for
in response to the ā˜**ā™. The plain base at your installation is supposed to recog- endfor
nize localfont as the name of the mode that makes fonts for your āstandardā ASCII
incr
output device. The equation ā˜mag=4ā™ means that this run will produce a font font metric ļ¬le
that is magniļ¬ed fourfold; i.e., the results will be 4 times bigger than usual. output of METAFONT
tfm
The computer will read io.mf as before, but this time it wonā™t display
an ā˜Oā™; characters are normally not displayed in fontmaking modes, because we
usually want the computer to run as fast as possible when itā™s generating a font
that has already been designed. All youā™ll see is ā˜(io.mf [79])ā™, followed by ā˜*ā™.
Now the fun starts: You should type
code=100;
for s=7 upto 10:
for w=5 upto 8:
test_I(incr code,s/10,w/20);
endfor endfor end.
(Here ā˜uptoā™ must be typed as a single word.) Weā™ll learn about repeating things
with ā˜for...endforā™ in Chapter 19. This little program produces 16 versions of
the letter I, with stem widths of 10 , 10 , 10 , and 10 pt, and with character widths
7 8 9
10
5 6 7 8
of 20 , 20 , 20 , and 20 em. The sixteen trial characters will appear in positions
101 through 116 of the font; it turns out that these are the ASCII codes for lower
case letters e through t inclusive. (Other codes would have been used if ā˜codeā™
had been started at a value diļ¬erent from 100. The construction ā˜incr codeā™
increases the value of code by 1 and produces the new value; thus, each use of
test_I has a diļ¬erent code number.)
This run of will not only produce a generic font io.nnngf,
it will also create a ļ¬le called io.tfm, the āfont metric ļ¬leā that tells typesetting
systems like TEX how to make use of the new font. The remaining part of
Experiment 4 will be to put TEX to work: We shall make some test patterns
from the new font, in order to determine which ā˜Iā™ is best.
You may need to ask a local system wizard for help at this point, because
it may be necessary to move the ļ¬le io.tfm to some special place where TEX
and the other typesetting software can ļ¬nd it. Furthermore, youā™ll need to run
a program that converts io.nnngf to the font format used by your local output
device. But with luck, these will both be fairly simple operations, and a new
font called ā˜ioā™ will eļ¬ectively be installed on your system. This font will contain
seventeen letters, namely an O and sixteen Iā™s, where the Iā™s happen to be in
the positions normally occupied by e, f, . . . , t. Furthermore, the font will be
magniļ¬ed fourfold.
The magniļ¬cation of the font will be reļ¬‚ected in its ļ¬le name. For example,
if localfont mode is for a device with 200 pixels per inch, the io font at 4Ć—
magniļ¬cation will be called ā˜io.800gfā™.
40 Chapter 5: Running

You can use TEX to typeset from this font like any other, but for the testfont
mixture
purposes of Experiment 4 itā™s best to use a special TEX package that has been backslash
speciļ¬cally designed for font testing. All you need to do is to run TEXā”which background letter
dvi
is just like running , except that you call it ā˜texā™ instead of ā˜mfā™; Isis
and you simply type ā˜testfontā™ in reply to TEXā™s ā˜**ā™. (The testfont routine
should be available on your system; if not, you or somebody else can type it in,
by copying the relevant material from Appendix H.) You will then be asked for
the name of the font you wish to test. Type
io scaled 4000
(which means the io font magniļ¬ed by 4, in TEXā™s jargon), since this is what
just created. The machine will now ask you for a test command,
\mixture
to get the āmixtureā test. (Donā™t forget the backslash.) Youā™ll be asked for a
background letter, a starting letter, and an ending letter; type ā˜Oā™, ā˜eā™, and ā˜tā™,
respectively. This will produce sixteen lines of typeset output, in which the ļ¬rst
line contains a mixture of O with e, the second contains a mixture of O with f,
and so on. To complete Experiment 4, type ā˜\endā™ to TEX, and print the ļ¬le
testfont.dvi that TEX gives you.
If all goes well, youā™ll have sixteen lines that say ā˜OIOOI IOOOII IOIā™,
but with a diļ¬erent I on each line. In order to choose the line that looks best,
without being inļ¬‚uenced by neighboring lines, itā™s convenient to take two sheets
of blank paper and use them to mask out all of the lines except the one youā™re
studying. Caution: These letters are four times larger than the size at which
the ļ¬nal font is meant to be viewed, so you should look at the samples from
afar. Xerographic reductions may introduce distortions that will give misleading
results. Sometimes when you stare at things like this too closely, they all look
wrong, or they all look right; ļ¬rst impressions are usually more signiļ¬cant than
the results of logical reļ¬‚ection. At any rate, you should be able to come up
with an informed judgment about what values to use for the stem width and the
character width of a decent ā˜Iā™; these can then be incorporated into the program,
the ā˜defā™ and ā˜enddefā™ parts of io.mf can be removed, and you can go on to
design other characters that go with your I and O. Furthermore you can always
go back and make editorial changes after you see your letters in more contexts.
EXERCISE 5.3
The goddess Io was known in Egypt as Isis. Design an ā˜ ā™ for her.

Well, this isnā™t a book about type design; the example of io.mf is simply
intended to illustrate how a type designer might want to operate, and to provide a
run-through of the complete process from design of type to its use in a document.
We must go back now to the world of computerese, and study a few more practical
details about the use of .
Chapter 5: Running 41

This has been a long chapter, but take heart: Thereā™s only one more ĀæĀæ
experiment to do, and then you will know enough about to run it
fearlessly by yourself forever after. The only thing you are still missing is some
information about how to cope with error messages. Sometimes
stops and asks you what to do next. Indeed, this may have already happened,
and you may have panicked.
Error messages can be terrifying when you arenā™t prepared for them;
but they can be fun when you have the right attitude. Just remember that
you really havenā™t hurt the computerā™s feelings, and that nobody will hold the
errors against you. Then youā™ll ļ¬nd that running might actually be
The ļ¬rst step in Experiment 5 is to plant some intentional mistakes in
the input ļ¬le. Make a copy of io.mf and call it badio.mf; then change line 1 of
mode setup; % an intentional error!
(thereby omitting the underline character in mode_setup). Also change the ļ¬rst
semicolon ( ā˜;ā™ ) on line 2 to a colon ( ā˜:ā™ ); change ā˜thick,10ā™ to ā˜thick,l0ā™ on
line 10 (i.e., replace the numeral ā˜1ā™ by the letter ā˜lā™ ); and change ā˜thinā™ to
ā˜thinnā™ on line 11. These four changes introduce typical typographic errors, and
it will be instructive to see if they lead to any disastrous consequences.
Now start up again; but instead of cooperating with the
computer, type ā˜mumbleā™ in reply to the ā˜**ā™. (As long as youā™re going to make
intentional mistakes, you might as well make some dillies.) will say
that it canā™t ļ¬nd any ļ¬le called mumble.mf, and it will ask you for another name.
Just hit return this time; youā™ll see that you had better give the name of a real
ļ¬le. So type ā˜badioā™ and wait for to ļ¬nd one of the faux pas in that
messed-up travesty.
Ah yes, the machine will soon stop, after typing something like this:
>> mode.setup
! Isolated expression.
;
l.1 mode setup;
% an intentional error!
?
begins its error messages with ā˜!ā™, and it sometimes precedes them
with one or two related mathematical expressions that are displayed on lines
starting with ā˜>>ā™. Each error message is also followed by lines of context that
show what the computer was reading at the time of the error. Such context lines
occur in pairs; the top line of the pair (e.g., ā˜mode setup;ā™ ) shows what -
has looked at so far, and where it came from (ā˜l.1ā™, i.e., line number 1);
the bottom line (here ā˜% an intentional error!ā™ ) shows what has
42 Chapter 5: Running

yet to read. In this case there are two pairs of context lines; the top pair refers transcript
log ļ¬le
to a semicolon that has read once but will be reading again, because ?
it didnā™t belong with the preceding material. inserting text online
online interaction, see interaction
You donā™t have to take out pencil and paper in order to write down the interacting with MF
error messages that you get before they disappear from view, since tokens
deleting tokens
always writes a ātranscriptā or ālog ļ¬leā that records what happened during
each session. For example, you should now have a ļ¬le called io.log containing
the transcript of Experiment 4, as well as a ļ¬le mfput.log that contains the
transcript of Experiment 1. (The old transcript of Experiment 2 was probably
overwritten when you did Experiment 3, and again when you did Experiment 4,
because all three transcripts were called io.log.) At the end of Experiment 5
youā™ll have a ļ¬le badio.log that will serve as a helpful reminder of what errors
need to be ļ¬xed up.
The ā˜?ā™ that appears after the context display means that
wants advice about what to do next. If youā™ve never seen an error message
before, or if youā™ve forgotten what sort of response is expected, you can type ā˜?ā™
now (go ahead and try it!); will respond as follows:
Type <return> to proceed, S to scroll future error messages,
R to run without stopping, Q to run quietly,
I to insert something, E to edit your file,
1 or ... or 9 to ignore the next 1 to 9 tokens of input,
H for help, X to quit.
This is your menu of options. You may choose to continue in various ways:
1. Simply type return . will resume its processing, after at-
tempting to recover from the error as best it can.
2. Type ā˜Sā™. will proceed without pausing for instructions if
further errors arise. Subsequent error messages will ļ¬‚ash by on your
terminal, possibly faster than you can read them, and they will appear
in your log ļ¬le where you can scrutinize them at your leisure. Thus,
3. Type ā˜Rā™. This is like ā˜Sā™ but even stronger, since it tells not
to stop for any reason, not even if a ļ¬le name canā™t be found.
4. Type ā˜Qā™. This is like ā˜Rā™ but even more so, since it tells not
only to proceed without stopping but also to suppress all further output
to your terminal. It is a fast, but somewhat reckless, way to proceed
(intended for running with no operator in attendance).
5. Type ā˜Iā™, followed by some text that you want to insert.
will read this text before encountering what it would ordinarily see next.
6. Type a small number (less than 100). will delete this many
tokens from whatever it is about to read next, and it will pause again
to give you another chance to look things over. (A ātokenā is a name,
number, or symbol that reads as a unit; e.g., ā˜modeā™ and
Chapter 5: Running 43

ā˜setupā™ and ā˜;ā™ are the ļ¬rst three tokens of badio.mf, but ā˜mode_setupā™ help messages
space
is the ļ¬rst token of io.mf. Chapter 6 explains this concept precisely.) period
percent
7. Type ā˜Hā™. This is what you should do now and whenever you are faced comments
with an error message that you havenā™t seen for a while.
has two messages built in for each perceived error: a formal one and
an informal one. The formal message is printed ļ¬rst (e.g., ā˜! Isolated
expression.ā™ ); the informal one is printed if you request more help
by typing ā˜Hā™, and it also appears in your log ļ¬le if you are scrolling
error messages. The informal message tries to complement the formal
one by explaining what thinks the trouble is, and often by
suggesting a strategy for recouping your losses.
8. Type ā˜Xā™. This stands for āexit.ā It causes to stop working
on your job, after putting the ļ¬nishing touches on your log ļ¬le and on
any characters that have already been output to your gf and/or tfm
ļ¬les. The current (incomplete) character will not be output.
9. Type ā˜Eā™. This is like ā˜Xā™, but it also prepares the computer to edit the
ļ¬le that is currently reading, at the current position, so that
you can conveniently make a change before trying again.
After you type ā˜Hā™ (or ā˜hā™, which also works), youā™ll get a message that tries to
explain the current problem: The mathematical quantity just read by -
(i.e., mode.setup) was not followed by ā˜=ā™ or ā˜:=ā™, so there was nothing for
the computer to do with it. Chapter 6 explains that a space between tokens (e.g.,
ā˜mode setupā™ ) is equivalent to a period between tokens (e.g., ā˜mode.setupā™ ). The
correct spelling ā˜mode_setupā™ would be recognized as a preloaded subroutine of
plain , but plain doesnā™t have any built-in meaning for
mode.setup. Hence mode.setup appears as a sort of orphan, and
realizes that something is amiss.
In this case, itā™s OK to go ahead and type return , because we really
donā™t need to do the operations of mode setup when no special mode has been
selected. will continue by forgetting the isolated expression, and it
will ignore the rest of line 1 because everything after a ā˜%ā™ sign is always ignored.
(This is another thing that will be explained in Chapter 6; itā™s a handy way to
to line 1 of badio.mf therefore have turned out to be relatively harmless. But
will almost immediately encounter the mutilated semicolon in line 2:
! Extra tokens will be flushed.
:
l.2 em#:=10pt#:
cap#:=7pt#;
?
What does this mean? Type ā˜Hā™ to ļ¬nd out. has no idea what to do
44 Chapter 5: Running

with a ā˜:ā™ at this place in the ļ¬le, so it plans to recover by āļ¬‚ushingā or getting ļ¬‚ushing
...
rid of everything it sees, until coming to a semicolon. It would be a bad idea to EXPR
type return now, since youā™d lose the important assignment ā˜cap#:=7pt#ā™, and SUFFIX
rotation
that would lead to worse errors. transformations
You might type ā˜Xā™ or ā˜Eā™ at this point, to exit from and to
ļ¬x the errors in lines 1 and 2 before trying again. But itā™s usually best to keep
going, trying to detect and correct as many mistakes as possible in each run,