<< . .

. 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
your answer in terms of printer™s points.
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,
and you should reply
\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
a creative experience instead of something to dread.
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
badio.mf to
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.
<to be read again>
;
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,
˜S™ is sort of like typing return to every message.
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
put comments into your programs.) The changes that were made
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.
<to be read again>
:
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,
since that increases your productivity while decreasing your computer bills. An
experienced user will quit after an error only if the error is un¬xable,
or if there™s almost no chance that additional errors are present.
The solution in this case is to proceed in two steps: First type ˜1™, which

<< . .

. 6
( : 45)



. . >>