# Metafont

Metafont is a description language used to define raster fonts. It is also the name of the interpreter that executes Metafont code, generating the bitmap fonts that can be embedded into e.g. PostScript. Metafont was devised by Donald Knuth as a companion to his TeX typesetting system.
One of the characteristics of Metafont is that the points defining the shapes of the glyphs—for example top of a stem, or intersection of a stem and crossbar—are defined with geometrical equations; the intent that the three stems of an ‘m’ are equally spaced horizontally might be expressed as $x_{2}-x_{1}=x_{3}-x_{2}$ if points 1, 2, and 3 are at the bottom ends of the three stems, whereas the intent that they all end on the same vertical position would be $y_{1}=y_{2}=y_{3}$.
Metafont is a macro language, where operations such as "draw a lower case top of stem serif at point 4" might appear as one macro instruction (with the point as argument) in the program for a letter. For describing shapes, Metafont has a rich set of path construction operations that mostly relieves the user of having to calculate control points.
Many families of Metafont fonts are set up so that the main source file for a font only defines a small number of design parameters (x-height, em width, slant, vertical stroke width, etc.), then calling a separate source file common for a whole range of fonts to actually draw the individual glyphs; this is the meta aspect of the system.

## Modes of operation

Metafont is most often run as a helper to output device (printer, screen) drivers; in those cases, its job is to generate bitmaps for a font for a specific combination of output device (called a mode in Metafont) and resolution (visible in the name of the output file, see below). These bitmaps are typically stored for later reuse, so that Metafont does not have to be run every time a document is displayed, but on the other hand TeX distributions with a Metafont component have typically not included any prebuilt bitmap fonts, since they would be rather large in comparison to the sources from which they could be generated. Since Metafont fonts were traditionally the TeX default from which other font formats were exceptions, an incomplete installation of a non-Metafont font can sometimes result in Metafont being called and emitting a confusing "somefont.mf not found" error message.
Equally important, but not as common, is running Metafont to generate a font metric (TFM) file; a TFM file is only generated if the fontmaking variable is positive. Traditionally TeX distributions have often come with all TFM files pregenerated (since they are pretty small), but someone installing a Metafont font from sources will have to generate its TFM file before TeX can use it.
A third way of operating Metafont is proof mode: if the proofing variable is positive then the bitmap font file also contains additional information provided via special commands, in particular the positions and names of points the font designer considered important for the design. If using the separate gftodvi utility to generate enlarged images of the font glyphs, this information from specials is included; point positions are not limited to pixel resolution.
Metafont can also be run interactively, and has commands for displaying on the screen the images it produces. Knuth has said that he uses Metafont as a kind of desk calculator for solving complicated equations, though he now uses MetaPost for mathematical illustrations.
Metafont can render any kind of graphical output, not just glyphs. However, MetaPost and Asymptote are preferred for mathematical illustrations. Metafont is most commonly invoked without a direct request from the user. DVI files can only contain references to typefaces, rather than the sets of raster or vector glyphs that other formats like PostScript allow. Consequently, the glyphs in the typefaces need to be accessed whenever a request is made to view, print or convert a DVI file.

### Output files

Metafont outputs several kinds of files: for a file called NAME.mf, it can output:
* NAME.NNNNgf – File with raster output at resolution NNNN (2602 by default).
* NAME.tfm – File with TeX font metric information, which is the information TeX needs. Usually metafont has to be told to generate this file.
* NAME.log – Log file output from processing
After running Metafont, typically one uses the gftopk program to convert the NNNNgf files to pk (packed) format (.NNNNpk). The pk format was primarily introduced to reduce file size (to about half), but expected to also speed up processing since less data would have to be input/output. The GF and PK formats both employ run-length encoding of bitmaps, but make different binary encodings of the run-lengths. The PK format also does some preprocessing of the bitmaps (bounding box, eliding repeated rows) and encodes all rows of a character as one long bit-sequence.
In the TeX Directory Structure standard, filenames are limited to 8+3 characters, so GF and PK files would only have extensions .gf and .pk. Files for different resolutions are kept apart by placing them in separate directories, named dpiNNNN, e.g. dpi300/cmr10.pk.

