Metafont is a system for producing shapes; it was designed for producing complete typeface families, but it can also produce geometric designs, dingbats, etc. And it has considerable mathematical and equation-solving capabilities which can be useful entirely on their own.
Metafont is a batch language, like C or Pascal: you compile a Metafont program into a corresponding font, rather than interactively drawing lines or curves. This approach has both considerable disadvantages (people unfamiliar with conventional programming languages will be unlikely to find it usable) and considerable advantages (you can make your design intentions specific and parameterizable). For a complete description of the Metafont language, see The METAFONTbook (see section B. References).
mf invocation
Metafont (usually invoked as mf) reads character definitions
specified in the Metafont programming language, and outputs the
corresponding font. This section merely describes the options available
in the Web2c implementation. For a complete description of the Metafont
language, see The Metafontbook (see section B. References).
Metafont processes its command line and determines its memory dump
(base) file in a way exactly analogous to MetaPost and TeX
(see section 4.1 tex invocation, and see section 3.5.2 Memory dumps). Synopses:
mf [option]... [mfname[.mf]] [mf-commands] mf [option]... \first-line mf [option]... &base args
Most commonly, a Metafont invocation looks like this:
mf '\mode:=mode; mag:=magnification; input mfname'
(The single quotes avoid unwanted interpretation by the shell.)
Metafont searches the usual places for the main input file mfname
(see section `Supported file formats' in Kpathsea), extending
mfname with `.mf' if necessary. To see all the relevant
paths, set the environment variable KPATHSEA_DEBUG to `-1'
before running the program. By default, Metafont runs an external
program named `mktexmf' to create any nonexistent Metafont source
files you input. You can disable this at configure-time or runtime
(see section `mktex configuration' in Kpathsea). This is mostly
for the sake of the EC fonts, which can be generated at any size.
Metafont writes the main GF output to the file `basemfname.nnngf', where nnn is the font resolution in pixels per inch, and basemfname is the basename of mfname, or `mfput' if no input file was specified. A GF file contains bitmaps of the actual character shapes. Usually GF files are converted immediately to PK files with GFtoPK (see section 10.2 GFtoPK: Generic to packed font conversion), since PK files contain equivalent information, but are more compact. (Metafont output in GF format rather than PK for only historical reasons.)
Metafont also usually writes a metric file in TFM format to `basemfname.tfm'. A TFM file contains character dimensions, kerns, and ligatures, and spacing parameters. TeX reads only this .tfm file, not the GF file.
The mode in the example command above is a name referring to a
device definition (see section 5.4 Modes: Device definitions for Metafont); for example, localfont or
ljfour. These device definitions must generally be precompiled
into the base file. If you leave this out, the default is proof
mode, as stated in The Metafontbook, in which Metafont outputs at
a resolution of 2602dpi; this is usually not what you want. The
remedy is simply to assign a different mode---localfont, for
example.
The magnification assignment in the example command above is a
magnification factor; for example, if the device is 600dpi and you
specify mag:=2, Metafont will produce output at 1200dpi.
Very often, the magnification is an expression such as
magstep(.5), corresponding to a TeX "magstep", which are
factors of
1.2 * sqrt(2).
After running Metafont, you can use the font in a TeX document as usual. For example:
\font\myfont = newfont \myfont Now I am typesetting in my new font (minimum hamburgers).
The program accepts the following options, as well as the standard `-help' and `-version' (see section 3.2 Common options):
inimf invocation
inimf is the "initial" form of Metafont, which does lengthy
initializations avoided by the "virgin" (vir) form, so as to be
capable of dumping `.base' files (see section 3.5.2 Memory dumps). For a
detailed comparison of virgin and initial forms, see section 3.5.1 Initial and virgin.
For a list of options and other information, see section 5.1 mf invocation.
The only memory dump file commonly used with Metafont is the default `plain.base', also known as `mf.base' (again, see section 3.5.2 Memory dumps). It is created by default during installation, but you can also do so by hand if necessary (e.g., if a Metafont update is issued):
inimf '\input plain; input modes; dump'
(The quotes prevent interpretation of the backslashes from the shell.) Then install the resulting `plain.base' in `$(basedir)' (`/usr/local/share/texmf/web2c' by default), and link `mf.base' to it.
For an explanation of the additional `modes.mf' file, see section 5.4 Modes: Device definitions for Metafont. This file has no counterpart in TeX or MetaPost.
In the past, it was sometimes useful to create a base file `cmmf.base' (a.k.a. `cm.base'), with the Computer Modern macros also included in the base file. Nowadays, however, the additional time required to read `cmbase.mf' is exceedingly small, usually not enough to be worth the administrative hassle of updating the `cmmf.base' file when you install a new version of `modes.mf'. People actually working on a typeface may still find it worthwhile to create their own base file, of course.
virmf invocation
virmf is the "virgin" form of Metafont, which avoids the
lengthy initializations done by the "initial" (ini) form, and
is thus what is generally used for production work. Usually it is
invoked under the name `mf'. For a detailed comparison of virgin
and initial forms, see section 3.5.1 Initial and virgin.
For a list of options and other information, see section 5.1 mf invocation.
Running Metafont and creating Metafont base files requires information that TeX and MetaPost do not: mode definitions which specify device characteristics, so Metafont can properly rasterize the shapes.
When making a base file, a file containing modes for locally-available devices should be input after `plain.mf'. One commonly used file is ftp://ftp.tug.org/tex/modes.mf; it includes all known definitions.
If, however, for some reason you have decreased the memory available in
your Metafont, you may need to copy `modes.mf' and remove the
definitions irrelevant to you (probably most of them) instead of using
it directly. (Or, if you're a Metafont hacker, maybe you can suggest a
way to redefine mode_def and/or mode_setup; right now, the
amount of memory used is approximately four times the total length of
the mode_def names, and that's a lot.)
If you have a device not included in `modes.mf', please see comments in that file for how to create the new definition, and please send the definition to tex-fonts@mail.tug.org to get it included in the next release of `modes.mf'.
Usually, when you run Metafont you must supply the name of a mode that
was dumped in the base file. But you can also define the mode
characteristics dynamically, by invoking Metafont with an assignment to
smode instead of mode, like this:
mf '\smode:="newmode.mf"; mag:=magnification; input mfname'
This is most useful when you are working on the definition of a new mode.
The magnification and mfname arguments are explained in
section 5.1 mf invocation. In the file `newmode.mf', you should have the
following (with no mode_def or enddef), if you are using
`modes.mf' conventions:
mode_param (pixels_per_inch, dpi); mode_param (blacker, b); mode_param (fillin, f); mode_param (o_correction, o); mode_common_setup_;
(Of course, you should use real numbers for dpi, b, f, and o.)
For more information on the use of smode, or if you are not using
`modes.mf', see page 269 of The Metafontbook.
The Web2c implementation of Metafont can do online graphics with a number of devices. (See the Metafont manual for more information about how to draw on your screen.) By default, no graphics support is enabled.
Metafont examines the MFTERM environment variable or config file
value at runtime, or the TERM environment variable if
MFTERM is not set, to determine the device support to use.
Naturally, only the devices for which support has been compiled in can
be selected.
Here is a table of the possibilities, showing the MFTERM value
and the corresponding configure option(s) in parentheses.
epsf
hp2627
mftalk
next
DrawingServant, available separately. See the
`web2c/window/next.c'.
regis
sun
gfx system
by using `sun-gfx.c'.)
tek
uniterm
xterm
Metafont. If you're using the Xt support, all the usual X toolkit
resources are supported. If you're using the Xlib support, only the
geometry resource is supported.
You specify the X display to which Metafont connects in the
DISPLAY environment variable, as usual.
Writing support for a new device is straightforward. Aside from defining the basic drawing routines that Metafont uses (see `mf.web'), you only have to add another entry to the tables on the last page of `web2c/lib/texmfmp.c'. Or you can write an independent program and use MFtalk (see `web2c/window/mftalk.c').
GFtoDVI makes proof sheets from a GF bitmap file as output by, for example, Metafont (see section 5. Metafont: Creating typeface families). This is an indispensable aid for font designers or Metafont hackers. Synopsis:
gftodvi [option]... gfname[gf]
The font gfname is searched for in the usual places (see section `Glyph lookup' in Kpathsea). To see all the relevant paths, set the
environment variable KPATHSEA_DEBUG to `-1' before running
the program.
The suffix `gf' is supplied if not already present. This suffix is not an extension; no `.' precedes it: for instance `cmr10.600gf'.
The output filename is the basename of gfname extended with `.dvi', e.g., `gftodvi /wherever/foo.600gf' creates `./foo.dvi'.
The characters from gfname appear one per page in the DVI output, with labels, titles, and annotations, as specified in Appendix H (Hardcopy Proofs) of The Metafontbook.
GFtoDVI uses several fonts besides gfname itself:
To change the default fonts, you must use special commands in
your Metafont source file.
The program accepts the following option, as well as the standard `-verbose', `-help', and `-version' (see section 3.2 Common options):
MFT translates a Metafont program into a TeX document suitable for typesetting, with the aid of TeX macros defined in the file `mftmac.tex'. Synopsis:
mft [option]... mfname[.mf]
MFT searches the usual places for mfname (see section `Supported file formats' in Kpathsea). To see all the relevant paths, set the
environment variable KPATHSEA_DEBUG to `-1' before running
the program. The output goes to the basename of mfname extended
with `.tex', e.g., `mft /wherever/foo.mf' creates
`./foo.tex'.
Line breaks in the input are carried over into the output; moreover, blank spaces at the beginning of a line are converted to quads of indentation in the output. Thus, you have full control over the indentation and line breaks. Each line of input is translated independently of the others.
Further control is allowed via Metafont comments:
%%% addto fill draw filldrawsays to format the `fill', `draw', and `filldraw' operations of plain Metafont just like the primitive token `addto', i.e., in boldface type. Without such reformatting commands, MFT would treat `fill' like an ordinary tag or variable name. In fact, you need a `%%%' command even to get parentheses to act like delimiters.
(The above description was edited from `mft.web', written by D.E. Knuth.)
The program accepts the following options, as well as the standard `-help' and `-version' (see section 3.2 Common options):
MFTINPUTS path; see section `Supported file formats' in Kpathsea.
Other examples of MFT style files are `cmbase.mft', which defines
formatting rules for the macros defined in `cm.base', and
`e.mft', which was used in the production of Knuth's Volume E,
Computer Modern Typefaces.
Using an appropriate MFT style file, it is also possible to configure
MFT for typesetting MetaPost sources. However, MFT does not search
the usual places for MetaPost input files.
If you use eight-bit characters in the input file, they are passed on verbatim to the TeX output file; it is up to you to configure TeX to print these properly.
Go to the first, previous, next, last section, table of contents.