summaryrefslogtreecommitdiff
path: root/usergrps/uktug/baskervi/3_1/mfbeg.tex
blob: 4fba53351b065c339b3b56144f0b26eabf2da71e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
\bgroup
\arraycolsep3pt
% A way to get a hyphen, courtesy of Karl Berry.
\newcommand{\MFbook}{{\em The \MF book\/}}
\newcommand{\TeXbook}{{\em The \TeX{}book\/}}
\newcommand{\ttbsl}{{\tt \char`\\\/}}  % typewriter type backslash.

% gt:  employing usual title font for "METAFONT" here.
\title{\MF\ for Beginners}
\author[Geoffrey Tobin]{Geoffrey Tobin\\{\tt ecsgrt@luxor.latrobe.edu.au}}
\begin{article}
\section*{Scope}%

This is not a tutorial on \MF{}.\footnote{This article is a
trimmed version of the tutorial file made available on
\TeX\ archives; a current full version can be obtained
from the {\em documentation} directory on any CTAN archive (see
elsewhere in this issue of \BV\ for more details of CTAN).} It is an
attempt to describe how some of the pitfalls in running the
program may, hopefully, be avoided.

It is a common experience to have initial (and medial and final)
difficulty with running \MF{}, and not all `\TeX{}nicians'
are as familiar with \MF{} as they are with \TeX{}.  Still, nothing
ventured, nothing gained.  So let's be of good cheer, and get down to
work.


\section{What is \MF{}?}

\MF{} is a program for making bitmap fonts for use by \TeX{}, its
viewers, printer drivers, and related programs.  It interprets a
drawing language with a syntax apparently derived in part from the
Algol family of programming languages, of which C, C++, Pascal and
Modula-2 are members.

The input can be interactive, or from a source file.
\MF{} source files are usually suffixed `{\tt .mf}'.

\MF{} sources can utilize scaling, rotation, reflection, skewing and shifting,
and other complex transformations in obvious and intuitive ways.
But that is another story, told (in part) by \MFbook{}.

\MF{}'s bitmap output is a {\sc gf} ({\em generic font\/}) file.
This may be compressed to an equivalent {\sc pk} ({\em packed\/}) font
by the auxiliary program {\em GFtoPK}.

Why doesn't \MF{} output {\sc pk} fonts directly?  Firstly, Tomas
{\sc Rokicki} had not invented {\sc pk} at the time Donald
Knuth was writing \MF{}.  Secondly, to change \MF{} now
would be too big a change in Knuth's opinion.  (Knuth
is a very conservative programmer; this fact is a two-sided coin.)

{\sc gf} and {\sc pk} files are suffixed `{\tt .*gf}' and `{\tt .*pk}'
respectively, where, in a typical {\sc unix} installation, the
`{\tt *}' stands for the font resolution.
(Resolution will be explained below.)
{\sc ms-dos} truncates file name suffixes to three characters, so a
font suffix `{\tt .1200gf}' becomes `{\tt .120}' --- beware of this!

A bitmap is all that's needed for large-scale {\em proofs},
as produced by the {\em GFtoDVI} utility,
but for \TeX{} to typeset a font it needs a {\sc tfm}
({\em \TeX{} Font Metric\/}) file to describe the dimensions, ligatures
and kerns of the font.  \MF{} can be told to make a {\sc tfm} file,
by making the internal variable `{\tt fontmaking}' positive.  Most
output device modes (see below) do this.

Remember that \TeX{} reads only the {\sc tfm} files.
The {\em glyphs}, or forms of the characters, as stored in {\sc gf}
or {\sc pk} font files, do not enter the picture
(I mean, are not read)
until the {\sc dvi} drivers are run.

\TeX{} can scale {\sc tfm} files.  Unfortunately, bitmaps such as {\sc
gf} and {\sc pk} are not scalable.  However, \MF{} files can be
compiled into fonts of arbitrary scale by \MF{}, even by
non-programmers.

Incidentally, properly constructed {\sc tfm} files are
device-independent, so running \MF{} with different modes normally
produces the identical {\sc tfm}.
Dimensions in {\sc tfm} files are specified to \MF{} in device
independent `sharped' dimensions (commonly suffixed by \#), where
a value of 1 corresponds to the dimension of {\tt 1pt} (typographical
point).  Most of \MF{}'s calculations are done with (resolution and
device dependent) pixels as units.  Care must be taken by font
designers to {\em always\/} calculate unsharped dimensions from sharped
ones, and never the other way round, so as to keep roundoff errors or
similar effects from influencing the {\sc tfm} files to depend on
resolution or device.  Although type quality will be influenced only in
minuscule ways, this is one of the more common reasons for checksum
errors reported by printer drivers.
Note that the only way to be sure that a {\sc tfm} file is device-independent
is to create the font in different modes and compare the resulting
{\sc tfm}'s, perhaps using {\em tftopl}.

More detailed descriptions of {\sc tfm} and {\sc gf} files, and of
{\em proof\/} mode, are found in Appendices F, G, and H, respectively
of \MFbook{}.


\section{Getting \MF{}'s Attention}\label{sec:typing}


\subsection{Typing at \MF{}'s `{\tt **}' prompt}\label{sub:starstar}

If you type the name of the \MF{} program alone on the command line:
\begin{verbatim}
    mf
\end{verbatim}
then {\tt mf} displays a `{\tt **}' prompt,
which
`is \MF{}'s way of asking you for an input file name'.
(See \MFbook{}, Chapter 5: `Running \MF{}'.)
Thus, to process a \MF{} file named {\tt fred.mf}, you may type:
\begin{verbatim}
    fred
\end{verbatim}

A backslash (`\ttbsl') can also be typed here.
This causes all subsequent commands at the prompt line to be
interpreted as in a \MF{} file.
(Concerning the backslash, see \MFbook{}, Chapter 20:
`More About Macros', pages 179 and 180 in the 1986 edition.)
Thus we can respond to the {\tt **} prompt with:
\begin{verbatim}
    \ input fred
\end{verbatim}
or even:
\begin{verbatim}
    \ ; input fred
\end{verbatim}

The backslash is useful because
certain commands are often executed before a \MF{} file is input.
In particular, quality printing
requires the \MF{} command {\tt mode},
and output magnification
employs the {\tt mag} command.
For example:
\begin{verbatim}
    \mode=localfont; mag=magstep(1); input fred
\end{verbatim}

To read {\sc ms-dos} pathnames at the {\tt **} prompt,
this satisfies \MF{}:
\begin{verbatim}
   \ input \seldom\fred.mf
\end{verbatim}
as does:
\begin{verbatim}
    d:\seldom\fred.mf
\end{verbatim}


\subsection{Typing on the Command Line}\label{sub:cmdline}

Most \MF{} implementations permit you to type \MF{} commands on the
command line, instead of at the {\tt **} prompt.  (Rather, it is
automatically passed to that prompt.)

On {\sc ms-dos}, type commands as at the {\tt **} prompt:
\begin{verbatim}
    mf \mode=localfont; input myfont10
\end{verbatim}

On {\sc unix}, command shells typically interpret semicolons,
backslashes and parentheses specially, unless they are `quoted'.
So, when typing those characters as part of instructions to \MF{}
on the {\sc unix} command line, it is wise to accustom
yourself to protecting them with {\em apostrophes\/}:
\begin{verbatim}
    mf '\mode=localfont; input myfont10'
\end{verbatim}
If {\tt localfont} makes fonts for a 300 dots per inch (dpi) device,
this should produce a {\sc tfm} file, `{\tt myfont10.tfm}',
and a 300 dpi {\sc gf} font file, `{\tt myfont10.300gf}'.
Almost all of the following will presume a 300 dpi device, and other
resolution devices will have appropriately different font file names.

These command lines are a bit long, very often used, and rather
intolerant of mistakes so you might type the repetitive parts into a
{\sc unix} shell script or an {\sc ms-dos} batch file, as appropriate.

In {\sc unix}, the {\tt **} prompt has the advantage that those pesky
apostrophes are not needed.  (Indeed, those apostrophes are always
wrong at the {\tt **} prompt --- \MF{} doesn't understand them.
It would not understand them on the command line either---it is just
that the shell does not hand them over to \MF{}.)
However, for shell scripts (and for batch files in {\sc ms-dos}),
the command line is a boon.


\subsection{`{\tt Please type another input file name: }'}%
\label{sub:another}

When \MF{} cannot find the main source file, it doesn't quit.
For example, when I typed {\tt mf fred}, \MF{} said:
\begin{verbatim}
    This is METAFONT ...
    **fred
    ! I can't find file `fred.mf'.
    <*> fred

    Please type another input file name:
\end{verbatim}
The usual program interrupts (eg, Control-C) don't work here,
and the `{\tt Please type ...}' prompt does not understand
\MF{} commands:  it will read only the first word, and insist on
interpreting this as a file name.

Beginners faced with this often wonder how to avoid an endless loop
or a reboot, or try to think of a \MF{} file that they do have
in \MF{}'s path.  In the latter case, the canonical name to use
is `{\tt null}', standing for the file `{\tt null.mf}'.

In fact, the solution is much easier:  on the
systems that I have tried, a simple end of file marker
(`control-Z' in {\sc ms-dos}, `control-D' in {\sc unix})
stops \MF{} in its tracks:
\begin{verbatim}
    ! Emergency stop.
    <*> fred

    End of file on the terminal!
\end{verbatim}


\section{Base files}\label{sec:base}

In versions 2.7 and 2.71, the \MF{} language contains 224
(previous versions had fewer) primitives,
which are the commands preceded by an asterisk in the Index (Appendix I)
to \MFbook{}.  From these we can build more complex operations,
using macros.  In \MF{} macros have some of the desirable
characteristics of functions in other languages.  Collections of
macros can be stored in \MF{} source files.

{\em Base\/} files are {\em precompiled internal tables\/} that \MF{}
loads faster than it loads the original \MF{} source files.
Thus, they are closely analogous to \TeX{}'s {\em format\/} files.


\subsection{The {\tt plain} base}\label{sub:plain}

The {\tt plain} base provides the commands that \MFbook{}
describes.  (See Appendix B of \MFbook{}, if you have it around
--- maybe a library has it --- I'm learning from a copy borrowed from the
local university's library.)

When it starts, \MF{} automatically loads\footnote {There are releases
  of \MF{} that contain the {\tt plain} base, and so don't have to
  load it.  However, on most computers, including personal computers,
  reading bases is so fast that such a {\em preloaded\/} base is
  unnecessary.} the {\tt plain} base.  This is usually called {\tt
  plain.base}, or sometimes only {\tt mf.base}, although for those
systems concerned (such as {\sc unix}), both file names should really
be present.

Em\TeX{} for {\sc ms-dos} calls the plain base {\tt plain.bas},
due to filename truncation.


\subsection{Loading a Different Base}\label{sub:loading}

Suppose that you have a base named {\tt joe.base}.
Typing
\begin{verbatim}
    mf &joe
\end{verbatim}
or (on unix, where we must either quote or escape the ampersand)
\begin{verbatim}
    mf \&joe
\end{verbatim}
or responding
\begin{verbatim}
    &joe
\end{verbatim}
to the {\tt **} prompt,
omits loading {\tt plain} base, and loads the {\tt joe} base instead.
Typically, however, the {\tt joe.mf} file which originally produced
the {\tt joe} base will have included {\tt plain.mf}, because working
without the {\tt plain} base macros would be too cumbersome.
(Refer to \MFbook{} (1986), Chapter 5: `Running \MF{}', page 35,
`dangerous bend' number two.)

The `{\tt cm}' base, for making the Computer Modern fonts,
can be loaded in that way:
\begin{verbatim}
    mf &cm
\end{verbatim}
Remember to quote the ampersand under {\sc unix}!


\subsection{The Linkage Trick}\label{sub:link}

On systems such as {\sc unix} where programs can read their own
command line name, and where files may be linked to two or more
names, then programs can modify their behavior according to the
name by which they are called.  Many {\sc unix} \TeX{} and \MF{}
installations exploit this in order to load different {\em format\/}
and {\em base\/} files, one for each of the various names to which
\TeX{} and \MF{} are linked.  Such installations can often
be recognized by the presence of the executable `{\tt virmf}'
in one of the directories in the {\tt PATH}.

For example, if a base file called `{\tt third.base}' resides where
\MF{} can find it, then {\tt virmf} can be linked to {\tt third}.  In
{\sc unix}, a {\em hard link\/} is formed by
\begin{verbatim}
    ln virmf third
\end{verbatim}

On systems supporting {\em symbolic links\/}, you should make all of
these links symbolic, rather than hard, or else you will have to redo
them every time you install a new copy of~{\tt virmf}; see below.
In {\sc unix}, this is done by
\begin{verbatim}
    ln -s virmf third
\end{verbatim}

Normally one wants {\tt mf} to load the {\tt plain} base,
so in such installations one links {\tt plain.base} to {\tt mf.base}:
\begin{verbatim}
    ln plain.base mf.base
\end{verbatim}
Again, you'd best make that link symbolic.  This comment applies for
the rest of this section as well.

As another example, take the `{\tt cm}' base.  In {\em web2c}:
\begin{verbatim}
    ln virmf cmmf
    ln cm.base cmmf.base
\end{verbatim}
so that `{\tt cmmf}' automatically loads `{\tt cm.base}'.

This applies equally to \TeX{}, which is why {\tt tex} and {\tt latex}
are then links to {\tt virtex}, {\tt tex.fmt} is a link to
{\tt plain.fmt}, and {\tt latex.fmt} is a link to {lplain.fmt}:
\begin{verbatim}
    ln virtex tex
    ln plain.fmt tex.fmt

    ln virtex latex
    ln lplain.fmt latex.fmt
\end{verbatim}

Karl Berry's {\em web2c} distribution for {\sc unix} uses
this `{\em linkage trick\/}'.

If you used symbolic links, you can laugh off the following

{\sc Warning:}
This linkage is convenient, but watch out during updates!
If {\tt mf.base} is a {\em hard link\/}
to {\tt plain.base}, then replacing {\tt plain.base} with its
new version severs the link:  {\tt mf} will still load {\tt mf.base},
but it will be the old version!  The proper procedure is to remove
the old {\tt mf.base}, and relink.  On {\sc unix}:
\begin{verbatim}
    rm mf.base
    ln plain.base mf.base
\end{verbatim}
On most {\sc unix\/} systems, {\tt ln -f} will automatically remove
the second file (if present) --- in this case, mf.base --- before linking.

Alternatively, {\em web2c} will update `{\tt plain.base}'
(and `{\tt plain.fmt}', and so on) for you,
if you tell {\em web2c\/}'s {\tt Makefile}  to
\begin{verbatim}
    make install
\end{verbatim}
Symbolic links, on systems that have them, are probably the best
method of handling updates, at least when doing them manually.
(Consult your system administrator for details.)


\subsection{Making a Base; the Local Modes file}\label{sub:modes}

The {\tt plain} base is made from a \MF{} file named
{\tt plain.mf} and, commonly, from some other file, often called
{\tt local.mf} or {\tt modes.mf}.

The {\tt local}/{\tt modes} file lists printers (and monitors), giving
each output device a font-making {\em mode\/}, containing a
description of some refinements that must be made in order to produce
good-looking output.  For instance, how to make the characters just
dark enough, and how to make diagonal lines come out sharply.

If you want to make a base, you need a variant of the \MF{} program
called `{\tt inimf}'.  (See \MFbook{}, p 279.)  For example,
{\tt plain.base} can be made in {\sc unix} by typing:
\begin{verbatim}
    inimf 'plain; input local; dump'
\end{verbatim}
If using the em\TeX{} version of \MF{} for a {\sc pc}, type:
\begin{verbatim}
    mf/i plain; input local; dump
\end{verbatim}


\section{Fonts}\label{sec:fonts}


\subsection{Proof Mode}\label{sub:proof}

The purpose of \MF{} is to make fonts.  For \ae{}sthetically pleasing
{\sc pk} bitmaps, the correct device mode must be selected.

An obstacle to beware of is that {\tt plain} \MF{} uses
{\em proof\/} mode by default.
(\MFbook{}, page 270, defines this mode.)
That means writing unmagnified font files with a resolution of
2601.72 dots per inch (dpi); that's 36 pixels per point.  (One
point is 1/72.27 of an inch.)  Proof mode does {\bf not} produce a
{\sc tfm} file.

What good is proof mode, and why is it the default?
{\em Proofs\/} are blown up copies of characters used by font
designers to judge whether they like the results of their work.
Naturally, proofs come first, and normal sized character production
later --- if you're a font designer.

So there are two clues that proof mode is on:  font files with
extensions like `{\tt .2602gf}' (or on {\sc ms-dos}, `{\tt .260}'),
and the `failure' to produce any {\sc tfm} file.

On some systems, such as {\sc X11}, a third clue is that the proof
font may be drawn on the screen --- it is so large, you can't miss it!


\subsection{Localfont Mode}\label{sub:localfont}

When using a stable font, or when testing the output of a new font,
we {\em don't\/} want proof mode,
we want our local output device's mode.
Usually, \MF{} is installed with a `{\tt localfont}'
assigned in the {\tt local}/{\tt modes} file.
On our department's Sun Network, we have assigned
\begin{verbatim}
    localfont:=CanonCX
\end{verbatim}
We use Karl  Berry's `{\tt modes.mf}'\footnote
{Available at {\tt ftp.cs.umb.edu} in the {\tt pub/tex} directory.},
which contains modes for many, many devices.  We chose the
{\tt CanonCX} mode because `{\tt modes.mf}' recommends it for Apple
Laserwriters and HP Laserjet~II printers, which we use.

To process a \MF{} source file named `{\tt myfont10.mf}' for the most
usual local device, specify the local mode to {\tt mf} before
inputting the font name:
\begin{verbatim}
    \mode=localfont; input myfont10
\end{verbatim}
This should produce a {\sc gf} font file, `{\tt myfont10.300gf}'
(`{\tt myfont10.300}' in {\sc ms-dos}),
and a {\sc tfm} file, `{\tt myfont10.tfm}'.


\subsection{Font Naming}\label{sub:naming}

By the way, if you modify an existing, say a  Computer
Modern (cm), font, you must give it a new name.  This is an honest
practice, and will avoid confusion.


\subsection{Magnification (and Resolution)}\label{sub:mag}

Now suppose that you want {\tt myfont10} to be magnified,
say to magstep 1 (magnified by 1.2), for a `jumbo' printer.
Assuming that the {\tt local}/{\tt modes} file has a mode
for the jumbo printer,
you may then run \MF{} with the following three commands:
\begin{verbatim}
    \mode=jumbo; mag=magstep(1); input myfont10
\end{verbatim}
to produce `{\tt myfile10.tfm}' (again!)
and a {\sc gf} font, `{\tt myfile10.360gf}'.
On {\sc ms-dos}, the file names will be truncated;
for example, `{\tt myfile10.360}'.

The `{\tt 360}' is `300 {\tt *} 1.2', indicating the magnification.
A 360 dpi font can be used either as a magnification 1.2 font on
a 300 dpi printer or as a normal sized font on a 360 dpi printer.

Note, however, that the \MF{} language includes special hints for
each output device which clue \MF{} as to the reactions of the
output device to pixel-sized minuscule changes.

So for highest quality, you would not even want to mix the fonts for
two 300~dpi printers, unless they share the same mode and most probably
the same print engine.


\subsection{{\em GFtoPK}}\label{sub:gftopk}

\TeX{} uses only the {\sc tfm} file, which \MF{}
will produce if it is in a font-making mode.
(\MFbook{}, Appendix F.)
Most {\sc dvi} drivers read the {\sc pk} font format,
but \MF{} makes a {\sc gf} (Generic Font) file.
So we need also to apply the {\em GFtoPK} utility:
\begin{verbatim}
    gftopk myfile10.300gf
\end{verbatim}
to produce the wanted `{\tt myfile.300pk}'
(or, on {\sc ms-dos}, `{\tt myfile.pk}')
{\sc pk} font.


\subsection{Storing the Fonts}\label{sub:store}

Now we have the fonts, where do we store them?  \TeX{}, \MF{} and
the various driver programs are compiled with default locations
written in.
These can be overridden by certain environment variables.
The names of these variables differ between systems,
but on {\sc unix} they might, for example, be `TEXFONTS' for the
{\sc tfm} files, and either `PKFONTS' or `TEXPKS' (or both of those)
--- before searching `TEXFONTS' --- for {\sc pk} fonts.
You can find out what environment variables you now have
by typing `{\tt set}' in {\sc ms-dos} and `{\tt env}' in the Bourne shell, sh,
in {\sc unix}.  In the {\sc unix} C shell, {\tt csh}, type
`{\tt setenv}'.


If you want \TeX{} and \MF{} to find files in the current directory
(as you almost certainly do!), then one way is to put `{\tt .}' into
their search paths.
(Both {\sc unix} and {\sc ms-dos} accept the {\tt .} notation
for the current directory.)
Default search paths are compiled into \TeX{} and \MF{}, but users
can customise the environment variables 
that the programs read, to override the defaults.

\MF{} as well as the {\sc dvi} drivers, can also be given full path
specifications for input files.

On the other hand, you may be content with your new font, and you may
have write access to the place where most of the fonts are stored.  In
that case, copy your font to there.  There will be a place for the
{\sc tfm} files, and another for the {\sc pk} files.  It is up to you
or your local system administrator(s) to know where these directories
are, because their names are very locale dependent.


\section{Some Limitations of \MF{}}\label{sec:limit}

\MF{} contains some builtin limitations, some obvious, others
less so.

Parts of the following list are most useful to budding programmers,
though casual users may wish to read it to learn whether
an error message produced by somebody else's \MF{} file is very
serious or not.

\begin{enumerate}
\item
All valid numbers are strictly less than 4096.

\item
\MFbook{}, in `Appendix F: Font Metric Information',
warns of one limitation that I've met when processing some fonts.

`At most 15 different nonzero heights, 15 different nonzero depths,
and 63 different nonzero italic corrections\footnote{Respectively,
{\tt charht}, {\tt chardp} and {\tt charic} values.}
may appear in a single font.  if these limits are exceeded,
\MF{} will change one or more values, by as little as possible,
until the restriction holds.  A warning message is issued if such
changes are necessary; for example

{\small\tt (some charht values had to be adjusted by as much as 0.12pt)}

means that you had too many different nonzero heights, but \MF{}
found a way to reduce the number to at most 15 by changing some of them;
none of them had to be changed by more than 0.12 points.
No warning is actually given unless the maximum amount of perturbation
exceeds $\frac{1}{16}$ pt.'

Every correct implementation of \MF{} will adjust character box
dimensions by the same amount, giving the same {\sc tfm} files, so we
ignore small perturbations in other people's fonts.  When designing
your own fonts, however, I think it is courteous to keep within the
limits, so as not to worry inexperienced users.

\item
In the {\tt addto} picture command, {\tt withweight} only accepts
values that round to {\tt -3}, {\tt -2}, {\tt -1}, {\tt +1}, {\tt +2},
or {\tt +3}.  To obtain other pixel weights, you can apply further
{\tt addto} commands.

\item
The memory size of the version of \MF{} you use is an evident,
implementation dependent restriction, but it may be, as in \TeX{},
that memory is not enough simply because, if you'll pardon my saying
so, some of your coding may be seriously inefficient or logically
invalid.
\end{enumerate}

\section{What Went Wrong?}

The complexity of wrong things far exceeds that of things intended.
\MFbook{}, chapter 5, `Running \MF{}', contains
instructive examples, and supposedly `dangerous', but actually basic
and useful, notes.

In that chapter, and in chapter 27, `Recovery from Errors', Knuth
discusses the diagnosis of \MF{}'s error messages.  I find this
perhaps the hardest part of the book --- if not of using \MF{}.

Incidentally, \MF{}'s error messages are contained in an ASCII
file called `{\tt mf.pool}'.  Reading the {\tt pool} file can be
entertaining.


\subsection{Big fonts, but Unwanted}\label{sec:proof}

Recently, I found myself accidentally producing fonts with extensions
like `{\tt 3122gf}'.  How?

{\em \MF{} will take\/ {\bf anything} as an excuse to revert
to\/ {\bf proof mode}.}

The `{\tt 3122}' is a magstep 1 proof mode.  It is
\begin{verbatim}
    (1.2)^1 * 2601.72  = 3122.164  dots per inch.
\end{verbatim}

My intention was for \MF{} on a PC to use an HP Laserjet mode in
place of proof mode.  However, \MF{}'s command line resembles
the law:  {\em every stroke of the pen is significant}.  What I had
forgotten was that on my setup, `{\tt localfont}' must be explicitly
requested.

Em\TeX{}'s \MF{}, with {\tt plain.mf}, defaults to proof mode.
However, I usually want a local printer's font-making mode.
So to process {\tt pics.mf} correctly, I need to say:
\begin{verbatim}
    mf '\mode=localfont; input pics'
\end{verbatim}


\subsection{Consequences of Some Typing Errors on \MF{}'s
  command line}\label{sub:typo}

Small typing errors are so common, and yet undocumented (why are
common mistakes not documented?), that I thought I'd list several that
have tripped me up on innumerable occasions.  After all, why reinvent
the car crash?

Consider a source file `{\tt pics.mf}' that contains `{\tt mag=1200/1000;}',
so it is automatically scaled by 1.2 (ie, by magstep 1).  If the target
printer has 300 dpi, then a 360 dpi {\sc gf} font is wanted.

Here is the gist of what happens for various typing errors, when using
em\TeX{}'s `{\tt mf186}' on a 286 {\sc pc} to process `{\tt pics.mf}'.

\begin{enumerate}
\item
\verb+mf186+  $\Longrightarrow$  \MF{} will keep prompting for arguments:
\begin{verbatim}
    **
\end{verbatim}

We can type the contents of the command line here; for example, I can
now type `{\tt pics}'.  In fact, even if you use the command line,
the {\tt .log} (`transcript') file shows \MF{} echoing its
interpretation of the command line to a  **  prompt.

\item  \verb+mf186 pics+  $\Longrightarrow$  proof mode:

\begin{verbatim}
    ! Value is too large (5184)
\end{verbatim}

No {\sc tfm} is produced, and the {\sc gf} file has resolution 3122 dpi.
(3121.72 dpi, to be precise.)

\item  \verb+mf186 mode=localfont; input pics+  $\Longrightarrow$  misinterpretation:
\begin{verbatim}
    ! I can't find file `modes=localfont.mf'.
\end{verbatim}

So, `{\tt modes}' needs that backslash, otherwise \MF\ thinks it is
the start of a source font's filename.  Backslash (`$\backslash$') and
ampersand (`\&') are escapes from this standard interpretation by
\MF{} of the first argument.  (Ampersand is in fact only a temporary
escape, as \MF{} resumes the {\tt mf} filename prompting attitude as
soon as a base is read.)

\item  \verb+mf186 \mode=localfont input pics+  $\Longrightarrow$
  weird effect:
\begin{verbatim}
 >> unknown string mode_name1.2
 ! Not a string
 <to be read again>
                    ;
 mode_setup-> ...ode)else:mode_name[mode]fi;
 l.6 mode_setup
                ;
\end{verbatim}

Wow!  What a difference a semicolon can make!

\item \verb+mf186 \mode=localfont pics+  $\Longrightarrow$
  almost nothing happens:
\begin{verbatim}
    ** \mode=localfont pics

    *
\end{verbatim}

There's the echo I mentioned.  From the lack of activity, {\tt pics}
evidently needs to be `{\tt input}'.

\item  \verb+mf186 \mode=localfont; pics+  $\Longrightarrow$

    Same as 5.

So, yes, when the mode is specified, we need `{\tt input}'
before `{\tt pics}'.

\item  \verb+mf186 &plain \mode=localfont; input pics+  $\Longrightarrow$

    Works.

Just as without the `{\tt \&plain}', it writes a {\sc gf} file,
`{\tt pics.360gf}', which is correct.
({\sc ms-dos} truncates the name to `{\tt pics.360}'.)
So, redundancy seems okay.  Does it waste time, though?
\end{enumerate}


\subsection{Finding the Fonts}\label{sub:finding}

Finding the fonts ({\tt *.mf}, {\tt *.tfm}, {\tt *.gf}, and {\tt *.pk})
trips up \TeX{}, \MF{}, {\em GFtoPK} and the output drivers continually.
`{\tt pics.tfm}' needs to be put where \TeX{} will look for {\sc tfm\/}s,
so I needed to ensure that `{\tt .}' was in the appropriate path environment
variable.  Similarly for the \MF{}, {\sc gf} and {\sc pk} font files.

Environment variables can be tricky.  For instance, em\TeX{}'s font-making
automation program `{\em MFjob}' cannot make fonts in the current directory
unless both `{\tt .}' and `{\tt ..}' are added to {\tt MFINPUT}.
This was not documented.

Also, some popular \TeX{} output drivers, such as the em\TeX{} drivers
on {\sc ms-dos} and {\sc os/2}, and Tomas Rokicki's `{\tt dvips}'
which has been ported to many systems, make missing fonts automatically
--- provided that they can find the necessary \MF{} source files.
Again, making fonts in the current directory can require some
tweaking.


\subsection{Strange Paths}

\MF{} satisfactorily fills simple closed curves, like `{\tt O}'
and `{\tt D}', but filling a figure eight, `{\tt 8}', causes a
complaint:
\begin{verbatim}
    Strange path (turning number is zero)
\end{verbatim}
because \MF{}'s rules for distinguishing inside from outside
might or might not give what you want for an `{\tt 8}', as there is
more than one conceivable answer.  You can use the `positive turning
rule' for all cases, and also turn off complaints, by setting
\begin{verbatim}
    turningcheck := 0;
\end{verbatim}
Chapter 13:  `Drawing, Filling, and Erasing', and Chapter 27:
`Recovery from Errors', discuss {\tt strange paths} in greater
depth.


Sometimes, when making a perfectly valid font, but in {\em low\/}
resolutions, as for previewers (eg, VGA has 96 dpi), one may get
flak about a `{\tt Strange path}' or `{\tt Not a cycle}' or
something similar.  Don't be alarmed.  Fonts for previewing will
still be OK even if not perfect.

Consequently, it is an idea to make low resolution fonts in
\MF{}'s \hbox{\tt nonstopmode}.

Examples of fonts that give messages of this nature are the pleasant
Pandora, and --- from memory --- the commendable Ralf Smith's
Formal Script ({\tt rsfs}).  Everything is fine at higher resolutions.

Mind you, some fonts provoke sporadic
(that is, design size dependent)
strange path messages at 300 dpi
(photo-typesetter users would consider that low resolution),
yet the printed appearance showed no visible defect.

Why do strange paths occur?
One cause is rounding error on relatively coarse grids.

To summarize, if your viewed or printed bitmaps are fine,
then you are OK.


\section{\MF{} Mail List}

Since 10 December 1992, there has been an e-mail discussion list
for \MF{}, created:

\begin{enumerate}
\item  as a means of communication between hooked \MF{}ers;

\item  as a way to bring the ``rest of us'' closer to them;

\item  as a means to get quick and efficient answers to questions
       such as:

\begin{itemize}
    \item[$\circ$]  why do I always get a ``.2602gf'' file?
    \item[$\circ$]  what is a ``strange path'',
                  and what can I do to avoid it?
    \item[$\circ$]  is there a way to go from \MF{} to PostScript
                  and vice-versa?
    \item[$\circ$]  where can I find a Stempel Garamond font
                  written in \MF{}?
    \item[$\circ$]  what is metaness?
\end{itemize}

\item  and finally, as a first step to encourage people to undertake
    \MF{}ing, and start a new post-Computer Modern era of \MF{}!
\end{enumerate}

To subscribe to this list, send the following two lines to
{\tt listserv@ens.fr} on the Internet:
  \begin{quote}
    \tt
    SUBSCRIBE METAFONT $<$Your name$>$\\
    SET METAFONT MAIL ACK
  \end{quote} 
The address of the list is {\tt metafont@ens.fr} (at
  the notorious Ecole Normale Superieure de~Paris).  Owner of the list
  is Jacques Beigbeder ({\tt beig@ens.fr}), coordinator is Yannis
  Haralambous ({\tt yannis@gat.citilille.fr}).  Language of the list
  is English; intelligent mottos are encouraged.


\section{Conclusion}

\MF{}, like \TeX{} and many another `portable' program of any
complexity, merits the warning: `{\em Watch out for the first step\/}'.

I hope that a document like this may help to prevent domestic
accidents involving \MF{}, and so contribute to making the task
of using and designing meta-fonts an enjoyable one.  My brief
experience with \MF{} suggests that it can be so.


All the Best!

\end{article}
\egroup