## Language

The Metafont language is an interpreted language for programs that are essentially declarative rather than imperative.

### Variables and equations

Variables in Metafont can be of eight different types:
* Numeric: fixed-point signed numbers with an epsilon of $2^{-16}$, capped to be less than 4096 (Q12.16). This is the default for variables not declared to be of another type.
* Pair: a pair of numerics, used primarily for representing points in the plane.
* Path: as in PostScript/PDF/SVG, a parametric curve in the plane whose coordinate functions are piecewise cubic polynomials. As in those other systems, path segments are encoded as Bézier curves in terms of knots and control points.
* Transform: an affine transformation of the plane, equivalent to a "(transformation) matrix" in PostScript/PDF.
* Pen: a convex polygon, representing the shape of a "pen" used for drawing.
* Picture: a raster image with a signed integer value for each pixel.
* Boolean
* String (of 8-bit characters)
Metapost adds color (a triple of numerics) as a ninth type and has a completely different (non-raster) model for pictures; the latter is the main point of divergence between the two programs. Metafont vardef macros also live in the same namespace as variables and may in some ways be regarded as a ninth type of variable, although macros do not exist as first-class values in Metafont.
Unusually, the names of variables are not simple tokens, but sequences of symbolic tokens and numeric indices; the variable name x2r is thus not one alphanumeric token, but a sequence of the three tokens x (symbolic), 2 (numeric), and r (symbolic). Record and array types may be simulated through collections of variables that share a common name prefix, an idiom supported by the type declaration system giving all variables whose names which differ only in numeric indices the same type (as expected for arrays) while keeping variables whole name differ in some symbolic token separate (as expected for records).
A very distinctive feature of Metafont is the use of equations to define variables. A numeric variable (or component of a pair or transformation variable) may be in the three states known (set), unknown independent (not set), and unknown dependent (not set, but given by a linear expression of one or several independents). When Metafont executes an equation statement, it turns one of the independents involved into a dependent and eliminates it from the expressions for all other dependents; when no independents remain in the expression for a dependent variable, that variable becomes known. Solving linear equation systems thus is a built-in feature of the Metafont language, and the recommended method of assigning most variables (especially those whose values have geometric significance) is to state equations determining their values. Equation systems frequently mix numeric (scalar) equations with pair (vector) equations.
An exception to the above is the class of internal quantity variables. These have names consisting of just one symbolic token, are always numeric, and are always known. They have a more direct internal representation than ordinary variables, making it convenient for primitive operations in Metafont (or extensions thereof) to use them implicitly.

### Syntax

