% begin file mfb3w4.tex %
\documentstyle[11pt]{article}

% gt:  Narrower margins; no marginal notes.

\oddsidemargin=0in
\evensidemargin=0in
\marginparwidth=0in
\marginparsep=0in

% gt:  text width that is okay for both Am. Quarto and for A4 paper.

\textwidth=6.25in

% gt:  less gap at top of each page; more text height.

\addtolength{\textheight}{\topmargin}
\topmargin=0in
\addtolength{\textheight}{0.4in}

% gt:  Variant of \METAFONT macro in "texnames.sty":
% gt:  Uses empty discretionary.  See _The TeXbook_, p 95.
\font\mf=logo10
\font\mfsl=logosl10
\hyphenchar\mf=-1
\hyphenchar\mfsl=-1
% A way to get a hyphen, courtesy of Karl Berry.
\newcommand{\MF}{{\mf META}\-{\mf FONT\/}}
\newcommand{\MFSL}{{\mfsl META}\-{\mfsl FONT\/}}
\newcommand{\MFbook}{{\sl The \MFSL{}book\/}}
\newcommand{\TeXbook}{{\sl The \TeX{}book\/}}
\newcommand{\BibTeX}{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
                      T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
\newcommand{\ttbsl}{{\tt \char`\\\/}}  % typewriter type backslash.

% gt:  employing usual title font for "METAFONT" here.
\title{%
  \vspace*{-1in}%
  METAFONT for Beginners\\%
  {\normalsize Third Draft, Revision `W4'}\\%
  {\normalsize (14:12 GMT +10  Thursday 14 July 1994)}%
}

\date{}

\author{Geoffrey {\sc Tobin} ({\tt G.Tobin@ee.latrobe.edu.au})}

\begin{document}

\maketitle

\tableofcontents

\newpage


\section*{Scope}%
\addcontentsline{toc}{section}{Scope}

This is not a tutorial on \MF{}.  It is an attempted description of
how some of the pitfalls in running the program may, hopefully, be
avoided.


\section*{Where you can obtain this file}\label{sec:CTAN}%
\addcontentsline{toc}{section}{Where you can obtain this file}

For those without ftp, an older version of \MF{} for Beginners can be
received by email from:
\begin{verbatim}
    fileserv@shsu.edu
\end{verbatim}
by sending the one-line message:
\begin{verbatim}
    sendme faq.mf
\end{verbatim}

\MF{} for Beginners can be obtained by ftp from the CTAN
(Comprehensive \TeX{} Archive Network) sites, in the
\begin{verbatim}
    documentation
\end{verbatim}
subdirectory, as the file
\begin{verbatim}
    metafont-for-beginners.tex
\end{verbatim}

The following record of a unix `script' command lists several
CTAN sites.

\begin{verbatim}
bash$ script
Script started on Mon Jun 27 19:17:54 1994
bash$ finger ctan_us@ftp.shsu.edu
[ftp.shsu.edu]
Login name: ctan_us   			In real life: US CTAN
Bldg:  			 
Directory: /pub/mirror/ctan_us      	Shell: /usr/local/bin/tcsh
Last login Sun Jun 26 14:59 on ttyp6
Plan:
In order to reduce network load, it is recommended that you use the CTAN
host which is located in the closest network proximity to your site.  

The participating hosts in the Comprehensive TeX Archive Network (CTAN) are:
  ftp.dante.de  (Germany)               /tex-archive (/pub/tex /pub/archive)
  ftp.shsu.edu  (Texas, USA)            /tex-archive (/pub/tex /pub/archive)
  ftp.tex.ac.uk (England)               /tex-archive (/pub/tex /pub/archive)

Known mirrors of the CTAN reside on (alphabetically):
  ftp.center.osaka-u.ac.jp (Japan)      /CTAN
  ftp.cs.rmit.edu.au  (Australia)       /tex-archive
  ftp.loria.fr (France)                 /pub/unix/tex/ctan
  ftp.uni-bielefeld.de (Germany)        /pub/tex
  ftp.uni-stuttgart.de (Germany)        /tex-archive (/pub/tex)
  ftpserver.nus.sg (Singapore)          /pub/zi/TeX
  src.doc.ic.ac.uk (England)            /packages/tex/uk-tex
  sunsite.unc.edu (North Carolina, USA)	/pub/packages/TeX
  wuarchive.wustl.edu (Missouri, USA)   /packages/TeX

Known partial mirrors of the CTAN reside on (alphabetically):
  dongpo.math.ncu.edu.tw (Taiwan)       /tex-archive
  ftp.adfa.oz.au (Australia)            /pub/tex/ctan
  ftp.muni.cz (The Czech Republic)      /pub/tex/CTAN
  nic.switch.ch (Switzerland)           /mirror/tex
  ftp.cs.ruu.nl (The Netherlands)       /pub/tex-archive
Please send updates to this list to <CTAN-Mgr@SHSU.edu>.
bash$ exit
exit

script done on Mon Jun 27 19:18:09 1994
\end{verbatim}


\section*{Reference}%
\addcontentsline{toc}{section}{Reference}

\MFbook{}, by Donald Ervin {\sc Knuth}, published by the
American Mathematical Society and Addison Wesley Publishing Company.
First edition, 1986, covers \MF{} 1.0.
Later editions cover \MF{} 2.0 and above.
This file is based, except where indicated otherwise,
on the 1986 edition.\footnote
{Opinion:  I actually enjoy reading \MFbook{},
whereas \TeXbook{} confuses me no end.}


\section*{Acknowledgements}%
\addcontentsline{toc}{section}{Acknowledgements}

Additions and corrections were kindly contributed by:
\begin{quote}
Bill {\sc Alford} ({\tt bill@phys.anu.edu.au}),\\
Tim A.~H.~{\sc Bell} ({\tt bhat@mundil.cs.mu.oz.au}),\\
Karl {\sc Berry} ({\tt karl@cs.umb.edu}),\\
Gert W.~{\sc Bultman} ({\tt bultman@dgw.rws.nl}),\\
Anita {\sc Zanolini Hoover} ({\tt anita@ravel.udel.edu}),\\
Berthold K.~P.~{\sc Horn} ({\tt bkph@kauai.ai.mit.edu}),\\
Micha{\l} {\sc Jaegermann} ({\tt ntomczak@vm.ucs.ualberta.ca}),\\
\hspace*{4em}and\\
David {\sc Kastrup} ({\tt dak@pool.informatik.rwth-aachen.de}).
\end{quote}

Typesetting was initiated by
\begin{quote}
Yannis {\sc Haralambous} ({\tt yannis@gat.citilille.fr}).
\end{quote}

Mistakes remain copyright \copyright{} 1994 Geoffrey {\sc Tobin}.


\section*{Motivation}%
\addcontentsline{toc}{section}{Motivation}

It's a common experience to have initial (and medial and final
{\tt :-)} ) 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\footnote
{Around 1960, Donald {\sc Knuth} worked as an Algol compiler
designer.}
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 {\sf GFtoPK}.

Why doesn't \MF{} output {\sc pk} fonts directly?  Firstly, Tomas
{\sc Rokicki} had not invented {\sc pk} at the time Donald
E.~{\sc Knuth} was writing \MF{}.  Secondly, to change \MF{} now
would be too big a change in {\sc Knuth}'s opinion.  ({\sc 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 {\sf 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 subsection \ref{sub:modes} 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.
% deleted "except in integer multiples of their original size".
% Pixel replication is as inexact an interpolation as other schemes,
% and does not produce adequate images.
However, \MF{} files can be compiled into fonts of arbitrary scale
by \MF{}, even
by non-programmers --- see subsection \ref{sub:mag}.

Incidentally, properly constructed {\sc tfm} files are
device-independent, so running \MF{} with different modes normally
produces the identical {\sc tfm}.
% This explanation might want a different place...
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 TFM file is device-independent
is to create the font in different modes and compare the resulting
TFM's, perhaps using {\sf 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{}.

{\sl The TUG {\sc dvi} Drivers Standard, Level 0}, draft 0.05, includes
precise definitions of the file structure of {\sc tfm} metrics and of
{\sc gf} and {\sc pk} bitmap fonts.
That document is obtainable from CTAN (see section \ref{sec:CTAN}
above) as the several files in the subdirectory:
\begin{verbatim}
    dviware/driv-standard/level-0
\end{verbatim}
Related information is contained in the documents in the `sister'
directory
\begin{verbatim}
    dviware/driv-standard/papers
\end{verbatim}


\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
(see subsection \ref{sub:modes} below)
requires the \MF{} command {\tt mode},
and output magnification
(subsection \ref{sub:mag})
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's 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 (see subsection \ref{sub:typo} below),
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's 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.

For the Macintosh, which is not command line based,
Tim {\sc Bell} reports that one port of \MF{}
(by Timothy {\sc Murphy\/} {\tt <tim@maths.tcd.ie>} 22 January 1993)
simulates the command line within the program
(using a special THINK C library written just for that).
But what you type goes through some string processing,
so you need double `\verb+\+'s.
Thus your example line reads:
\begin{verbatim}
    mf \\mode=localfont; input myfont10
\end{verbatim}


\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 (see
subsection~\ref{sub:link} for why this works) {\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 {\sc 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 recognised 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 (see section \ref{sub:env} below), 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 {\sf 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 {\sc Berry\/}'s {\sf 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, {\sf web2c} will update `{\tt plain.base}'
(and `{\tt plain.fmt}', and so on) for you,
if you tell {\sf 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's 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 {\sc 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 {\sc Computer
Modern (cm)}, font, you must give it a new name.  This is an honest
practice, and will avoid confusion.


\subsection{Using a New Font in \TeX{}}\label{sub:tex}

To use a new font in a \TeX{} document, select it specifically.
Example:  in a \TeX{} macro file, or in a \LaTeX{} style file,
to define \verb+\mine+ as a font-selection command for
`{\tt myfont10.tfm}', say:
\begin{verbatim}
    \font\mine=myfont10
\end{verbatim}

Then to typeset `Mary had a little lamb,' in the {\tt myfont10} font,
and then to revert to the previous font, type
\begin{verbatim}
    {\mine Mary had a little lamb,}
\end{verbatim}
Note, however, that this will not change the line spacing parameters
of \TeX{} as
well. If your lines appear a little too cramped and unevenly spaced vertically,
it is very probable that you need to increase \verb+\baselineskip+.
For \LaTeX{} users, a simple remedy is to just select a larger font
before your own.  Also, end your paragraph by an empty line or a
\verb+\par+ command before the closing brace, or your line spacing changes
will be cancelled before the paragraph has a chance of being typeset.


\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{{\sf GFtoPK}}\label{sub:gftopk}

\TeX{} uses only the {\sc tfm} file, which \MF{}
will produce if it's 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 {\sf 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,
% `set' in the Bourne shell is dangerous, because it gives the values
% of non-environment variables of the shell as well. If you forgot
% to say export, you might have some time detecting your omission
% if you use just `set'.
in {\sc unix}.  In the {\sc unix} C shell, {\tt csh}, type
`{\tt setenv}'.

Micha{\l} {\sc Jaegermann} notes that on a `virgin' installation
--- in which everything is in default directories and no environment
variables have yet been set --- that won't succeed.  Presumably we're
talking to system installers now.  So, as a first resort:
\begin{quote}
    \em Read The Manual.
\end{quote}
As a last resort, one can discover default values and environment
variable names by using a command like {\sc unix}'s {\tt strings}
on the executable files.
For instance:
\begin{verbatim}
    strings -6 /bin/virmf | less
\end{verbatim}
(Use `more' or `pg' for paging, if `less' is not available.)
Seeking 6-letter names is about right, as ``{\tt TEXPKS}'' has six
letters, while {\tt strings\/}' default of four collects too much
random noise.
Environment variables are usually in upper case, and their names
strongly hint at their purposes.
Default locations may be discovered by looking for path name strings.

Using this advice may show some undocumented names.
If you have the program sources, you may check their purpose.
Otherwise, not to worry, the important ones should be self-evident.
As an illustration, here are some environment variable names found by
applying ``strings -6'' to {\sc Rokicki's} {\tt dvips}:
\begin{verbatim}
    * DVIPSHEADERS
      HOME
    * PKFONTS
      PRINTER
      TEXCONFIG
      TEXFONTS
      TEXINPUTS
    * TEXPACKED
    * TEXPICTS
      TEXPKS
      VFFONTS
\end{verbatim}
The four starred names are not documented by the {\tt dvips} manual
(for version 5.484).
In Karl {\sc Berry's} {\tt dvipsk}, a variant of {\tt dvips},
{\tt DVIPSHEADERS}\footnote{In version 5.518b, which is forthcoming.},
{\tt PKFONTS} and {\tt TEXPICTS} {\em are\/}
documented, while {\tt TEXPACKED} is {\em not used}.

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 (see subsection \ref{sub:env})
that the programs read, to override the defaults.

\MF{} (as illustrated in section \ref{sec:typing} above),
as well as the {\sc dvi} drivers,
can also be given full path specifications for input files.
(On most systems, so can \TeX{}, but, as Berthold K.~P.~{\sc Horn}
({\tt bkph@kauai.ai.mit.edu}) has observed,
{\sc ms-dos} poses the problem that the backslash `\ttbsl{}'
used in {\sc ms-dos} path names is very special in \TeX{} input.
However, I'll leave solving that one to the \TeX{}ackers.)

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's up to you
or your local system administrator(s) to know where these directories
are, because their names are very locale dependent.


\subsection{Environment Variables for em\TeX{} and {\sf web2c}}%
\label{sub:env}

Environment variables often cause confusion, as they vary unpredictably
--- sometimes subtly, sometimes widely --- between systems.

Em\TeX{} for {\sc ms-dos} and {\sf web2c} for {\sc unix} are two
popular distributions of \TeX{}, \MF{}, and associated programs.
It's worthwhile therefore to compare their environment variables.

Firstly, the variables used leading up to the production of the
{\sc dvi} file:

\begin{center}
\begin{tabular}{|l|l|l|}
  \hline
  \multicolumn{3}{|c|}{\TeX{}, \BibTeX{}, \MF{} and {\sf MFjob}} \\
  \hline
  Seeking & em\TeX{} & {\sf web2c} \\
  \hline
  \TeX{} Pool file & {\tt TEXFMT}, {\tt BTEXFMT} & {\tt TEXPOOL} \\
  \TeX{} Formats & {\tt TEXFMT}, {\tt BTEXFMT} & {\tt TEXFORMATS} \\
  \TeX{} Inputs & {\tt TEXINPUT} & {\tt TEXINPUTS} \\
  \TeX{} Font Metrics & {\tt TEXTFM} & {\tt TFMFONTS, TEXFONTS} \\
  \hline
  \BibTeX{} {\tt bst} & {\tt TEXINPUT} & {\tt BSTINPUTS, TEXINPUTS} \\
  \BibTeX{} {\tt bib} & {\tt BIBINPUT} & {\tt BIBINPUTS} \\
  \hline
  \MF{} Pool & {\tt MFBAS, BMFBAS} & {\tt MFPOOL} \\
  \MF{} Bases & {\tt MFBAS, BMFBAS} & {\tt MFBASES} \\
  \MF{} Inputs & {\tt MFINPUT} & {\tt MFINPUTS} \\
  {\sf MFjob} Inputs & {\tt MFJOB} & \multicolumn{1}{c|}{---} \\
  \hline
\end{tabular}
\end{center}

The second table compares the environment variables used by em\TeX{}'s
{\sc dvi} drivers with those for Tomas {\sc Rokicki\/}'s portable
{\sf PostScript} driver, {\tt dvips}.

\begin{center}
\begin{tabular}{|l|l|l|}
  \hline
  \multicolumn{3}{|c|}{{\sc dvi} Drivers} \\
  \hline
  Seeking & em\TeX{} Drivers & {\tt dvips} \\
  \hline
  {\sc dvi} files & {\tt DVIDRVINPUT} & {\em current directory} \\
  {\sc pk} Fonts & {\tt DVIDRVFONTS} & {\tt TEXPKS, PKFONTS} \\
  Bitmap Graphics & {\tt DVIDRVGRAPH} & \multicolumn{1}{c|}{---} \\
  Virtual Fonts & set by {\tt /pv} option & {\tt VFFONTS, TEXFONTS} \\
  {\tt MakeTeXPK} & \multicolumn{1}{c|}{---} & {\tt MAKETEXPK} \\
  {\tt config.ps} & \multicolumn{1}{c|}{---} & {\tt TEXCONFIG} \\
  {\sc ps} files & \multicolumn{1}{c|}{---} & {\tt TEXINPUTS} \\
  \hline
\end{tabular}
\end{center}

Where two or more variables are listed together, they are
searched from left to right.  For example, {\tt dvips} seeks {\sc pk}
fonts first in {\tt TEXPKS}, then in {\tt PKFONTS}.
By the way, if no {\sc pk} fonts can be found, then {\tt dvips}
uses the {\sc tfm} files to determine spacing, and leaves the
characters blank.

{\sc Berry}'s {\tt dvipsk} seeks {\sc pk} fonts in whichever
{\em one\/} of {\tt PKFONTS, TEXPKS, GLYPHFONTS} and {\tt TEXFONTS}
--- in that order --- is set and of the highest priority.
If a font cannot be found via environment variables, then the
compile-time system default paths are searched; any lower priority
font path environment variables are ignored --- which may also be the
behavior of Rokicki's {\tt dvips}, but readers are encouraged to
discover the truth for themselves.
In addition, {\tt dvipsk} seeks {\sc gf} fonts using the successive
environment variables {\tt GFFONTS, GLYPHFONTS} and {\tt TEXFONTS}.

{\sf MFjob} and {\tt MakeTeXPK} have a similar function:
to create {\sc pk} fonts from \MF{} files.
When {\sc pk} fonts are missing, but the \MF{} font sources
are available,
{\sf MFjob} can be called by recent versions (1.4r and above)
of the em\TeX{} drivers to create the missing fonts.
{\tt MakeTeXPK} is called by {\tt dvips} for the same purpose.

In {\sc Berry\/}'s {\tt web2c 5.851d}\footnote
{Available at {\tt ftp.cs.umb.edu} in the {\tt pub/tex} directory.},
\TeX{} can be configured to call {\tt MakeTeXTFM} and
{\tt MakeTeXTeX}, and \MF{} to call {\tt MakeTeXMF},
to make missing {\sc tfm}, \TeX{}, and \MF{} files, respectively.
{\tt MakeTeXTFM}, like {\tt MakeTeXPK}, can call \MF{}.
Design of {\tt MakeTeXTeX} and {\tt MakeTeXMF} are up to the user's
imagination --- Karl says that one possibility is to employ {\tt ftp}.


\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's 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.

References for some of the subsequent points:

\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', {\sc 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's
\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's 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{}, {\sf 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 `{\sf 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 {\sc 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{{\tt MakeTeXPK}}\label{sub:maketexpk}

On {\sc unix}, when fonts are missing,
{\tt dvips} calls a Bourne shell script, `{\tt MakeTeXPK}',
which creates a temporary directory, which it then changes to,
before calling \MF{} to make the missing fonts.
The change of directory can cause \MF{} not to find font sources
lying in what {\bf used} to be the current directory.

Gert W.~{\sc Bultman} ({\tt bultman@dgw.rws.nl}) has suggested the
following modification to {\tt MakeTeXPK\/}:
\begin{verbatim}
    MFINPUTS=${MFINPUTS}:`pwd`; export MFINPUTS
\end{verbatim}
to add the current directory to the search path, {\em before\/} the
change to the temporary directory:
\begin{verbatim}
    cd $TEMPDIR
\end{verbatim}

Micha{\l} {\sc Jaegermann} ({\tt ntomczak@vm.ucs.ualberta.ca})
has pointed out that:

`This will not work very well in a situation when the {\tt MFINPUTS} variable
is not set, and you rely instead on \MF{} files being in a default
location.  The problem is that in such a situation, after an execution
of the line above, you will end up with ONLY your 'current working
directory' in the {\tt MFINPUTS} path, [which still leaves you
without access to the standard \MF{} files].

`For the Bourne shell, {\tt sh}, this line should rather read
somewhat\footnote
{gt:  I've separated this into two (valid, unix Bourne shell) lines,
to fit into the text width of this document.}
like:
\begin{verbatim}
    MFINPUTS=`pwd`:${MFINPUTS-/usr/lib/mf/inputs}
    export MFINPUTS
\end{verbatim}
which gives you a fallback position.  Of course,
\begin{verbatim}
    /usr/lib/mf/inputs
\end{verbatim}
should be replaced by a default value for the {\tt MFINPUTS} path.

`This problem is highly likely to affect budding \MF{} hackers
on {\sf NeXT}, for example.'

Micha{\l}'s suggestion gives priority to \MF{} files in the directory that
is current when MakeTeXPK is called, which is the usual preference.
In {\tt sh}, the `{\tt \${A-B}}' construction has the value of {\tt A},
if {\tt A} is defined, and the value of {\tt B}, otherwise.

Karl {\sc Berry} advises that for {\tt web2c 5.851c} and above,
a leading or trailing colon in a path is replaced by the compile-time
default path.  For {\tt web2c} he suggests:
\begin{verbatim}
    if test -z "$MFINPUTS"; then
      MFINPUTS=`pwd`:
    else
      MFINPUTS=`pwd`:$MFINPUTS:
    fi
\end{verbatim}

Test these ideas on your system, to see what is most applicable.

Incidentally, on {\sc ms-dos}, {\tt dvips} calls a batch file,
`{\tt MAKETEXP.BAT}', but, in the {\sc ms-dos} versions I've seen,
this lacks the change to a temporary directory that causes
the problem that occurs both in the {\sc unix} versions of {\tt dvips}
and in em\TeX{}'s MFjob.


\subsection{Strange Paths; Not a cycle; Bad pos}

\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}', `{\tt Not a cycle}',
`{\tt bad pos}', or something similar.  Don't be alarmed.  Fonts for
previewing will still be OK even if not perfect.  (Actually, I don't
spot any difference!)

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

Em\TeX{}'s drivers version 1.4s make missing fonts automatically
through the {\tt MFjob} program (version 1.1l).  To keep {\tt MFjob}
running, add the option {\tt /i} (`ignore errors produced by \MF{}')
to the {\tt MFJOBOPT} environment variable.

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
(phototypesetter users would consider that low resolution),
yet the printed appearance shows 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 and affiliation$>$\\
    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 {\sc Beigbeder}
(``{\tt beig@ens.fr}''),
coordinator is Yannis {\sc 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!
%% Geoffrey Tobin

\end{document}
% end file mfb3w4.tex %