book.
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 Algol2family of programming languages, of which C, C++, Pascal and Modula-2 are members.
The input can be interactive, or from a source file. source files are usually suffixed `.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 The book.
's bitmap output is a GF (generic font) file. This may be compressed to an equivalent PK (packed) font by the auxiliary program GFtoPK.
Why doesn't output PK fonts directly? Firstly, Tomas ROKICKI had not invented PK at the time Donald E. KNUTH was writing . Secondly, to change now would be too big a change in KNUTH's opinion. (KNUTH is a very conservative programmer; this fact is a two-sided coin.)
GF and PK files are suffixed `.*gf' and `.*pk' respectively, where, in a typical UNIX installation, the `*' stands for the font resolution. (Resolution will be explained below.) MS-DOS truncates file name suffixes to three characters, so a font suffix `.1200gf' becomes `.120' — beware of this!
A bitmap is all that's needed for large-scale proofs,
as produced by the GFtoDVI utility,
but for TEX to typeset a font it needs a TFM
(TEX Font Metric) file to describe the dimensions, ligatures
and kerns of the font. can be told to make a TFM file,
by making the internal variable `fontmaking' positive. Most
output device modes (see subsection ![[*]](crossref.png)
below) do this.
Remember that TEX reads only the TFM files. The glyphs, or forms of the characters, as stored in GF or PK font files, do not enter the picture (I mean, are not read) until the DVI drivers are run.
TEX can scale TFM files. Unfortunately, bitmaps such as
GF and PK are not scalable.
However, files can be compiled into fonts of arbitrary scale
by , even
by non-programmers — see subsection .
Incidentally, properly constructed TFM files are device-independent, so running with different modes normally produces the identical TFM. Dimensions in TFM files are specified to in device independent `sharped' dimensions (commonly suffixed by #), where a value of 1 corresponds to the dimension of 1pt (typographical point). Most of 's calculations are done with (resolution and device dependent) pixels as units. Care must be taken by font designers to 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 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 tftopl.
More detailed descriptions of TFM and GF files, and of
proof mode, are found in Appendices F, G, and H, respectively
of The book.
The TUG DVI Drivers Standard, Level 0, draft 0.05, includes precise definitions of the file structure of TFM metrics and of GF and PK bitmap fonts. That document is obtainable from the TEX archive at
ftp.uni-stuttgart.dewhere it is currently found as the several files in the directory
soft/tex/dviware/driv-standard/level-0Related information is contained in the documents in the `sister' directory
soft/tex/dviware/driv-standard/papers