path: root/usergrps/uktug/baskervi/3_1/mfbeg.tex

\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