Metafont has numeric and string constant tokens with mainstream syntaxes; strings are delimited by " quotes, numeric constants can have decimals but not an exponent part. All other tokens are classified as symbolic, and can be redefined arbitrarily; there is no restriction that tokens with certain meanings must have names consisting of certain characters. At runtime, there can additionally be capsule tokens, which are effectively constant value tokens of arbitrary type; in the source code those appear as symbolic tokens.
Except where characters are involved in numeric or string constants, the extent of the token containing a particular character depends on to which class the character belongs; unlike TeX, Metafont has fixed character classes. The characters ,, ;, (, and ) are "loners" and only form single character tokens. For the character classes <=>:|, ‘’ (single quotes), +-, /*\, !?, #&@$, ^~, [, ],, and ., as well as the class of underscore together with upper and lower case A–Z, the token consists of the longest consecutive sequence of characters from the same class. Whitespace characters don't contribute tokens. % starts a comment lasting until end of line.
A notable application of these rules is that # is frequently appearing as part of variable names in Metafont code, e.g. em# and pt#.
Delimiters (such as parentheses) do not have built-in meanings, instead there is a command that turns two symbolic tokens into a pair of matching delimiters, but normally Metafont programs use only the ordinary parentheses. Besides to override priorities in expressions, delimiters are also required around certain kinds of macro arguments.

### Graphics

Curves in Metafont are defined as cubic splines, rather than quadratic, for greater versatility at the cost of more complex arithmetic.
Unlike more common outline font formats (such as TrueType or PostScript Type 1), a Metafont font is primarily made up of strokes with finite-width "pens", along with filled regions. Thus, rather than describing the outline of the glyph directly, a Metafont file describes the pen paths. Some simpler Metafont fonts, such as the calligraphic mathematics fonts in the Computer Modern family, use a single pen stroke with a relatively large pen to define each visual "stroke" of the glyphs. More complex fonts such as the Roman text fonts in the Computer Modern family use a small pen to trace around the outline of the visual "strokes", which are then filled; the result is much like an outline font, but with slightly softened corners defined by the pen shape.
Since the font shapes are defined by equations rather than directly coded numbers, it is possible to treat parameters such as aspect ratio, font slant, stroke width, serif size, and so forth as input parameters in each glyph definition (which then define not a single font, but a meta-font). Thus, by changing the value of one of these parameters at one location in the Metafont file, one can produce a consistent change throughout the entire font. Computer Modern Roman illustrates many uses of this feature; a typical TeX installation includes a number of versions of the font in pitches from 5 to 17 cpi, with the stroke widths the same in all sizes (rather than increasing as the font is scaled up). In addition, the Computer Modern typewriter and sans-serif fonts are defined using essentially the same Metafont file as the Roman font, but with different global parameters.

## Use

While well-known type designers, such as Hermann Zapf, have collaborated with Knuth to create new fonts using Metafont, the system has not been widely adopted by professional type designers. Knuth attributes this to the fact that "asking an artist to become enough of a mathematician to understand how to write a font with 60 parameters is too much." Jonathan Hoefler commented that the Metafont system ultimately became "a technology behind zero of your favourite fonts...Knuth's idea that letters start with skeletal forms is flawed."
The Metafont system allows fonts to be processed in unusual ways; in 1982, Knuth showed how it could be used to morph fonts, with a serif font slowly transitioning into a sans-serif design over the course of a text.

## History

Donald Knuth started work on font creation software in 1977, and produced the first version of Metafont in 1979. Due to shortcomings in the original Metafont language, Knuth developed an entirely new Metafont system in 1984, and it is this revised system that is used today; Metafont has a versioning system similar to that of TeX, where the number asymptotically approaches e with each revision.

## Example

The following example creates a closed beanlike shape for the character "B" of a font:
This yields the following glyph:
The above example will be processed with a command line such as:
Then it can be used in a LaTeX file such as the following (all files should dwell in the same directory, or the TeX system should be informed about them using appropriate methods):
The resulting PDF file should look like this:

## Producing PostScript Type 1 fonts

There are several tools for converting Metafont programs to PostScript Type 1 fonts. Most make use of MetaPost's ability to convert a subset of Metafont's language into EPS outlines, which can subsequently be converted to PostScript Type 1 fonts. Generating vector outlines of Metafont pen strokes is nontrivial, as the Metafont model of a glyph is a raster image and the exact outlines of most strokes are not Bézier curves.
* The Polish JNS team developed METATYPE1 (based on MetaPost) for creating PostScript Type 1 fonts. Its big disadvantage is that no pens may be used which highly reduces the power of Metafont language. Initially, tool has been used by the Polish GUST typeface foundry to produce a modernized and extended variant of Computer Modern, called Latin Modern.
* mf2pt1, which is also based on Metapost, was developed by Scott Pakin with some contributions from Werner Lemberg. It also has several limitations detailed in its manual, the most significant one being the restriction that each glyph must be drawn entirely from closed paths. In order to overcome the limitations of mf2pt1, the EPS output by Metapost can be post-processed with FontForge, which is capable of interpreting complex PostScript paths generated by Metapost from Metafont's elliptic pens, and also capable of removing contour overlaps. Since FontForge supports scripting, this post-processing step can also be automated. This approach was used to produce Type 1 outlines for the MnSymbol mathematical font developed by Achim Blumensath; MnSymbol was designed as a companion to Minion Pro.
* MetaFog is a proprietary converter that can analytically convert pen strokes, but it requires manual post processing to eliminate degenerate cases, and it is not publicly available. It can process only Metapost output.
The common approach to generate Type 1 fonts with pen strokes remains to generate a high-resolution bitmap and then use an autotracer, implemented by packages such as mftrace and TeXtrace