# Web2c ¶

This document describes how to install and use the programs in the Web2c implementation of the TeX system, especially for Unix systems. It corresponds to Web2c version 2026, released in January 2026.

## Table of Contents

## 1 Introduction ¶

This manual corresponds to version 2026 of Web2c, released in January 2026.

Web2c (also spelled Web2C) is the name of a TeX implementation, originally for Unix, but now also running under Windows and other operating systems. By TeX implementation, we mean all of the standard programs developed by the Stanford TeX project led by Donald E. Knuth: Metafont, DVItype, GFtoDVI, BibTeX, Tangle, etc., as well as TeX itself. Other programs are also included: DVIcopy, written by Peter Breitenlohner, MetaPost and its utilities (derived from Metafont), by John Hobby, and many more.

General strategy: Web2c works, as its name implies, by translating the WEB source in which TeX is written into C source code. Its output is not self-contained, however; it makes extensive use of many macros and functions in a library (the `web2c/lib` directory in the sources). Therefore, it will not work without change on an arbitrary WEB program.

Availability: All of Web2c is freely available—“free” both in the sense of no cost (free ice cream) and of having the source code to modify and/or redistribute (free speech). See unixtex.ftp in Kpathsea, for the practical details of how to obtain Web2c.

Different parts of the Web2c distribution have different licensing terms, however, reflecting the different circumstances of their creation; consult each source file for exact details. The main practical implication for redistributors of Web2c is that most of the executables are covered by the GNU General Public License or GNU Lesser General Public License, and therefore anyone who gets a binary distribution must also be able to get the sources, as explained by the terms of the GPL (https://gnu.org/licenses/). The GPL covers the Web2c executables, including `tex`, because the Free Software Foundation sponsored the initial development of the Kpathsea library that Web2c uses. The basic source files from Stanford, however, have their own copyright terms or are in the public domain, and are not covered by the GPL.

History: Tomas Rokicki originated the TeX-to-C system in 1987, working from the first change files for TeX under Unix, which were done primarily by Howard Trickey and Pavel Curtis. Tim Morgan then took over development and maintenance for a number of years; the name changed to Web-to-C somewhere in there. In 1990, Karl Berry became the maintainer. He made many changes to the original sources, and started using the shorter name Web2c. In 1997, Olaf Weber took over, and then in 2006, Karl started taking care of it again. No significant development or changes have been needed for many years, though dozens of other people have contributed in many ways; their names are listed in the `ChangeLog` files.

Originally, Web2c was distributed as its own package, alongside the original web programs from Stanford and other components. It was also the basis for the teTeX distribution (now discontinued). Around 2004, the packaging focus shifted entirely to the TeX Live distribution (https://tug.org/texlive/), though the same Web2c is at the heart of the release.

Other acknowledgements by Karl: The University of Massachusetts at Boston (particularly Rick Martin and Bob Morris) provided computers and ftp access to me for many years. Richard Stallman at the Free Software Foundation employed me while I wrote the original path searching library (for the GNU font utilities). (rms also gave us Emacs, GDB, and GCC, without which I cannot imagine developing Web2c.) And, of course, TeX would not exist in the first place without Donald E. Knuth.

Further reading: See References.

## 2 Installation ¶

(A copy of this chapter is in the distribution file `web2c/INSTALL`.)

Installing Web2c is mostly the same as installing any other Kpathsea-using program. Therefore, for the basic steps involved, see Installation in Kpathsea. (A copy is in the file `kpathsea/INSTALL`.)

One peculiarity to Web2c is that the source distribution comes in two files: `web.tar.gz` and `web2c.tar.gz`. You must retrieve and unpack them both. (We have two because the former archive contains the very large and seldom-changing original WEB source files.) See unixtex.ftp in Kpathsea.

Another peculiarity is the MetaPost program. Although it has been installed previously as `mp`, as of Web2c 7.0 the installed name is now `mpost`, to avoid conflict with the `mp` program that does prettyprinting. This approach was recommended by the MetaPost author, John Hobby. If you as the TeX administrator wish to make it available under its shorter name as well, you will have to set up a link or some such yourself. And of course individual users can do the same.

For solutions to common installation problems and information on how to report a bug, see the file `kpathsea/BUGS` (see Bugs in Kpathsea). See also the Web2c home page, http://www.tug.org/web2c.

Points worth repeating:

- Before starting the standard compilation and installation you must install the basic fonts, macros, and other library files. See Installation in Kpathsea.
- If you do not wish to use the standard file locations, see Changing search paths in Kpathsea.
- Some Web2c features are enabled or disabled at `configure` time, as described in the first section below.

### 2.1 `configure` options ¶

This section gives pointers to descriptions of the ‘`--with`’ and ‘`--enable`’ `configure` arguments that Web2c accepts. Some are specific to Web2c, others are generic to all Kpathsea-using programs.

For a list of all the options `configure` accepts, run ‘`configure --help`’. The generic options are listed first, and the package-specific options come last.

For a description of the generic options (which mainly allow you to specify installation directories) and basic `configure` usage, see Running `configure` scripts in Autoconf, a copy is in the file `kpathsea/CONFIGURE`.

‘`--disable-dump-share`’

  Do not make fmt/base/mem files sharable across different endian architectures. See Hardware and memory dumps.

‘`--without-maketexmf-default`’
‘`--without-maketexpk-default`’
‘`--without-maketextfm-default`’
‘`--with-maketextex-default`’

  Enable or disable the dynamic generation programs. See mktex configuration in Kpathsea. The defaults are the inverse of the options, i.e., everything is enabled except `mktextex`.

‘`--enable-shared`’

  Build Kpathsea as a shared library. See Shared library in Kpathsea.

‘`--with-editor=cmd`’

  Change the default editor invoked by the ‘`e`’ interactive command. See Editor invocation.

‘`--with-epsfwin`’
‘`--with-hp2627win`’
‘`--with-mftalkwin`’
‘`--with-nextwin`’
‘`--with-regiswin`’
‘`--with-suntoolswin`’
‘`--with-tektronixwin`’
‘`--with-unitermwin`’
‘`--with-x`’
‘`--with-x-toolkit=KIT`’
‘`--with-x11win`’
‘`--with-x11`’

  Define Metafont graphics support; by default, no graphics support is enabled. See Online Metafont graphics.

‘`--x-includes=dir`’
‘`--x-libraries=dir`’

  Define the locations of the X11 include files and libraries; by default, `configure` does its best to guess). See Optional Features in Autoconf. A copy is in `kpathsea/CONFIGURE`.

### 2.2 Compile-time options ¶

In addition to the `configure` options listed in the previous section, there are a few things that can be affected at compile-time with C definitions, rather than with `configure`. Using any of these is unusual.

To specify extra compiler flags (‘`-Dname`’ in this case), the simplest thing to do is:

    make XCFLAGS="ccoptions"

You can also set the `CFLAGS` environment variable before running `configure`. See configure environment in Kpathsea.

Anyway, here are the possibilities:

‘`-DFIXPT`’ ¶
‘`-DNO_MF_ASM`’

  Use the original WEB fixed-point routines for Metafont and MetaPost arithmetic calculations regarding fractions. By default, assembly-language routines are used on x86 hardware with GNU C (unless ‘`NO_MF_ASM`’ is defined), and floating-point routines are used otherwise.

‘`-DIPC_DEBUG`’ ¶

  Report on various interprocess communication activities. See IPC and TeX.

### 2.3 Additional targets ¶

Web2c has several Make targets besides the standard ones. You can invoke these either in the top level directory of the source distribution (the one containing `kpathsea/` and `web2c/`), or in the `web2c/` directory.

‘`c-sources`’ ¶

  Make only the C files, translated from the Web sources, presumably because you want to take them to a non-Unix machine.

‘`formats`’ ¶
‘`install-formats`’

  Make or install all the memory dumps (see Memory dumps). By default, the standard plain formats plus `latex.fmt` are made. You can add other formats by redefining the `fmts`, `bases`, and `mems` variables. See the top of `web2c/Makefile` for the possibilities.

‘`fmts`’ ¶
‘`install-fmts`’

  Make or install the TeX `.fmt` files. See Initial TeX.

‘`bases`’ ¶
‘`install-bases`’

  Make or install the Metafont `.base` files. See Initial Metafont.

‘`mems`’ ¶
‘`install-mems`’

  Make or install the MetaPost `.mem` files. See Initial MetaPost.

‘`triptrap`’ ¶
‘`trip`’
‘`trap`’
‘`mptrap`’

  To run the torture tests for TeX, Metafont, and MetaPost (respectively). See the next section.

### 2.4 Trip, trap, and mptrap: Torture tests ¶

To validate your TeX, Metafont, and MetaPost executables, run ‘`make triptrap`’. This runs the trip, trap, and mptrap “torture tests”. See the files `triptrap/tripman.tex`, `triptrap/trapman.tex`, and `triptrap/mptrap.readme` for detailed information and background on the tests.

The differences between your executables’ behavior and the standard values will show up on your terminal. The usual differences (these are all acceptable) are:

- string usage and table sizes;
- glue set ratios;
- ‘`down4`’, ‘`right4`’, and ‘`y4`’ commands in DVItype output;
- dates and times.

Any other differences are trouble. The most common culprit in the past has been compiler bugs, especially when optimizing. See TeX or Metafont failing in Kpathsea.

The files `trip.diffs`, `mftrap.diffs`, and `mptrap.diffs` in the `triptrap` directory show the standard diffs against the original output. If you diff your diffs against these files, you should come up clean. For example

    make trip >&mytrip.diffs
    diff triptrap/trip.diffs mytrip.diffs

To run the tests separately, use the targets `trip`, `trap`, and `mptrap`.

To run simple tests for all the programs as well as the torture tests, run ‘`make check`’. You can compare the output to the distributed file `tests/check.log` if you like.

## 3 Commonalities ¶

Many aspects of the TeX system are the same among more than one program, so we describe those pieces together, here.

Another kind of commonality is the extensions to TeX that are available across all the engines; see Extended TeX engines.

### 3.1 Option conventions ¶

To provide a clean and consistent behavior, we chose to have all these programs use the GNU function `getopt_long_only` to parse command lines. It is used in a restricted mode where all the options have to come before the rest of the arguments.

As a result, you can:

- use ‘`-`’ or ‘`--`’ to start an option name;
- use any unambiguous abbreviation for an option name;
- separate option names and values with either ‘`=`’ or one or more spaces;
- use filenames that would otherwise look like options by putting them after an option ‘`--`’.

By convention, non-option arguments, if specified, generally define the name of an input file, as documented for each program.

If a particular option with a value is given more than once, it is the last value that counts.

For example, the following command line specifies the options ‘`foo`’, ‘`bar`’, and ‘`verbose`’; gives the value ‘`baz`’ to the ‘`abc`’ option, and the value ‘`xyz`’ to the ‘`quux`’ option; and specifies the filename `-myfile-`.

    -foo --bar -verb -abc=baz -quux karl --quux xyz -- -myfile-

### 3.2 Common options ¶

All of these programs accept the standard GNU ‘`--help`’ and ‘`--version`’ options, and several programs accept ‘`--verbose`’. Rather than writing identical descriptions for every program, they are described here.

‘`--help`’ ¶

  Print a usage message listing basic usage and all available options to standard output, then exit successfully.

‘`--verbose`’ ¶

  Print progress reports to standard output.

‘`--version`’ ¶

  Print the version number to standard output, then exit successfully.

TeX, Metafont, and MetaPost have a number of additional options in common:

‘`-cnf-line=str`’ ¶

  Parse str as if it were a line in the `texmf.cnf` configuration file, overriding all other settings. See Path searching options in Kpathsea.

‘`-file-line-error`’ ¶
‘`-no-file-line-error`’

  Change (or do not change) the way error messages are printed. The alternate style looks like error messages from many compilers and is easier to parse for some editors that invoke TeX. This option used to be called ‘`-file-line-error-style`’.

‘`-fmt=dumpname`’ ¶
‘`-base=dumpname`’
‘`-mem=dumpname`’

  Use dumpname instead of the program name or a ‘`%&`’ line to determine the name of the memory dump file read (‘`fmt`’ for TeX, ‘`base`’ for Metafont, ‘`mem`’ for MetaPost). See Memory dumps. Also sets the program name to dumpname if no ‘`-progname`’ option was given.

‘`-halt-on-error`’ ¶

  Stop processing and exit when an error occurs, as opposed to the normal process of trying to recover and continue.

‘`-ini`’ ¶

  Enable the “initial” form of the program (see Initial and virgin). This is implicitly set if the program name is `initex` resp. `inimf`.

‘`-interaction=string`’ ¶

  Set the interaction mode from the command line. The string must be one of ‘`batchmode`’, ‘`nonstopmode`’, ‘`scrollmode`’, or ‘`errorstopmode`’.

‘`-jobname=string`’ ¶

  Set the job name to string, instead of deriving it from the name of the input file.

‘`-kpathsea-debug=number`’ ¶

  Set path searching debugging flags according to the bits of number (see Debugging in Kpathsea). You can also specify this in `KPATHSEA_DEBUG` environment variable (for all Web2c programs). (The command line value overrides.) The most useful value is ‘`-1`’, to get all available output.

‘`-output-directory=dirname`’ ¶

  Specify the directory dirname to which output files are written. Also look for input files in dirname first, before looking along the normal search path. Input files are only looked for as specified; no default extension is added. See Output file location.

‘`-parse-first-line`’ ¶
‘`-no-parse-first-line`’

  Check or disable checking whether the first line of the main input file starts with ‘`%&`’, and parse it if it does. This line can be used specify the format and/or a TCX file.

‘`-progname=string`’ ¶

  Set program (and memory dump) name to string. This may affect the search paths and other values used (see Config files in Kpathsea). Using this option is equivalent to making a link named string to the binary and then invoking the binary under that name. See Memory dumps.

‘`-recorder`’ ¶

  Enable the filename recorder. This makes the program save a list of the opened files into a file with (by default) extension ‘`.fls`’. For Aleph, this option is always on, and the file has extension ‘`.ofl`’.

  Ordinarily, the ‘`.fls`’ file is written to the same location as the ‘`.log`’ file, for example, respecting `-output-directory` if it is given (see Output file location). However, if TeX processing is done on the command line (or in response to the ‘`**`’ prompt), the ‘`.fls`’ might be written to the current directory, or include an integer (the current pid), as in `texput1234.fls`. You can use `-jobname` to explicitly set the basename.

‘`-translate-file=tcxfile`’ ¶

  Use tcxfile to define which characters are printable and translations between the internal and external character sets. Moreover, tcxfile can be explicitly declared in the first line of the main input file ‘`%& -translate-file=tcxfile`’. This is the recommended method for portability reasons. See TCX files: Character translations.

‘`-8bit`’ ¶

  This option specifies that by default all characters should be considered printable. If ‘`-translate-file`’ was given as well, then the TCX file may mark characters as non-printable. This is a no-op in engines natively supporting Unicode.

### 3.3 Path searching ¶

All of the Web2c programs, including TeX, which do path searching use the Kpathsea routines to do so. The precise names of the environment and configuration file variables which get searched for particular file formatted are therefore documented in the Kpathsea manual (see Supported file formats in Kpathsea). Reading `texmf.cnf` (see Config files in Kpathsea), invoking `mktex…` scripts (see mktex scripts in Kpathsea), and so on are all handled by Kpathsea.

The programs which read fonts make use of another Kpathsea feature: `texfonts.map`, which allows arbitrary aliases for the actual names of font files; for example, ‘`Times-Roman`’ for ‘`ptmr8r.tfm`’. The distributed (and installed by default) `texfonts.map` includes aliases for many widely available PostScript fonts by their PostScript names.

### 3.4 Output file location ¶

All the programs generally follow the usual convention for output files; namely, they are placed in the directory current when the program is run, regardless of any input file location; or, in a few cases, output is to standard output. The main programs (TeX, Metafont, MetaPost) provide several ways to override this, as explained below.

For example, if you run ‘`tex /tmp/foo`’, by default the output will be in `./foo.dvi` and `./foo.log`, not `/tmp/foo.dvi` and `/tmp/foo.log`.

An explicitly-given output location is also checked for input files, as TeX often generates files that need to be subsequently read. For input, the input filename is simply checked as given. No suffixes, such as ‘`.tex`’, are added by default, and no exhaustive path searching is done.

#### Override 1: ‘`-output-directory`’ option ¶

If the ‘`-output-directory`’ option is specified, all output files that would normally be written in the current directory are written in the specified directory instead. See Common options.

#### Override 2: `TEXMF_OUTPUT_DIRECTORY` environment variable ¶

Furthermore, if the ‘`-output-directory`’ option is specified, its argument is saved in the environment variable `TEXMF_OUTPUT_DIRECTORY`. This is for the benefit of any subprograms that might be called via `\write18` (see Shell escapes), such as `kpsewhich` (see Invoking kpsewhich in Kpathsea). (This feature was added in TeX Live 2024.)

If the ‘`-output-directory`’ option is not specified, but the environment variable `TEXMF_OUTPUT_DIRECTORY` is set, then the environment variable value is used just as if it had been given to the option.

Warning: we most strongly recommend always setting `TEXMF_OUTPUT_DIRECTORY` temporarily, for a given run. It has great potential for confusion, since with it set, output files will not be in the expected place. To reduce this chance somewhat, `TEXMF_OUTPUT_DIRECTORY` must be set in the environment, not a configuration file.

#### Override 3: `TEXMFOUTPUT` environment variable ¶

Finally, if neither ‘`-output-directory`’ nor `TEXMF_OUTPUT_DIRECTORY` is set, and an output file is not writable, then the main programs (TeX, Metafont, MetaPost), plus BibTeX for this one case, make an exception: if the config file or environment variable value `TEXMFOUTPUT` is set (it is not by default), the output file is written to the directory specified. Usually this is because the current directory is not writable, and thus all output files are written to `TEXMFOUTPUT`, but technically it works on a file-by-file basis.

None of these explicitly-given output locations are checked until (and unless) the program needs to write a file. For example, the invocation
`tex --output-directory=/nonesuch \\end`
won’t generate an error until TeX tries to write the log file:
‘`! I can't write on file `texput.log'.`’.

## 4 Three programs: Metafont, MetaPost, and TeX ¶

TeX, Metafont, and MetaPost have a number of features in common. Besides the ones here, command-line options and other commonalities are described in the previous section.

### 4.1 Runtime options ¶

Besides the configure- and compile-time options described in the installation section (see Installation), you can control a number of parameters in the `texmf.cnf` runtime file read by Kpathsea (see Config files in Kpathsea).

The main purpose of `texmf.cnf` is to specify search paths, but array sizes and other options are also set there. Most are rather obscure. Here are a few of the more interesting values:

‘`main_memory`’ ¶

  Total words of memory available, for TeX, Metafont, and MetaPost. Must remake the format file after changing.

‘`extra_mem_bot`’ ¶

  Extra space for “large” TeX data structures (default 0): boxes, glue, breakpoints, et al. If you use PiCTeX, you may well want to set this.

‘`expand_depth`’ ¶

  Limit on recursive expansion calls before TeX aborts (default 10000). If a TeX program does an unterminated recursive expansion, TeX will dutifully expand macros until the system’s runtime stack overflows, typically with a segmentation fault (SIGSEGV). This parameter was introduced to minimize the chance of that unpleasant (though not dangerous) crash, instead allowing TeX to quit with a more informative message.

  The crash can still happen, though, if the system has an exceptionally small memory allocation for its stack. There is no quantitative way to determine the limit, and it does not seem worth implementing system-dependent heuristics to guess at the number, since it’s highly improbable that any real TeX code will ever need more than 10000 recursive expansions (it has never happened). For the same reason, using the libsigsegv library (https://gnu.org/s/libsigsegv) does not seem worth the effort.

‘`texmf_casefold_search`’ ¶

  See Casefolding search in Kpathsea.

Ideally all arrays would be dynamically expanded as necessary, so the only limiting factor would be the amount of swap space available, or some configurable limit much larger than can currently be supported.

Unfortunately, implementing this is extremely difficult, as the fixed size of arrays is assumed in many places throughout the source code. These runtime limits are a practical compromise between the compile-time limits in previous versions, and truly dynamic arrays. (On the other hand, the Web2c BibTeX implementation does do true dynamic reallocation of some arrays.)

Nowadays there is rarely a reason to modify the values. But if you do wish to modify `texmf.cnf`, in TeX Live the best approach is to put your changes, and only your changes at the top of the TL installation tree. That is, if the system `texmf.cnf` is installed in `/some/path/to/texlive/YYYY/texmf-dist/web2c/texmf.cnf` is put your custom settings in `/some/path/to/texlive/YYY/texmf.cnf`, where YYYY is the year of installation (if you use that subdirectory; it’s the default). That way, unrelated changes to the system `texmf.cnf` can happen with normal updates, without affecting your local values.

### 4.2 Initial and virgin ¶

The TeX and Metafont programs each have two main variants, called initial and virgin. MetaPost no longer makes this distinction.

The initial form is enabled if:

1. the ‘`-ini`’ option was specified; or
2. the program name is `initex` resp. `inimf`; or
3. the first line of the main input file is ‘`%&ini`’;

otherwise, the virgin form is used.

The virgin form is the one generally invoked for production use. The first thing it does is read a memory dump (see Determining the memory dump to use), and then proceeds on with the main job.

The initial form is generally used only to create memory dumps (see the next section). It starts up more slowly than the virgin form, because it must do lengthy initializations that are encapsulated in the memory dump file.

### 4.3 Memory dumps ¶

In typical use, TeX and Metafont require a large number of macros to be predefined; therefore, they support memory dump files, which can be read much more efficiently than ordinary source code.

#### 4.3.1 Creating memory dumps ¶

The programs both create memory dumps in slightly idiosyncratic (thought substantially similar) way, so we describe the details in separate sections (references below). The basic idea is to run the initial version of the program (see Initial and virgin), read the source file to define the macros, and then execute the `\dump` primitive.

Also, each program uses a different filename extension for its memory dumps, since although they are completely analogous they are not interchangeable (TeX cannot read a Metafont memory dump, or vice versa).

Here are the filename extensions with references to examples of creating memory dumps:

TeX

  (‘`.fmt`’) See Initial TeX.

Metafont

  (‘`.base`’) See Initial Metafont.

MetaPost used to have an equivalent memory dump, called ‘`.mem`’, but no longer uses this; it now reads only source files.

When making memory dumps, the programs read environment variables and configuration files for path searching and other values as usual. If you are making a new installation and have environment variables pointing to an old one, for example, you will probably run into difficulties.

#### 4.3.2 Determining the memory dump to use ¶

The virgin form (see Initial and virgin) of each program always reads a memory dump before processing normal source input. All three programs determine the memory dump to use in the same way:

1. If the first non-option command-line argument begins with ‘`&`’, the program uses the remainder of that argument as the memory dump name. For example, running ‘`tex \&super`’ reads `super.fmt`. The backslash merely protects the ‘`&`’ against interpretation by the shell; quotes could also be used. TeX must see only the ‘`&`’.
2. If the ‘`-fmt`’ resp. ‘`-base`’ option is specified, its value is used.
3. If the ‘`-progname`’ option is specified, its value is used.
4. If the first line of the main input file (which must be specified on the command line, not in response to the ‘`**`’ prompt) is `%&dump`, and dump is an existing memory dump of the appropriate type, dump is used.

   The first line of the main input file can also specify which character translation file is to be used: `%&-translate-file=tcxfile` (see TCX files: Character translations).

   These two roles can be combined: `%&dump -translate-file=tcxfile`. If this is done, the name of the dump must be given first.

5. Otherwise, the program uses the program invocation name, most simply `tex` resp. `mf`. For example, if `latex` is a link to `tex`, and the user runs ‘`latex foo`’, `latex.fmt` will be used.

#### 4.3.3 Hardware and memory dumps ¶

By default, most memory dump files are sharable among architectures of different types; specifically, among machines of different endianness (see Byte order in GNU C Library) and with different word sizes (4-byte `long` vs. 8-byte `long`). This is a feature of the Web2c implementation, and is not true of all TeX implementations.

However, with the advent of Lua as an embedded scripting language, some dumps have become unportable, namely `lualatex`, `optex`, and `context`. These formats precompile Lua code into bytecode, which is architecture-specific for the sake of speed. With TeX Live, if you need to support multiple architectures with the same tree, you can explicitly set `TEXMFSYSVAR` to different directories on the different systems. More discussion: https://github.com/latex3/latex2e/issues/775.

The script `tl-check-fmtshare` in the TeX Live source tree (`Master/tlpkg/bin`) provides a relatively easy way to test that a `.fmt` built on the local host can be loaded by a TeX engine built on some remote host.

If you specify ‘`--disable-dump-share`’ to `configure`, however, memory dumps will be endian-dependent. The reason to do this is speed. To achieve endian-independence, the reading of memory dumps on LittleEndian architectures, such as PC’s and DEC architectures, is somewhat slowed (all the multibyte values have to be swapped). Usually, this is not noticeable, and the advantage of being able to share memory dumps across all platforms at a site outweighs the speed loss. But if you’re trying to squeeze out every possible bit of performance, you may wish to do this.

TeXnically, even without ‘`--disable-dump-share`’, sharing of `.fmt` files cannot be guaranteed to work. Floating-point values are always written in native format, and hence will generally not be readable across platforms. Fortunately, TeX uses floating point only to represent glue ratios, and none of the common formats (plain, LaTeX, AMSTeX, …) do any glue setting at `.fmt`-creation time. Metafont does not use floating point in any dumped value at all.

Different memory dump files will never compare equal byte-for-byte, because the programs dump the current date and time. So don’t be alarmed by this difference.

If you don’t know what endianness your machine is, and you’re curious, here is a little C program to tell you. (The `configure` script contains a similar program.) This is from the book C: A Reference Manual, by Samuel P. Harbison and Guy L. Steele Jr. (see References).

    main ()
    {
      /* Are we little or big endian?  From Harbison&Steele.  */
      union
      {
        long l;
        char c[sizeof (long)];
      } u;
      u.l = 1;
      if (u.c[0] == 1)
        printf ("LittleEndian\n");
      else if (u.c[sizeof (long) - 1] == 1)
        printf ("BigEndian\n");
      else
        printf ("unknownEndian");

      exit (u.c[sizeof (long) - 1] == 1);
    }

You can add `printf("long %d\n", sizeof(long));` to see the size of the `long` data type.

### 4.4 Editor invocation ¶

TeX, Metafont, and MetaPost all (by default) stop and ask for user intervention at an error. If the input came from a file, and the user responds with `e` or `E`, the program invokes an editor.

Specifying ‘`--with-editor=cmd`’ to `configure` sets the default editor command string to cmd. The environment variables/configuration values `TEXEDIT`, `MFEDIT`, and `MPEDIT` (respectively) override this. If ‘`--with-editor`’ is not specified, the default is `vi +%d %s` on Unix, and an invocation of the TeXworks editor on Windows. (See `texmf.cnf` for the precise values.)

In this string, ‘`%d`’ is replaced by the line number of the error, and ‘`%s`’ is replaced by the name of the current input file.

### 4.5 `\input` filenames ¶

TeX, Metafont, and MetaPost source programs can all read other source files with the `\input` (TeX) and `input` (MF and MP) primitives:

    \input name % in TeX

The file name can always be terminated with whitespace; for Metafont and MetaPost, the statement terminator ‘`;`’ also works. (LaTeX and other macro packages provide other interfaces to `\input` that allow different notation; here we are concerned only with the primitive operation.)

As an extension to standard TeX (allowed by Knuth’s conditions), Web2c also supports specifying the filename in double quotes (`"some name"`) and in a group, i.e., braces (`{some name}`), which is convenient for filenames containing spaces or other special characters, as described in the sections below.

In all cases, space tokens are ignored after the filename is read.

Also, double quote (`"`) characters are ignored within the filename; there is no way to read files whose names contain a `"`.

For maximal portability of your document across systems, use only the characters ‘`a`’–‘`z`’, ‘`0`’–‘`9`’, and at most one ‘`.`’. Do not use anything but simple filenames, since directory separators vary among systems; instead, add the necessary directories to the appropriate search path.

#### 4.5.1 `\input` quoted filename: `\input "some name"` ¶

As of Web2c version 7.5.3 (2004), double-quote characters can be used to include spaces or other special characters. In typical use, the ‘`"`’ characters surround the entire filename:

    \input "filename with spaces"

Technically, the quote characters can be used inside the name, and can enclose any characters, as in:

    \input filename" "with" "spaces

One more point. In LaTeX, the quotes are needed inside the braces of its `\input` macro, thus:

    \input{a b}    % fails
    \input{"a b"}  % ok

There is no way to quote the quote character.

#### 4.5.2 `\input` braced filename: `\input{some name}` ¶

As of Web2c 2020, `\input` filenames in TeX engines (this does not apply in Metafont and MetaPost) can also be specified within a TeX group, typically curly braces. For example:

    \input{filename with spaces}

As always with TeX, the brace characters are not hardwired; what counts is the category code: the first token after the `\input` must be of catcode 1 (begin group), and it is matched with the next character of catcode 2 (end group).

Within the group-delimited filename, braces are treated as normal characters.

As with all forms of filenames, following spaces are ignored (after the end group), and double quote (`"`) characters are ignored within the filename.

#### 4.5.3 `\input` filename caveats ¶

The quoting mechanisms just described come into play after TeX has tokenized and expanded the input. So, multiple spaces and tabs will generally be seen as a single space, active characters such as ‘`~`’ are expanded first (generally causing an error), and so on. More examples below.

Various C library routines and Unix itself use the null byte (character code zero, ASCII NUL) to terminate strings. So filenames in Web2c cannot contain nulls, even though TeX itself does not treat NUL specially.

Windows reserves a long list of alphanumeric filenames, case-insensitive and with any extension, such as ‘`CON`’, ‘`NUL`’, ‘`COM1`’, ‘`con.tex`’, etc.; see Windows systems documentation for the whole list. Trying to use such names will cause a system error on Windows.

Finally, the present Web2c implementation does ‘`~`’ and ‘`$`’ expansion on name, on all platforms, unlike Knuth’s original program. Thus:

    \input ~jsmith/$foo.bar

will dereference the environment variable or Kpathsea config file value ‘`foo`’ and read that file, extended with ‘`.bar`’, in user ‘`jsmith`’’s home directory. You can also use braces in the variable expansion, as in ‘`${foo}bar`’, if you want to follow the variable name with a letter, numeral, or ‘`_`’.

(So, another way to get a program to read a filename containing whitespace is to define an environment variable and dereference it.)

In all the common TeX formats (plain TeX, LaTeX, ConTeXt, …), the characters ‘`~`’ and ‘`$`’ have special category codes, so to use them within a document you have to change their catcodes or use `\string`.

## 5 TeX: Typesetting ¶

TeX is a typesetting system: it was especially designed to handle complex mathematics, as well as most ordinary text typesetting.

TeX is a batch language, like C or Pascal, and not an interactive “word processor”: you compile a TeX input file into a corresponding device-independent (DVI) file (and then translate the DVI file to the commands for a particular output device). This approach has both considerable disadvantages and considerable advantages. For a complete description of the TeX language, see The TeXbook (see References). Many other books on TeX, introductory and otherwise, are available.

### 5.1 `tex` invocation ¶

TeX (usually invoked as `tex`) formats the given text and commands, and outputs a corresponding device-independent representation of the typeset document. This section merely describes the options available in the Web2c implementation. For a complete description of the TeX typesetting language, see The TeXbook (see References).

TeX, Metafont, and MetaPost process the command line (described here) and determine their memory dump (fmt) file in the same way (see Memory dumps). Synopses:

    tex [option]... [texname[.tex]] [more-input]
    tex [option]... \more-input
    tex [option]... &fmt first-line

In short, TeX prepends `\input` to non-option command line arguments or the input to the ‘`**`’ prompt, and then processes the result as normal TeX input, including expansion.

The most common invocation is ‘`tex somefile`’, which reads ‘`somefile.tex`’, normally from the current directory. It is equivalent to `\input somefile`.

In more detail:

TeX searches the usual places for the main input file texname (see Supported file formats in Kpathsea), extending texname with `.tex` if necessary. To see all the relevant paths, set the environment variable `KPATHSEA_DEBUG` to ‘`-1`’ before running the program.

After texname is read, TeX processes any remaining more-input on the command line as regular TeX input. Also, if the first non-option argument begins with a TeX escape character (usually `\`), TeX processes all non-option command-line arguments as a line of regular TeX input. The backslash or other escape character usually has to be escaped to avoid being processed by your shell.

If no arguments or options are specified, TeX prompts for an input filename with ‘`**`’. Whatever input is given in response to ‘`**`’ is processed exactly like a command line not starting with an escape character, i.e., `\input` is prepended and then the entire line is processed as normal TeX intput.

Thus, the text of an input filename, as well as any text following a filename, is subject to TeX’s normal macro expansion. As a result, a ‘`~`’ character is normally not usable within a filename, since by default ‘`~`’ is defined (in plain TeX, LaTeX, etc.) to be an active character that expands into several primitive tokens that can’t be part of a filename. As a special case in Web2c, a ‘`~`’ beginning a filename refers to a user’s home directory (see `\input` filename caveats), but you still have to arrange for TeX to see a ‘`~`’ character rather than the expansion of ‘`~`’.

To summarize the usual cases (in all these cases, `tex` also reads `tex.fmt` before starting any processing):

- ‘`tex foo`’ executes ‘`\input foo`’.
- ‘`tex foo bar`’ executes ‘`\input foo bar`’, which inputs `foo.tex` and then typesets ‘`bar`’.
- ‘`tex \\end`’ executes ‘`\end`’; here the double backslash is one common way of escaping the backslash for the shell. TeX only sees one backslash.
- ‘`tex`’ with no arguments prints a ‘`**`’ prompt. Entering ‘`foo bar`’ at the ‘`**`’ prompt again executes ‘`\input foo`’ and typesets ‘`bar`’.

TeX writes its main output, a DVI file, to `basetexname.dvi`, where basetexname is the basename of texname, or ‘`texput`’ if no input file was specified.

A DVI file is a device-independent binary representation of your document. You can translate the DVI file, using independent programs, to whatever may be needed, such as a PDF file (see dvipdfmx(1)), a PostScript file (see Introduction in Dvips), an SVG file (see dvisvgm(1)), etc. There are also variants of TeX that can produce PDF files directly, namely pdfTeX and LuaTeX (see Extended TeX engines).

The program accepts the following options, as well as the standard ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-enc`’
‘`-[no]-file-line-error`’
‘`-fmt=fmtname`’
‘`-halt-on-error`’
‘`-ini`’
‘`-interaction=string`’
‘`-ipc`’
‘`-ipc-start`’
‘`-jobname=string`’
‘`-kpathsea-debug=number`’
‘`-[no]parse-first-line`’
‘`-output-directory`’
‘`-progname=string`’
‘`-recorder`’
‘`-translate-file=tcxfile`’
‘`-8bit`’

  These options are common to TeX, Metafont, and MetaPost. See Common options.

‘`-enc`’ ¶

  Enable encTeX extensions, such as `\mubyte`. This can be used to support the Unicode UTF-8 input encoding, although using an engine with native Unicode support is more common nowadays. http://www.olsak.net/enctex.html.

‘`-ipc`’ ¶
‘`-ipc-start`’

  With either option, TeX writes its DVI output to a socket as well as to the usual `.dvi` file. With ‘`-ipc-start`’, TeX also opens a server program at the other end to read the output. See IPC and TeX.

  These options are available only if the ‘`--enable-ipc`’ option was specified to `configure` during installation of Web2c.

‘`-mktex=filetype`’ ¶
‘`-no-mktex=filetype`’

  Turn on or off the ‘`mktex`’ script associated with filetype. For TeX proper, filetype can only be ‘`tex`’ and ‘`tfm`’, but for pdfTeX and LuaTeX, it can also be ‘`pk`’.

‘`-mltex`’ ¶

  If we are `INITEX` (see Initial and virgin), enable MLTeX extensions such as `\charsubdef`. Implicitly set if the program name is `mltex`. See MLTeX.

‘`-output-comment=string`’ ¶

  Use string as the DVI file comment. Ordinarily, this comment records the date and time of the TeX run, but if you are doing regression testing, you may not want the DVI file to have this spurious difference. This is also taken from the environment variable and config file value ‘`output_comment`’.

‘`-shell-escape`’ ¶
‘`-no-shell-escape`’
‘`-shell-restricted`’

  Enable, or disable, or enable with restrictions the `\write18{shell-command}` feature for external execution of shell commands. See Shell escapes.

‘`-enable-write18`’ ¶
‘`-disable-write18`’

  Synonyms for `-shell-escape` and `-no-shell-escape`, for compatibility with MiKTeX. (MiKTeX also accepts both pairs of options.) See Shell escapes.

‘`-src-specials`’ ¶
‘`-src-specials=string`’

  This option makes TeX output specific source information using ‘`\special`’ commands in the DVI file. These ‘`\special`’ track the current filename and line number.

  Using the first form of this option, the ‘`\special`’ commands are inserted automatically.

  In the second form of the option, string is a comma separated list of the following values: ‘`cr`’, ‘`display`’, ‘`hbox`’, ‘`math`’, ‘`par`’, ‘`parend`’, ‘`vbox`’. You can use this list to specify where you want TeX to output such commands. For example, ‘`-src-specials=cr,math`’ will output source information every line and every math formula.

  These commands can be used with the appropriate DVI viewer and text editor to switch from the current position in the editor to the same position in the viewer and back from the viewer to the editor.

  This option works by inserting ‘`\special`’ commands into the token stream, and thus in principle these additional tokens can be recovered or seen by the tricky-enough macros. If you run across a case, let us know, because this counts as a bug. However, such bugs are very hard to fix, requiring significant changes to TeX, so please don’t count on it.

  Redefining ‘`\special`’ will not affect the functioning of this option. The commands inserted into the token stream are hard-coded to always use the ‘`\special`’ primitive.

  TeX does not pass the `TRIP` test when this option is enabled.

Other input and output that can happen:

- TeX also reads TFM files for any fonts you load in your document with the `\font` primitive. By default, it runs an external program named `mktextfm` to create any nonexistent TFM files. You can disable this at configure-time or runtime (see mktex configuration in Kpathsea).
- TeX can write output files, via the `\openout` primitive. This raises the possibility of a Trojan horse attack: an unwitting user could run a TeX program that overwrites, say, `$HOME/.ssh/authorized_keys`. (MetaPost has a `write` primitive with similar implications.)

  To alleviate this and similar problems, the functions `kpathsea_out_name_ok` and `kpathsea_in_name_ok` from the Kpathsea library (see Calling sequence in Kpathsea) are used to determine if a given filename is acceptable to be opened for output or input, depending on the setting of the configuration variables `openout_any` and `openin_any`: ‘`a`’ (for “any”, the default for `openin_any`), ‘`r`’ (for “restricted”), or ‘`p`’ (for “paranoid”, the default for `openout_any`).

  In any case, all `\openout` filenames are recorded in the log file, except those opened on the first line of input, which is processed before the log file has been opened.

### 5.2 Initial TeX ¶

The initial form of TeX is invoked by ‘`tex -ini`’. It does lengthy initializations avoided by the “virgin” (`vir`) form, so as to be capable of dumping ‘`.fmt`’ files (see Memory dumps). For a detailed comparison of virgin and initial forms, see Initial and virgin.

For a list of options and other information, see `tex` invocation.

Unlike Metafont and MetaPost, many format files are commonly used with TeX. The standard one implementing the features described in The TeXbook is ‘`plain.fmt`’, also known as ‘`tex.fmt`’ (again, see Memory dumps). It is created by default during installation, but you can also do so by hand if necessary:

    tex -ini '\input plain \dump'

(The quotes prevent interpretation of the backslashes from the shell.) Then put the resulting `plain.fmt` where TeX will find it, and link `tex.fmt` to it. Any existing `tex.fmt` can be found with the invocation:

    kpsewhich --all --engine=/ tex.fmt

See Formats, for more details on TeX formats.

### 5.3 Formats ¶

TeX formats are large collections of macros, often dumped into a `.fmt` file (see Memory dumps) by `tex -ini` (see Initial TeX). A number of formats are in reasonably widespread use. The formats are generally selected, installed, and updated as part of a larger TeX distribution, such as TeX Live (https://tug.org/texlive).

`latex` ¶

  The most widely used format, called LaTeX, based on LaTeX2e and also incorporating LaTeX3; new versions are released approximately every six months, with patches issued as needed. The old release was called ‘LaTeX 2.09’, and is no longer maintained or supported, though compatibility for 2.09 documents is retained. LaTeX attempts to provide generic markup instructions, such as “emphasize”, instead of specific typesetting instructions, such as “use the 10pt Computer Modern italic font”. The LaTeX home page: https://www.latex-project.org.

`latex-dev` ¶

  A set of formats and executables made so that anyone interested can easily help test upcoming LaTeX releases. They correspond to new formats which have been tested by the LaTeX team for stability and usability. Testing by as many users as possible is desired and requested. Simply changing the regular engine name (e.g., `pdflatex`), to have a `-dev` suffix (`pdflatex-dev`) in your invocations is all that should be needed. No changes to source documents should be required.

`context` ¶

  ConTeXt is an independent macro package which also supports a document structuring approach. It can also create interactive PDF files and has an integrated MetaPost library for graphics, among many other advanced features. It uses its own engine, LuaMetaTeX, developed in tandem. The ConTeXt home page: http://www.pragma-ade.com.

`eplain` ¶

  An “expanded plain” format that provides various common features (e.g., symbolic cross-referencing, tables of contents, indexing, citations using BibTeX), for those authors who prefer to handle their own high-level formatting. The Eplain home page: https://tug.org/eplain.

`texinfo` ¶

  The documentation system developed and maintained by the Free Software Foundation for their software manuals. It can be automatically converted into HTML, plain text, a machine-readable online format called Info, etc. The Texinfo home page: https://www.gnu.org/software/texinfo.

`amstex` ¶

  This was the official typesetting system of the American Mathematical Society; nowadays, the AMS recommends authors use LaTeX; the AMS provides a number of LaTeX packages important for math typesetting. The AMS’s TeX page: https://www.ams.org/tex.

`slitex` ¶

  An obsolete LaTeX 2.09 format for making slides. In core LaTeX2e, it is replaced by the ‘`slides`’ document class. As of 2025, the ‘`ltx-talk`’ class is also provided for typesetting presentations, including accessibility support: https://ctan.org/pkg/ltx-talk. The ‘`beamer`’ package is perhaps the most commonly used method for making slides nowadays: https://ctan.org/pkg/beamer.

### 5.4 Languages and hyphenation ¶

TeX supports most natural languages. See also TeX extensions.

#### 5.4.1 MLTeX: Multi-lingual TeX ¶

Multi-lingual TeX (`mltex`) is an extension of TeX originally written by Michael Ferguson and now updated and maintained by Bernd Raichle. With the advent of Unicode, it has become obsolete, though it is still supported in Web2c in the event of bugs or compilation bugs.

MLTeX allows the use of non-existing glyphs in a font by declaring glyph substitutions. These are restricted to substitutions of an accented character glyph, which need not be defined in the current font, by its appropriate `\accent` construction using a base and accent character glyph, which do have to exist in the current font. This substitution is automatically done behind the scenes, if necessary, and thus MLTeX additionally supports hyphenation of words containing an accented character glyph for fonts missing this glyph (e.g., Computer Modern). Standard TeX suppresses hyphenation in this case.

MLTeX works at `.fmt`-creation time: the basic idea is to specify the ‘`-mltex`’ option to TeX when you `\dump` a format. Then, when you subsequently invoke TeX and read that `.fmt` file, the MLTeX features described below will be enabled.

Generally, you use special macro files to create an MLTeX `.fmt` file.

The sections below describe the two new primitives that MLTeX defines. Aside from these, MLTeX is completely compatible with standard TeX.

#### 5.4.1.1 `\charsubdef`: Character substitutions ¶

The most important primitive MLTeX adds is `\charsubdef`, used in a way reminiscent of `\chardef`:

    \charsubdef composite [=] accent base

Each of composite, accent, and base are font glyph numbers, expressed in the usual TeX syntax: ``\e` symbolically, `'145` for octal, `"65` for hex, `101` for decimal.

MLTeX’s `\charsubdef` declares how to construct an accented character glyph (not necessarily existing in the current font) using two character glyphs (that do exist). Thus it defines whether a character glyph code, either typed as a single character or using the `\char` primitive, will be mapped to a font glyph or to an `\accent` glyph construction.

For example, if you assume glyph code 138 (decimal) for an e-circumflex and you are using the Computer Modern fonts, which have the circumflex accent in position 18 and lowercase ‘e’ in the usual ASCII position 101 decimal, you would use `\charsubdef` as follows:

    \charsubdef 138 = 18 101

For the plain TeX format to make use of this substitution, you have to redefine the circumflex accent macro `\^` in such a way that if its argument is character ‘e’ the expansion `\char138` is used instead of `\accent18 e`. Similar `\charsubdef` declaration and macro redefinitions have to be done for all other accented characters.

To disable a previous `\charsubdef c`, redefine c as a pair of zeros. For example:

    \charsubdef '321 = 0 0  % disable N tilde

(Octal `'321` is the ISO Latin-1 value for the Spanish N tilde.)

`\charsubdef` commands should only be given once. Although in principle you can use `\charsubdef` at any time, the result is unspecified. If `\charsubdef` declarations are changed, usually either incorrect character dimensions will be used or MLTeX will output missing character warnings. (The substitution of a `\charsubdef` is used by TeX when appending the character node to the current horizontal list, to compute the width of a horizontal box when the box gets packed, and when building the `\accent` construction at `\shipout`-time. In summary, the substitution is accessed often, so changing it is not desirable, nor generally useful.)

#### 5.4.1.2 `\tracingcharsubdef`: Substitution diagnostics ¶

To help diagnose problems with ‘`\charsubdef`’, MLTeX provides a new primitive parameter, `\tracingcharsubdef`. If positive, every use of `\charsubdef` will be reported. This can help track down when a character is redefined.

In addition, if the TeX parameter `\tracinglostchars` is 100 or more, the character substitutions performed at `\shipout`-time will be recorded.

#### 5.4.2 TCX files: Character translations ¶

TCX (TeX character translation) files help TeX support direct input of 8-bit international characters if fonts containing those characters are being used. Specifically, they map an input (keyboard) character code to the internal TeX character code (a superset of ASCII).

Of the various proposals for handling more than one input encoding, TCX files were chosen because they follow Knuth’s original ideas for the use of the ‘`xchr`’ and ‘`xord`’ tables. He ventured that these would be changed in the WEB source in order to adjust the actual version to a given environment. It turns out, however, that recompiling the WEB sources is not as simple a task as Knuth may have imagined; therefore, TCX files, providing the possibility of changing of the conversion tables on on-the-fly, have been implemented instead.

This approach limits the portability of TeX documents, as some implementations do not support it (or use a different method for input-internal reencoding). It may also be problematic to determine the encoding to use for a TeX document of unknown provenance; in the worst case, failure to do so correctly may result in subtle errors in the typeset output. But we feel the benefits outweigh these disadvantages.

This is entirely independent of the MLTeX extension (see MLTeX: Multi-lingual TeX): whereas a TCX file defines how an input keyboard character is mapped to TeX’s internal code, MLTeX defines substitutions for a non-existing character glyph in a font with a `\accent` construction made out of two separate character glyphs. TCX files involve no new primitives; it is not possible to specify that an input (keyboard) character maps to more than one character.

Information on specifying TCX files:

- The best way to specify a TCX file is to list it explicitly in the first line of the main document:

      %& -translate-file=tcxfile

- You can also specify a TCX file to be used on a particular TeX run with the command-line option ‘`-translate-file=tcxfile`’.
- TCX files are searched for along the `WEB2C` path.
- Initial TeX (see Initial TeX) ignores TCX files.

The Web2c distribution comes with a number of TCX files. Two important ones are `il1-t1.tcx` and `il2-t1.tcx`, which support ISO Latin 1 and ISO Latin 2, respectively, with Cork-encoded fonts (a.k.a. the LaTeX T1 encoding). TCX files for Czech, Polish, and Slovak are also provided.

One other notable TCX file is `empty.tcx`, which is, well, empty. Its purpose is to reset Web2C’s behavior to the default (only visible ASCII being printable, as described below) when a format was dumped with another TCX being active—which is in fact the case for everything but plain TeX in the TeX Live and other distributions. Thus:

    latex somefile8.tex
    ⇒ terminal etc. output with 8-bit chars
    latex --translate-file=empty.tcx somefile8.tex
    ⇒ terminal etc. output with ^^ notation

Syntax of TCX files:

1. Line-oriented. Blank lines are ignored.
2. Whitespace is ignored except as a separator.
3. Comments start with ‘`%`’ and continue to the end of the line.
4. Otherwise, a line consists of one or two character codes, optionally followed by 0 or 1. The last number indicates whether dest is considered printable.

       src [dest [prnt]]

5. Each character code may be specified in octal with a leading ‘`0`’, hexadecimal with a leading ‘`0x`’, or decimal otherwise. Values must be between 0 and 255, inclusive (decimal).
6. If the dest code is not specified, it is taken to be the same as src.
7. If the same src code is specified more than once, it is the last definition that counts.

Finally, here’s what happens: when TeX sees an input character with code src, it 1) changes src to dest; and 2) makes the dest code “printable”, i.e., printed as-is in diagnostics and the log file rather than in ‘`^^`’ notation.

By default, no characters are translated, and character codes between 32 and 126 inclusive (decimal) are printable.

Specifying translations for the printable ASCII characters (codes 32–127) will yield unpredictable results. Additionally you shouldn’t make the following characters printable: `^^I` (TAB), `^^J` (line feed), `^^M` (carriage return), and `^^?` (delete), since TeX uses them in various ways.

Thus, the idea is to specify the input (keyboard) character code for src, and the output (font) character code for dest.

By default, only the printable ASCII characters are considered printable by TeX. If you specify the ‘`-8bit`’ option, all characters are considered printable by default. If you specify both the ‘`-8bit`’ option and a TCX file, then the TCX can set specific characters to be non-printable.

Both the specified TCX encoding and whether characters are printable are saved in the dump files (like `tex.fmt`). So by giving these options in combination with ‘`-ini`’, you control the defaults seen by anyone who uses the resulting dump file.

When loading a dump, if the ‘`-8bit`’ option was given, then all characters become printable by default.

When loading a dump, if a TCX file was specified, then the TCX data from the dump is ignored and the data from the file used instead.

#### 5.4.3 Patgen: Creating hyphenation patterns ¶

Patgen creates hyphenation patterns from dictionary files for use with TeX. Synopsis:

    patgen dictionary patterns output translate

Each argument is a filename. No path searching is done. The output is written to the file output.

In addition, Patgen prompts interactively for other values.

For more information, see Word hy-phen-a-tion by com-put-er by Frank Liang (see References), and also the `patgen.web` source file.

The only options are ‘`-help`’ and ‘`-version`’ (see Common options).

### 5.5 Shell escapes ¶

TeX can execute shell escapes, that is, arbitrary shell commands. Although tremendously useful, this also has obvious security implications. Therefore, as of TeX Live 2009, a restricted mode for shell escapes is the default mode of operation, which allows executing only certain commands, as specified in the `texmf.cnf` configuration file.

- Unrestricted shell escapes are allowed if the option `--shell-escape` is specified, or if the environment variable or config file value `shell_escape` is set to ‘`t`’ or ‘`y`’ and ‘`1`’.
- Restricted shell escapes are allowed if `shell_escape` is set to ‘`p`’. This is the default.
- Shell escapes are completely disabled if `--no-shell-escape` is specified, or if `shell_escape` is set to anything else.

When enabled, the TeX construct to execute a system command is `\write18{shell-command}`; for example:

    \write18{echo "hello, world"}

From TeX’s point of view, this is a normal `\write` command, and is therefore subject to the usual TeX expansions. Also, the system call either happens during the ‘`\output`’ routine or right away, according to the absence or presence of the `\immediate` prefix, as usual for `\write`.

The shell-command string is passed to the command shell (via the C library function `system`). The output of shell-command is not diverted anywhere, so it will not appear in the log file, or anywhere but the terminal output. The exit status of the system call is also not available to TeX.

In unrestricted mode, the argument is simply passed straight to `system` unaltered.

In restricted mode, ASCII double quote characters (`"`) should always be used in the argument to `\write18` where quoting of arguments is needed, as in the example above. This is to achieve some measure of system independence. On Unix systems, these are replaced with single quote (`'`) characters to avoid insecure further expansion (from, e.g., ``...``). Care is also taken on Windows to avoid additional expansions. Mismatched quotation marks in the command string result in a diagnostic message in the log file, and no execution is performed.

After quotation processing, if the first word (delimited by a space or tab) of the command is in the list specified by the `shell_escape_commands` configuration value, the command is executed. Otherwise it is not. In any case, a message is written to the log file.

The `shell_escape_commands` value is a comma-separated list of words. Whitespace is significant, and typically should not be present. The default definition in `texmf.cnf` looks like this, with more commands included:

    shell_escape_commands = bibtex,kpsewhich,repstopdf,...

pdfTeX and LuaTeX support reading (via `\input` and `\openin`) and writing (via `\openout`) from pipes if the first character is ‘`|`’. The following command is then treated exactly the same as the argument to `\write18`. In these engines, the primitive variable `\pdfshellescape` is set to 0 if shell escapes are disabled, 1 if they are enabled, and 2 if they are enabled with restrictions.

The purpose of this feature is to make it possible for TeX documents to perform useful external actions in the common case of an individual user running a known document on his or her own machine. In environments such as CGI scripts or wikis where the input has to be considered untrustworthy, shell escapes should be completely disabled.

Programs intended to be called from TeX in restricted should implement the “paranoid” safety measures regarding output files that TeX itself does. See Calling sequence in Kpathsea.

### 5.6 IPC and TeX ¶

(If anyone uses this feature and needs documentation, write tex-k@tug.org.)

This functionality is available only if the ‘`--enable-ipc`’ option was specified to `configure` during installation of Web2c (see Installation).

If you define `IPC_DEBUG` before compilation (e.g., with ‘`make XCFLAGS=-DIPC_DEBUG`’), TeX will print messages to standard error about its socket operations. This may be helpful if you are, well, debugging.

### 5.7 Extended TeX engines ¶

The base TeX program has been extended in many ways.

There has been a substantial effort to make a set of extended functionality available across all actively-updated engines, so that formats, notably LaTeX, can rely on it. A list of this common extended functionality is in a LaTeX News article, https://www.latex-project.org/news/latex2e-news/ltnews31.pdf. For engines in TeX Live, the detailed documentation for these primitives is mostly in the pdfTeX manual (https://pdftex.org).

In addition, each engine (naturally) has its own particular features, described in its own manual. Here’s a partial list of the engines.

e-TeX ¶

  Adds many new primitives, including right-to-left typesetting and more registers. Now frozen. More info: https://ctan.org/pkg/etex.

Aleph ¶

  This adds Unicode support, right-to-left typesetting, and more, based on the Omega engine, with the e-TeX and other extensions. Aleph is maintained only for serious bug fixes and does not include the common functionality mentioned above. More info: https://ctan.org/pkg/aleph, https://ctan.org/pkg/omega.

pdfTeX ¶

  Can produce PDF as well as DVI files. It also incorporates the e-TeX extensions, new primitives for hypertext and micro-typography, reading/writing from pipes, and much more. In TeX Live, the command `etex` invokes pdfTeX to make all these additions available with DVI output. Home page: https://pdftex.org.

LuaTeX ¶

  Embeds the Lua programming language (http://lua.org) and opens up the TeX typesetting engine to control from Lua, starting from the pdfTeX capabilities as a base. Also natively supports UTF-8 input, the OpenType and TrueType font formats, and use of system fonts. Home page: https://luatex.org.

XeTeX ¶

  Combines support for Unicode input, the OpenType and TrueType font formats, and use of system fonts with the capabilities of pdfTeX, with the exception of the font expansion part of micro-typography. Home page: https://tug.org/xetex.

hiTeX ¶

  Outputs its own HINT format, which is designed for reading technical documents on mobile devices. More info: https://ctan.org/pkg/hitex.

pTeX ¶
upTeX

  With additional support for Japanese; pTeX was the original engine, and upTeX has native Unicode support and thus is more useful for Chinese and Korean. More info: https://ctan.org/pkg/ptex, https://ctan.org/pkg/uptex.

epTeX ¶
eupTeX

  Further extends pTeX and upTeX with the e-TeX extensions. More info: https://ctan.org/pkg/eptex, https://ctan.org/pkg/euptex.

## 6 Metafont: Creating typeface families ¶

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 References).

### 6.1 `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 References).

Metafont processes its command line and determines its memory dump (base) file in a way exactly analogous to MetaPost and TeX (see `tex` invocation, and see 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 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 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 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 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

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 Common options):

‘`-[no]-file-line-error`’
‘`-fmt=fmtname`’
‘`-halt-on-error`’
‘`-ini`’
‘`-interaction=string`’
‘`-jobname=string`’
‘`-kpathsea-debug=number`’
‘`-[no]parse-first-line`’
‘`-output-directory`’
‘`-progname=string`’
‘`-recorder`’
‘`-translate-file=tcxfile`’
‘`-8bit`’

  These options are common to TeX, Metafont, and MetaPost. See Common options.

‘`-mktex=filetype`’ ¶
‘`-no-mktex=filetype`’

  Turn on or off the ‘`mktex`’ script associated with filetype. The only value that makes sense for filetype is ‘`mf`’.

### 6.2 Initial Metafont ¶

`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 Memory dumps). For a detailed comparison of virgin and initial forms, see Initial and virgin.

For a list of options and other information, see `mf` invocation.

The only memory dump file commonly used with Metafont is the default ‘`plain.base`’, also known as ‘`mf.base`’ (again, see Memory dumps). It is created by default during installation, but you can also do so by hand if necessary:

    mf -ini '\input plain; input modes; dump'

(The quotes prevent interpretation of the backslashes from the shell.) Then install the resulting `plain.base` where Metafont will find it, and link `mf.base` to it.

For an explanation of the additional `modes.mf` file, see 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 developing a typeface with Metafont may find it worthwhile to create their own base file.

### 6.3 Modes: Device definitions for Metafont ¶

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 `modes.mf` (https://ctan.org/pkg/modes); 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@math.utah.edu 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 `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.

### 6.4 Online Metafont graphics ¶

The Web2c implementation of Metafont can do online graphics with a number of devices. (See The Metafontbook for more information about how to draw on your screen.) The default graphics support is determined at compile time.

The two Kpathsea configuration variables `screen_width` and `screen_depth` define the width and height of the window used by Metafont. They can be set in the environment or a Kpathsea configuration file (see path sources in kpathsea). They default to 1664 and 1200, respectively.

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. Some devices are system-specific and not always available.

If `MFTERM` is not set, but the `DISPLAY` environment variable is set (to a valid X server specification like ‘`:0`’), the Metafont window support for X is used, assuming it was detected and included at compile time.

Here is a table of the possibilities, showing the `MFTERM` value and the corresponding `configure` option(s) in parentheses.

`amiga` ¶

  (‘`--enable-amigawin`’) Amiga systems.

`epsf` ¶

  (‘`--enable-epsfwin`’) Pseudo-window server for Encapsulated PostScript (see `web2c/window/epsf.c`). This device produces an EPS file containing the graphics which would be displayed online on other devices. The name of the EPS file defaults to metafont.eps but can be changed by setting the MFEPSF environment variable to the new filename. Contributed by Mathias Herberts.

`hp2627` ¶

  (‘`--enable-hp2627win`’) HP2627a color graphics terminals.

`mftalk` ¶

  (‘`--enable-mftalkwin`’) Generic window server (see `web2c/window/mftalk.c`).

`next` ¶

  (‘`--enable-nextwin`’) NeXT window system. This requires a separate program, called `DrawingServant`, available separately. See the `web2c/window/next.c`.

`regis` ¶

  (‘`--enable-regiswin`’) Regis terminals.

`sun` ¶

  (‘`--enable-suntoolswin`’) The old Suntools (not any flavor of X) window system. (You can get the even older SunWindows `gfx` system with `sun-gfx.c`.)

`tek` ¶

  (‘`--enable-tektronixwin`’) Tektronix terminals.

`uniterm` ¶

  (‘`--enable-unitermwin`’) Uniterm, Simon Poole’s emulator of a smart Tektronix 4014 terminal. This may work with regular Tektronix terminals as well; it’s faster than the driver ‘`--enable-tektronixwin`’ selects.

`win32win` ¶

  Microsoft Windows.

`xterm` ¶

  ‘`--with-x`’ The X window system (version 11).

  There are two variants of the X11 support, one that works with the Xt toolkit (`X11-Xt.c`), and another that works directly with Xlib (`X11-Xlib.c`). If `--with-mf-x-toolkit` is specified when building Metafont, the Xt version is used, else Xlib.

  Specify ‘`--disable-mf-nowin`’ in order not to build a separate non-windows-capable Metafont executable `mf-nowin`.

  You cannot specify any of the usual X options (e.g., ‘`-geometry`’) on the Metafont command line, but you can specify X resources in your `~/.Xdefaults` or `~/.Xresources` file. The class name is `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`).

### 6.5 GFtoDVI: Character proofs of fonts ¶

GFtoDVI makes proof sheets from a GF bitmap file as output by, for example, Metafont (see 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 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:

- gray font (default `gray`): for the pixels that make up the character. Simply using black is not right, since then labels, key points, and other information could not be shown.
- title font (default `cmr8`): for the header information at the top of each output page.
- label font (default `cmtt10`): for the labels on key points of the figure.
- slant font (no default): for diagonal lines, which are otherwise simulated using horizontal and vertical rules.

To change the default fonts, you must use `special` commands in your Metafont source file, typically via commands like `slantfont slantlj4`. There is no default slant font since no one printer is suitable as a default. You can make your own by copying one of the existing files, such as `.../fonts/source/public/misc/slantlj4.mf` and then running `mf` on it.

For testing purposes, you may it useful to run `mf-nowin rtest` (hit RETURN when it stops) to get a `gf` file of a thorn glyph. Or use `mf` instead of `mf-nowin` to have the glyph(s) displayed on the screen. After that, `gftodvi rtest.2602gf` should produce `rtest.dvi`, which you process as usual.

The program accepts the following option, as well as the standard ‘`-verbose`’, ‘`-help`’, and ‘`-version`’ (see Common options):

‘`-overflow-label-offset=points`’ ¶

  Typeset the so-called overflow labels, if any, points TeX points from the right edge of the character bounding box. The default is a little over two inches (ten million scaled points, to be precise). Overflow equations are used to locate coordinates when their actual position is too crowded with other information.

### 6.6 MFT: Prettyprinting Metafont source ¶

MFT translates a Metafont or MetaPost program into a TeX document suitable for typesetting. Synopsis:

    mft [option]... sourcename[.mf|.mp]

MFT searches the usual places for sourcename (see 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 sourcename extended with `.tex`, e.g., ‘`mft /wherever/foo.mf`’ creates `./foo.tex`.

The output uses the TeX macros defined in the file `mftmac.tex` (for Metafont) or `mptmac.tex` (for MetaPost).

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 comments:

- Metafont/MetaPost comments following a single ‘`%`’ should be valid TeX input. But Metafont/MetaPost source material can be included within vertical bars in a comment; this will be translated by MFT as if it were regular code. For example, a Metafont comment like ‘`% |x2r| is the tip of the bowl`’ will be translated into the TeX ‘`% $x_{2r}$ is the …`’, i.e., the ‘`x2r`’ is treated as an identifier.
- ‘`%%`’ indicates that the remainder of an input line should be copied verbatim to the output. This is typically used to introduce additional TeX material at the beginning or an MFT job, e.g. code to modify the standard layout or the formatting macros defined in `mftmac.tex`, or to add a line saying ‘`%%\bye`’ at the end of the job. (MFT doesn’t add this automatically in order to allow processing several files produces by MFT in the same TeX job.)
- ‘`%%% token1 other-tokens`’ introduces a change in MFT’s formatting rules; all the other-tokens will henceforth be translated according to the current conventions for token1. The tokens must be symbolic (i.e., not numeric or string tokens). For example, the input line

      %%% addto fill draw filldraw

  says 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.

- ‘`%%%%`’ introduces an MFT comment, i.e., MFT ignores the remainder of such a line.
- Five or more ‘`%`’ signs should not be used.

(The above description was based on that in `mft.web`, written by Donald Knuth.)

The program accepts the following options, as well as the standard ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-change=chfile[.ch]`’ ¶

  Apply the change file chfile as with Tangle and Weave (see WEB: Literate programming).

‘`-metapost`’ ¶

  Force interpretation of the input as MetaPost; this is the default of the filename extension is ‘`.mp`’.

‘`-style=mftfile[.mft]`’ ¶

  Read mftfile before anything else; a MFT style file typically contains only MFT directives as described above. The default style file is `plain.mft` (for Metafont) or `mplain.mft` (for MetaPost). MFT files are searched along the `MFTINPUTS` path (see 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.

## 7 MetaPost: Generating PostScript ¶

MetaPost is a picture-drawing language similar to Metafont (see Metafont: Creating typeface families), but instead of outputting bitmaps in a “font”, it outputs PostScript commands. It’s primarily intended for creating technical illustrations, but can also be used to create PostScript or OpenType fonts (https://ctan.org/pkg/metatype1).

MetaPost also provides for arbitrary integration of text and graphics in a natural way, using any typesetter (TeX and Troff are both supported) and a number of other subsidiary programs, described below.

### 7.1 `mpost` invocation ¶

MetaPost (installed as `mpost`) reads a series of pictures specified in the MetaPost programming language, and outputs corresponding PostScript code. This section merely describes the options available in the Web2c implementation. For a complete description of the MetaPost language, see AT&T technical report CSTR-162, generally available in `texmf/doc/metapost/`, where texmf is the root of TeX directory structure. The MetaPost home page: https://tug.org/metapost.

Also, a standard MetaPost package for drawing graphs is documented in AT&T technical report CSTR-164, available as the file `mpgraph.ps`, generally stored alongside `mpman.ps`.

MetaPost processes its command line in a way analogous to Metafont and TeX (see `tex` invocation). Synopses:

    mpost [option]... [mpname[.mp]] [mp-commands]
    mpost [option]... \first-line
    mpost [option]... &mem args

MetaPost searches the usual places for the main input file mpname (see Supported file formats in Kpathsea), extending mpname with `.mp` if necessary. To see all the relevant paths, set the environment variable `KPATHSEA_DEBUG` to ‘`-1`’ before running the program.

MetaPost writes its PostScript output to a series of files `basempname.nnn` (or perhaps `basempname.ps`, very occasionally `basempname.tfm`), where nnn are the figure numbers specified in the input, typically to the `beginfig` macro, and basempname is the basename of mpname, or ‘`mpout`’ if no input file was specified. MetaPost uses the ‘`.ps`’ extension when the figure number is out of range, e.g., if you say `beginfig(-1)`.

You can use the output files as figures in a TeX document just as with any other PostScript figures. For example, with this TeX command:

    \special{psfile="filename"}

or by using `epsf.tex` (see EPSF macros in Dvips).

The MetaPost construct

    btex ... tex-input ... etex

generates a MetaPost picture expression corresponding to tex-input.

The construct

    verbatimtex ... tex-input ... etex

simply passes the tex-input through to TeX. For example, if you are using LaTeX, your MetaPost input file must start with a `verbatimtex` block that gives the necessary `\documentclass` (or `\documentstyle`) `\begin{document}` command. You will also need to set the environment variable `TEX` to ‘`latex`’.

tex-input need not be specifically TeX input; it could also be Troff. In that case, you will need the ‘`-m pictures`’ Troff macro package (unfortunately absent from many Troff implementations), or an equivalent such as the ‘`-m pspic`’ macros from GNU groff described in grops(1).

Naturally, you must use fonts that are supported by the typesetter; specifically, you’ll probably want to use standard PostScript fonts with Troff. And only the TeX system understands Computer Modern or other Metafont fonts; you can also use PostScript fonts with TeX, of course.

MetaPost-generated PostScript figures which do use Computer Modern fonts for labels cannot be directly previewed or printed. Instead, you must include them in a TeX document and run the resulting DVI file through Dvips to arrange for the downloading of the required fonts (see Fonts in figures in Dvips). To help with this, the MetaPost distribution provides a small TeX file `mproof.tex` which is typically called as:

    tex mproof mp-output-files... ; dvips mproof -o

The resulting file `mproof.ps` can then be printed or previewed.

To generate EPSF files, set the internal MetaPost variable `prologues` positive. To make the output files self-contained, use only standard PostScript fonts. MetaPost reads the same `psfonts.map` file as Dvips, to determine PostScript fonts that need to be downloaded (see psfonts.map in Dvips).

It is possible for pdfTeX to read MetaPost output directly; this is in contrast to general EPSF files, which have to be converted for use with PDF output. The easiest way is to name the MetaPost output files with the `.mps` extension. Then the LaTeX `\includegraphics` command, for example, will be able to read them, even when outputting PDF.

MetaPost can write output files, via the `write` primitive; this opens a security hole. See `tex` invocation.

The program accepts the following options, as well as the standard ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-[no]-file-line-error`’
‘`-halt-on-error`’
‘`-ini`’
‘`-interaction=string`’
‘`-jobname=string`’
‘`-kpathsea-debug=number`’
‘`-[no]parse-first-line`’
‘`-output-directory`’
‘`-progname=string`’
‘`-recorder`’
‘`-translate-file=tcxfile`’
‘`-8bit`’

  These options are common to TeX, Metafont, and MetaPost. See Common options.

‘`-debug`’ ¶

  Print debugging information and leave temporary files in place.

‘`-mem=MPFILE`’ ¶

  Preload MPFILE instead of via the program name of `%&` line. This is a MetaPost source file; MetaPost no longer has binary mem files.

‘`-numbersystem=string`’ ¶

  Set number system mode where string is one of: `scaled double binary interval decimal`.

‘`-restricted`’ ¶

  Be secure: disable the `tex`, `makempx` and editor commands.

‘`-s internal=value`’ ¶

  Set INTERNAL to VALUE, a string or integer.

‘`-T`’ ¶
‘`-troff`’

  Set the `prologues` internal variable to `1`.

‘`-tex=texprogram`’ ¶

  When this option is given, the program texprogram is used to typeset the labels.

### 7.2 Initial MetaPost ¶

As of MetaPost 1.504 (TeX Live 2011), MetaPost no longer dumps `.mem` files (see Memory dumps) and does not distinguish virgin and initial forms (see Initial and virgin). Instead, the “initial” file name is read in its source form—that is, `mpost.mp` when the program is invoked as `mpost`. This is considered to be “preloading” the source.

For a list of options and other information, see `mpost` invocation.

MetaPost provides a format with all the features of plain Metafont, called `mfplain`. You can use that in the same way; just run `mfplain` instead of `mpost`. This lets you directly process Metafont source files with MetaPost, producing character proofs (one file for each character) similar to those produced with Metafont in proof mode and GFtoDVI (see GFtoDVI: Character proofs of fonts).

### 7.3 DVItoMP: DVI to MPX conversion ¶

DVItoMP converts DVI files into low-level MetaPost commands in a so-called MPX file. Synopsis:

    dvitomp dvifile[.dvi] [mpxfile[.mpx]]

If mpxfile is not specified, the output goes to the basename of dvifile extended with `.mpx`, e.g., ‘`dvitomp /wherever/foo.dvi`’ creates `./foo.mpx`.

DVItoMP supports Dvips-style color specials, such as ‘`color push name`’ and ‘`color pop`’, outputting them as `withcolor` MetaPost commands.

The only options are ‘`-help`’ and ‘`-version`’ (see Common options).

## 8 BibTeX: Bibliographies ¶

BibTeX automates much of the job of typesetting bibliographies, and makes bibliography entries reusable in many different contexts.

### 8.1 BibTeX invocation ¶

BibTeX creates a printable bibliography (`.bbl`) file from references in a `.aux` file, generally written by TeX or LaTeX. The `.bbl` file is then incorporated on a subsequent run. The basic bibliographic information comes from `.bib` files, and a BibTeX style (`.bst`) file controls the precise contents of the `.bbl` file. Synopsis:

    bibtex [option]... auxfile[.aux]

The output goes to the basename of auxfile extended with `.bbl`; for example, ‘`bibtex /wherever/foo.aux`’ creates `./foo.bbl`. BibTeX also writes a log file to the basename of auxfile extended with ‘`.blg`’.

The names of the `.bib` and `.bst` files are specified in the `.aux` file as well, via the `\bibliography` and `\bibliographystyle` (La)TeX macros. BibTeX searches for `.bib` files using the `BIBINPUTS` and `TEXBIB` paths, and for `.bst` files using `BSTINPUTS` (see Supported file formats in Kpathsea). It does no path searching for `.aux` files.

The program accepts the following options, as well as the standard ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-terse`’ ¶

  Suppress the program banner and progress reports normally output.

‘`-min-crossrefs=n`’ ¶

  If at least n (2 by default) bibliography entries refer to another entry e via their `crossref` field, include e in the `.bbl` file, even if it was not explicitly referenced in the `.aux` file. For example, e might be a conference proceedings as a whole, with the cross-referencing entries being individual articles published in the proceedings.

  If you want to avoid these automatic inclusions altogether, make n a sufficiently large number, and be sure to remove any previous `.aux` and `.bbl` files. Otherwise the option may appear to have no effect, since BibTeX will have added the citation for e to the `.aux`, and nothing will remove it.

See also:

`btxdoc.tex` ¶

  Basic LaTeXable documentation for general BibTeX users.

`btxhak.tex` ¶

  LaTeXable documentation for style designers.

`btxdoc.bib` ¶

  BibTeX database file for the two above documents.

`xampl.bib` ¶

  Example database file with all the standard entry types.

`ftp://ftp.math.utah.edu/pub/tex/bib/` ¶

  A very large `.bib` and `.bst` collection, including references for all the standard TeX books and a complete bibliography for TUGboat.

### 8.2 Basic BibTeX style files ¶

Here are descriptions of the four standard and four semi-standard basic BibTeX styles. `CTAN:/biblio/bibtex` contains these and many more (for CTAN info, see unixtex.ftp in Kpathsea).

`plain` ¶

  Sorts entries alphabetically, with numeric labels. Generally formatted according to van Leunen’s A Handbook for Scholars. The other style files listed here are based on `plain`.

`abbrv` ¶

  First names, month names, and journal names are abbreviated.

`acm` ¶

  Names are printed in small caps.

`alpha` ¶

  Alphanumeric labels, e.g., ‘`Knu66`’.

`apalike` ¶

  No labels at all; instead, the year appears in parentheses after the author. Use this in conjunction with `apalike.tex` (plain TeX) or `apalike.sty` (LaTeX), which also changes the citations in the text to be ‘`(author, year)`’.

`ieeetr` ¶

  Numeric labels, entries in citation order, IEEE abbreviations, article titles in quotes.

`siam` ¶

  Numeric labels, alphabetic order, Math. Reviews abbreviations, names in small caps.

`unsrt` ¶

  Lists entries in citation order, i.e., unsorted.

`btxbst.doc`

  The template file and documentation for the standard styles.

## 9 WEB: Literate programming ¶

WEB languages allow you to write a single source file that can produce both a compilable program and a well-formatted document describing the program in as much detail as you wish to prepare. Writing in this kind of dual-purpose language is called literate programming. (The Usenet newsgroup `comp.programming.literate` is devoted to this subject.)

WEB-like languages have been implemented with many pairs of base languages: Cweb provides C and Troff (see References); CWEB provides C and TeX (`CTAN:/web/c_cpp/cweb`); Spiderweb provides C, C++, Awk, Ada, many others, and TeX (`CTAN:/web/spiderweb`); and, of course, the original WEB provides Pascal and TeX, the implementation languages for the original TeX, Metafont, MetaPost, and related programs to come from the TeX project at Stanford.

Knuth’s original WEB language is documented in the file `webman.tex`, available as a formatted pdf in the `knuth-pdf` page (https://ctan.org/pkg/knuth-pdf).

### 9.1 Tangle: Translate WEB to Pascal ¶

Tangle creates a compilable Pascal program from a WEB source file (see WEB: Literate programming). Synopsis:

    tangle [option]... webfile[.web] [changefile[.ch]]

The Pascal output is written to the basename of webfile extended with ‘`.p`’; for example, ‘`tangle /wherever/foo.web`’ creates `./foo.p`. Tangle applies changefile to webfile before writing the output; by default, there is no change file.

If the program makes use of the WEB string facility, Tangle writes the string pool to the basename of webfile extended with ‘`.pool`’.

The Pascal output is packed into lines of 72 characters or less, with the only concession to readability being the termination of lines at semicolons when this can be done conveniently.

The program accepts the following options, as well as the standard ‘`--help`’ and ‘`--version`’ (see Common options):

‘`-length=number`’ ¶

  The number of characters that are considered significant in an identifier. Whether underline characters are counted depends on the ‘`-underline`’ option. The default value is 32, the original tangle used 7, but this proved too restrictive for use by Web2c.

‘`-lowercase`’ ¶
‘`-mixedcase`’
‘`-uppercase`’

  These options specify the case of identifiers in the output of tangle. If ‘`-uppercase`’ (‘`-lowercase`’) is specified, tangle will convert all identifiers to uppercase (lowercase). The default is ‘`-mixedcase`’, which specifies that the case will not be changed.

‘`-underline`’ ¶

  When this option is given, tangle does not strip underline characters from identifiers.

‘`-loose`’ ¶
‘`-strict`’

  These options specify how strict tangle must be when checking identifiers for equality. The default is ‘`-loose`’, which means that tangle will follow the rules set by the case-smashing and underline options above. If ‘`-strict`’ is set, then identifiers will always be stripped of underlines and converted to uppercase before checking whether they collide.

### 9.2 Weave: Translate WEB to TeX ¶

Weave creates a TeX document from a WEB source file (see WEB: Literate programming), assuming various macros defined in `webmac.tex`. It takes care of typographic details such as page layout, indentation, and italicizing identifiers. It also automatically gathers and outputs extensive cross-reference information. Synopsis:

    weave [option]... webfile[.web] [changefile[.ch]]

The output is to the basename of webfile extended with ‘`.tex`’; for example, ‘`weave /wherever/foo.web`’ creates `./foo.tex`. Weave applies changefile to webfile before writing the output; by default, there is no change file.

The Web2c version of Weave accepts 8-bit characters as themselves. This can cause trouble with various internal WEB control codes, and should not be relied on.

The program accepts the following option, as well as the standard ‘`-verbose`’, ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-x`’ ¶

  Omit the cross-reference information: the index, the list of WEB module names, and the table of contents (an empty `CONTENTS.tex` file will still be written when the Weave output file is processed by TeX using the default `webmac.tex`, though).

Conventionally, WEB programmers should define the TeX `\title` macro at the beginning of the source file. Also, to get output of only changed modules, one can say `\let\maybe=\iffalse` (usually as the first change in the change file).

### 9.3 Pooltype: Display WEB pool files ¶

Pooltype shows the so-called string number of each string in a WEB pool file (see WEB: Literate programming), as output by Tangle (see Tangle: Translate WEB to Pascal), including the first 256 strings corresponding to the possible input characters. Pooltype primarily serves as an example of WEB conventions to implementors of the TeX system. Synopsis:

    pooltype [option]... poolfile[.pool]

No path searching is done for poolfile. Output is to standard output.

The only options are ‘`--help`’ and ‘`--version`’ (see Common options).

As an example of the output, here is the (edited) output for `tex.pool`:

    0: "^^@"
    1: "^^A"
    ...
    255: "^^ff"
    256: "pool size"
    ...
    1314: "Using character substitution: "
    (23617 characters in all.)

In Metafont and MetaPost, the first 256 characters are represented as single bytes (i.e., themselves), not in the ‘`^^`’ notation. Thus, Pooltype shows the results after conversion for output.

## 10 DVI utilities ¶

TeX outputs a file in DVI (DeVice Independent) format as a compact representation of the original document. DVI files can be translated to meet the requirements of a real physical device, such as PostScript printers (see Introduction in Dvips), PCL printers (see dvilj(1)), and X displays (see xdvi(1)). In fact, DVI translators are available for virtually all common devices: see `CTAN:/dviware` (for CTAN info, see unixtex.ftp in Kpathsea).

For the precise definition of the DVI file format, see (for example) the source file `web2c/dvitype.web`.

The DVI-processing programs in the Web2c distribution are not device drivers; they perform generic utility functions.

### 10.1 DVIcopy: Canonicalize virtual font references ¶

DVIcopy reads a DVI file, expands any references to virtual fonts (see Virtual fonts in Dvips) to base fonts, and writes the resulting DVI file. Thus you can use virtual fonts even if your DVI processor does not support them, by passing the documents through DVIcopy first. Synopsis:

    dvicopy [option]... [indvi[.dvi] [outdvi[.dvi]]]

DVIcopy reads standard input if indvi is not specified, and writes standard output if outdvi is not specified.

The program accepts the following options, as well as the standard ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-magnification=integer`’ ¶

  Override existing magnification in indvi with integer; 1000 specifies no magnification. This is equivalent to setting TeX’s `\mag` parameter.

‘`-max-pages=n`’ ¶

  Process n pages; default is one million.

‘`-page-start=page-spec`’ ¶

  Start at the first page matching page-spec, which is one or more (signed) integers separated by periods, corresponding to TeX’s `\count0…9` parameters at `\shipout` time; ‘`*`’ matches anything. Examples: ‘`3`’, ‘`1.*.-4`’.

### 10.2 DVItype: Plain text transliteration of DVI files ¶

DVItype translates a DeVice Independent (DVI) file (as output by TeX, for example) to a plain text file that humans can read. It also serves as a DVI-validating program, i.e., if DVItype can read a file, it’s correct. Synopsis:

    dvitype [option]... dvifile[.dvi]

DVItype does not read any bitmap files, but it does read TFM files for fonts referenced in dvifile. The usual places are searched (see Supported file formats in Kpathsea). To see all the relevant paths, set the environment variable `KPATHSEA_DEBUG` to ‘`-1`’ before running the program.

Output goes to standard output.

The program accepts the following options, as well as the standard ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-dpi=real`’ ¶

  Do pixel movement calculations at real pixels per inch; default 300.0.

‘`-magnification=integer`’ ¶

  Override existing magnification in indvi with integer; 1000 specifies no magnification. This is equivalent to setting TeX’s `\mag` parameter.

‘`-max-pages=n`’ ¶

  Process n pages; default is one million.

‘`-output-level=n`’ ¶

  Verbosity level of output, from 0 to 4 (default 4):

  - 0: Global document information only.
  - 1: Most DVI commands included, and typeset characters summarized.
  - 2: Character and movement commands explicitly included.
  - 3: DVI stack and current position calculations included.
  - 4: Same information as level 3, but DVItype does random positioning in the file, reading the DVI postamble first.
‘`-page-start=page-spec`’ ¶

  Start at the first page matching page-spec, which is one or more (signed) integers separated by periods, corresponding to TeX’s `\count0…9` parameters at `\shipout` time; ‘`*`’ matches anything. Examples: ‘`1`’, ‘`5.*.-9`’.

‘`-show-opcodes`’ ¶

  Show numeric opcode values (in decimal) for DVI commands, in braces after the command name. This can help in debugging DVI utilities. We use decimal because in the DVI format documentation (in `dvitype.web`, among others) the opcodes are shown in decimal.

#### 10.2.1 DVItype output example ¶

As an example of the output from DVItype (see section above), here is its (abridged) translation of the `story.dvi` resulting from running the example in The TeXbook, with ‘`-output-level=4`’ and ‘`-show-opcodes`’ on.

    ...
    Options selected:
      Starting page = *
      Maximum number of pages = 1000000
      Output level = 4 (the works)
      Resolution = 300.00000000 pixels per inch
    numerator/denominator=25400000/473628672
    magnification=1000;       0.00006334 pixels per DVI unit
    ' TeX output 1992.05.17:0844'
    Postamble starts at byte 564.
    maxv=43725786, maxh=30785863, maxstackdepth=3, totalpages=1
    Font 33: cmsl10---loaded at size 655360 DVI units
    Font 23: cmbx10---loaded at size 655360 DVI units
    Font 0: cmr10---loaded at size 655360 DVI units

    42: beginning of page 1
    87: push {141}
    level 0:(h=0,v=0,w=0,x=0,y=0,z=0,hh=0,vv=0)
    88: down3 -917504 {159} v:=0-917504=-917504, vv:=-58
    92: pop {142}
    ...
    104: putrule {137} height 26214, width 30785863 (2x1950 pixels)
    113: down3 5185936 {159} v:=655360+5185936=5841296, vv:=370
    117: push {141}
    level 1:(h=0,v=5841296,w=0,x=0,y=0,z=0,hh=0,vv=370)
    118: right4 12265425 {146} h:=0+12265425=12265425, hh:=777
    [ ]
    123: fntdef1 23 {243}: cmbx10
    145: fntnum23 {194} current font is cmbx10
    146: setchar65 h:=12265425+569796=12835221, hh:=813
    147: w3 251220 {150} h:=12835221+251220=13086441, hh:=829
    151: setchar83 h:=13086441+418700=13505141, hh:=856
    ...
    164: setchar82 h:=17448202+565245=18013447, hh:=1142
    165: x0 -62805 {152} h:=18013447-62805=17950642, hh:=1138
    166: setchar89 h:=17950642+569796=18520438, hh:=1174
    [A SHORT STORY]
    167: pop {142}
    level 1:(h=0,v=5841296,w=0,x=0,y=0,z=0,hh=0,vv=370)
    ...
    550: pop {142}
    level 0:(h=0,v=42152922,w=0,x=0,y=0,z=0,hh=0,vv=2670)
    551: down3 1572864 {159} v:=42152922+1572864=43725786, vv:=2770
    555: push {141}
    level 0:(h=0,v=43725786,w=0,x=0,y=0,z=0,hh=0,vv=2770)
    556: right4 15229091 {146} h:=0+15229091=15229091, hh:=965
    561: setchar49 h:=15229091+327681=15556772, hh:=986
    [ 1]
    562: pop {142}
    level 0:(h=0,v=43725786,w=0,x=0,y=0,z=0,hh=0,vv=2770)
    563: eop {140}

Explanation:

- The DVItype options are recorded at the beginning, followed by global information about the document, including fonts used.
- Each DVI command is preceded by its byte position in the file (‘`42:`’, ‘`87:`’, …), and (because of the ‘`-show-opcodes`’) followed by its decimal opcode value in braces (‘`{141}`’, ‘`{142}`’, …).
- The ‘`level`’ lines record information about the DVI stack; ‘`h`’ and ‘`v`’ define the current position in DVI units, while ‘`hh`’ and ‘`vv`’ are the same in pixels.
- Text sequences are summarized in brackets, as in ‘`[A SHORT STORY]`’ and the ‘`[ 1]`’.

## 11 Font utilities ¶

The Web2c programs described here convert between various TeX-related font formats; the first section below briefly describes the formats. GFtoPK is the only one that is routinely used, as Metafont outputs GF format, but it’s most efficient for device drivers to use PK.

The precise definitions of the PK, GF, TFM, PL, VF, and VPL formats mentioned below are in the source files that read them; `pktype.web`, `gftype.web`, `tftopl.web`, etc.

### 11.1 Font file formats ¶

For another perspective on this, see Font concepts in Dvips.

Font files come in several varieties, with suffixes like:

    .tfm  .*pk  .*gf  .*pxl (obsolete)  .pl  .mf  .vf  .vpl

Each represents a file format.

A TFM (TeX font metric) file is a compact binary file that contains information about each character in a font, about combinations of characters within that font, and about the font as a whole. The font metric information contained in TFM files is device-independent units is used by TeX to do typesetting. Unlike the bitmap (raster) fonts described below, TFM font files contain no information about the shapes of characters. They describe rectangular areas and combinations thereof, but not what will eventually be printed in those areas.

Since TeX does scaling calculations, one TFM file serves for all magnifications of a given typeface. On the other hand, the best printed results are obtained when magnified (or reduced fonts) are not produced geometrically (as done by PostScript, for example) but rather optically, with each size a separate design (as done with Computer Modern and the EC fonts, for example); then a separate TFM file is needed for each size.

At any rate, TeX produces a DVI (DeVice Independent) file from your source document. In order to print DVI files on real devices, you need font files defining digitized character shapes and other data. Then previewers and printer-driver programs can translate your DVI files into something usable by your monitor or printer. Bitmap fonts come with suffixes such as ‘`.600pk`’ or ‘`.600gf`’ or ‘`.3000pxl`’, where the ‘`600`’ is the horizontal dots-per-inch resolution at which the font was produced, and the ‘`pk`’ or ‘`gf`’ or ‘`pxl`’ indicates the font format. Outline fonts in PostScript Type 1 format have suffixes such as ‘`.pfa`’ or ‘`.pfb`’.

Fonts in pk (packed) format are in the tightly packed raster format that is pretty much the standard today. They take up less space than fonts in the gf (generic font) format that Metafont generates, and far less space than fonts in pxl format. Fonts in pxl format take up gross amounts of disk space and permit only 128 characters. They are obsolete.

Font files with the ‘`.pl`’ (property list) suffix are the plain text (human-readable) analog of the binary ‘`.tfm`’ files. The TFtoPL and PLtoTF programs convert between the two formats (see TFtoPL: TeX font metric to property list conversion and PLtoTF: Property list to TeX font metric conversion).

Font files with the ‘`.mf`’ suffix are in Metafont source format. These are the files used by Metafont to generate rastered fonts for specific typefaces at specific magnifications for the specific resolution and type of mapping used by your device.

The suffix ‘`.vf`’ identifies “virtual font” files, for which ‘`.vpl`’ is the human-readable analog. See See VFtoVP: Virtual font to virtual property lists, and VPtoVF: Virtual property lists to virtual font. For further discussion of virtual fonts, see `CTAN:/doc/virtual-fonts.knuth`, `CTAN:/help/virtualfonts.txt`, and Virtual fonts in Dvips.

(This section is based on documentation in the original Unix TeX distribution by Pierre MacKay and Elizabeth Tachikawa.)

### 11.2 GFtoPK: Generic to packed font conversion ¶

GFtoPK converts a generic font (GF) file output by, for example, Metafont (see `mf` invocation) to a packed font (PK) file. PK files are considerably smaller than the corresponding gf files, so they are generally the bitmap font format of choice. Some DVI-processing programs, notably Dvips, only support PK files and not GF files. Synopsis:

    gftopk [option]... gfname.dpi[gf] [pkfile]

The font gfname is searched for in the usual places (see 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`.

If pkfile is not specified, the output is written to the basename of ‘`gfname.dpipk`’, e.g., ‘`gftopk /wherever/cmr10.600gf`’ creates `./cmr10.600pk`.

The only options are ‘`--verbose`’, ‘`--help`’, and ‘`--version`’ (see Common options).

### 11.3 PKtoGF: Packed to generic font conversion ¶

PKtoGF converts a packed font (PK) file to a generic font (GF) file. Since PK format is much more compact than GF format, the most likely reason to do this is to run GFtype (see GFtype: Plain text transliteration of generic fonts) on the result, so you can see the bitmap images. Also, a few old utility programs do not support PK format. Synopsis:

    pktogf [option]... pkname.dpi[pk] [gffile]

The font pkname is searched for in the usual places (see Glyph lookup in Kpathsea). To see all the relevant paths, set the environment variable `KPATHSEA_DEBUG` to ‘`-1`’ before running the program.

The suffix ‘`pk`’ is supplied if not already present. This suffix is not an extension; no ‘`.`’ precedes it: for instance, `cmr10.600pk`.

If gffile is not specified, the output is written to the basename of ‘`pkname.dpigf`’, e.g., ‘`pktogf /wherever/cmr10.600pk`’ creates `./cmr10.600gf`.

The only options are ‘`--verbose`’, ‘`--help`’, and ‘`--version`’ (see Common options).

### 11.4 PKtype: Plain text transliteration of packed fonts ¶

PKtype translates a packed font (PK) bitmap file (as output by GFtoPK, for example) to a plain text file that humans can read. It also serves as a PK-validating program, i.e., if PKtype can read a file, it’s correct. Synopsis:

    pktype pkname.dpi[pk]

The font pkname is searched for in the usual places (see Glyph lookup in Kpathsea). To see all the relevant paths, set the environment variable `KPATHSEA_DEBUG` to ‘`-1`’ before running the program.

The suffix ‘`pk`’ is supplied if not already present. This suffix is not an extension; no ‘`.`’ precedes it: for instance, `cmr10.600pk`.

The translation is written to standard output.

The only options are ‘`-help`’ and ‘`-version`’ (see Common options).

As an example of the output, here is the (abridged) translation of the letter ‘K’ in ‘`cmr10`’, as rendered at 600dpi with the mode ‘`ljfour`’ from `modes.mf` (https://ctan.org/pkg/modes).

    955:  Flag byte = 184  Character = 75  Packet length = 174
      Dynamic packing variable = 11
      TFM width = 815562  dx = 4259840
      Height = 57  Width = 57  X-offset = -3  Y-offset = 56
      [2]23(16)17(8)9(25)11(13)7(27)7(16)7(28)4(18)7(28)2(20)7(27)...
      ...
      (14)9(24)12(5)[2]23(13)21

Explanation:

‘`955`’ ¶

  The byte position in the file where this character starts.

‘`Flag byte`’ ¶
‘`Dynamic packing variable`’

  Related to the packing for this character; see the source code.

‘`Character`’ ¶

  The character code, in decimal.

‘`Packet length`’ ¶

  The total length of this character definition, in bytes.

‘`TFM width`’ ¶

  The device-independent (TFM) width of this character. It is 2^24 times the ratio of the true width to the font’s design size.

‘`dx`’ ¶

  The device-dependent width, in scaled pixels, i.e., units of horizontal pixels times 2^16.

‘`Height`’ ¶
‘`Width`’

  The bitmap height and width, in pixels.

‘`X-offset`’ ¶
‘`Y-offset`’

  Horizontal and vertical offset from the upper left pixel to the reference (origin) pixel for this character, in pixels (right and down are positive). The reference pixel is the pixel that occupies the unit square in Metafont; the Metafont reference point is the lower left hand corner of this pixel. Put another way, the x-offset is the negative of the left side bearing; the right side bearing is the horizontal escapement minus the bitmap width plus the x-offset.

‘`[2]23(16)…`’ ¶

  Finally, run lengths of black pixels alternate with parenthesized run lengths of white pixels, and brackets indicate a repeated row.

### 11.5 GFtype: Plain text transliteration of generic fonts ¶

GFtype translates a generic font (GF) bitmap file (as output by Metafont, for example) to a plain text file that humans can read. It also serves as a GF-validating program, i.e., if GFtype can read a file, it’s correct. Synopsis:

    gftype [option]... gfname.dpi[gf]

The font gfname is searched for in the usual places (see 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 translation is written to standard output.

The program accepts the following options, as well as the standard ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-images`’ ¶

  Show the characters’ bitmaps using asterisks and spaces.

‘`-mnemonics`’ ¶

  Translate all commands in the GF file.

As an example of the output, here is the (abridged) translation of the letter ‘K’ in ‘`cmr10`’, as rendered at 600dpi with the mode ‘`ljfour`’ from `modes.mf` (https://ctan.org/pkg/modes), with both ‘`-mnemonics`’ and ‘`-images`’ enabled.

GFtype outputs the information about a character in two places: a main definition and a one-line summary at the end. We show both. Here is the main definition:

    2033: beginning of char 75: 3<=m<=60 0<=n<=56
    (initially n=56) paint (0)24(12)20
    2043: newrow 0 (n=55) paint 24(12)20
    2047: newrow 0 (n=54) paint 24(12)20
    2051: newrow 0 (n=53) paint 24(12)20
    2055: newrow 7 (n=52) paint 10(21)13
    2059: newrow 8 (n=51) paint 8(23)9
    ...
    2249: newrow 8 (n=5) paint 8(23)11
    2253: newrow 7 (n=4) paint 10(22)12
    2257: newrow 0 (n=3) paint 24(11)22
    2261: newrow 0 (n=2) paint 24(11)22
    2265: newrow 0 (n=1) paint 24(11)22
    2269: newrow 0 (n=0) paint 24(11)22
    2273: eoc

    .<--This pixel's lower left corner is at (3,57) in METAFONT coordinates
    ************************            ********************
    ************************            ********************
    ************************            ********************
    ************************            ********************
           **********                     *************
            ********                       *********
    ...
            ********                       ***********
           **********                      ************
    ************************           **********************
    ************************           **********************
    ************************           **********************
    ************************           **********************
    .<--This pixel's upper left corner is at (3,0) in METAFONT coordinates

Explanation:

‘`2033`’ ¶
‘`2043`’
‘`…`’

  The byte position in the file where each GF command starts.

‘`beginning of char 75`’ ¶

  The character code, in decimal.

‘`3<=m<=60 0<=n<=56`’ ¶

  The character’s bitmap lies between 3 and 60 (inclusive) horizontally, and between 0 and 56 (inclusive) vertically. (m is a column position and n is a row position.) Thus, 3 is the left side bearing. The right side bearing is the horizontal escapement (given below) minus the maximum m.

‘`(initially n=56) paint (0)24(12)20`’ ¶

  The first row of pixels: 0 white pixels, 24 black pixels, 12 white pixels, etc.

‘`newrow 0 (n=55) paint 24(12)20`’ ¶

  The second row of pixels, with zero leading white pixels on the row.

‘`eoc`’ ¶

  The end of the main character definition.

Here is the GF postamble information that GFtype outputs at the end:

    Character 75: dx 4259840 (65), width 815562 (64.57289), loc 2033

Explanation:

‘`dx`’ ¶

  The device-dependent width, in scaled pixels, i.e., units of horizontal pixels times 2^16. The ‘`(65)`’ is simply the same number rounded. If the vertical escapement is nonzero, it would appear here as a ‘`dy`’ value.

‘`width`’ ¶

  The device-independent (TFM) width of this character. It is 2^24 times the ratio of the true width to the font’s design size. The ‘`64.57289`’ is the same number converted to pixels.

‘`loc`’

  The byte position in the file where this character starts.

### 11.6 TFtoPL: TeX font metric to property list conversion ¶

TFtoPL translates a TeX font metric (TFM, see Metric files in Dvips) file (as output by Metafont, for example) to property list format (a list of parenthesized items describing the font) that humans can edit or read. This program is mostly used by people debugging TeX implementations, writing font utilities, etc. Synopsis:

    tftopl [option]... tfmname[.tfm] [plfile[.pl]]

The font tfmname (extended with ‘`.tfm`’ if necessary) is searched for in the usual places (see Supported file formats in Kpathsea). To see all the relevant paths, set the environment variable `KPATHSEA_DEBUG` to ‘`-1`’ before running the program.

If plfile (which is extended with ‘`.pl`’ if necessary) is not specified, the property list file is written to standard output. The property list file can be converted back to TFM format by the companion program TFtoPL (see the next section).

The program accepts the following option, as well as the standard ‘`-verbose`’, ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-charcode-format=type`’ ¶

  Output character codes in the PL file according to type: either ‘`octal`’ or ‘`ascii`’. Default is ‘`ascii`’ for letters and digits, octal for all other characters. Exception: if the font’s coding scheme starts with ‘`TeX math sy`’ or ‘`TeX math ex`’, all character codes are output in octal.

  In ‘`ascii`’ format, character codes that correspond to graphic characters, except for left and right parentheses, are output as a ‘`C`’ followed by the single character: ‘`C K`’, for example. In octal format, character codes are output as the letter ‘`O`’ followed by octal digits, as in ‘`O 113`’ for ‘`K`’.

  ‘`octal`’ format is useful for symbol and other non-alphabetic fonts, where using ASCII characters for the character codes is merely confusing.

As an example of the output, here is the (abridged) property list translation of `cmr10.tfm`:

    (FAMILY CMR)
    (FACE O 352)
    (CODINGSCHEME TEX TEXT)
    (DESIGNSIZE R 10.0)
    (COMMENT DESIGNSIZE IS IN POINTS)
    (COMMENT OTHER SIZES ARE MULTIPLES OF DESIGNSIZE)
    (CHECKSUM O 11374260171)
    (FONTDIMEN
       (SLANT R 0.0)
       (SPACE R 0.333334)
       (STRETCH R 0.166667)
       (SHRINK R 0.111112)
       (XHEIGHT R 0.430555)
       (QUAD R 1.000003)
       (EXTRASPACE R 0.111112)
       )
    (LIGTABLE
       ...
       (LABEL C f)
       (LIG C i O 14)
       (LIG C f O 13)
       (LIG C l O 15)
       (KRN O 47 R 0.077779)
       (KRN O 77 R 0.077779)
       (KRN O 41 R 0.077779)
       (KRN O 51 R 0.077779)
       (KRN O 135 R 0.077779)
       (STOP)
       ...
       )
    ...
    (CHARACTER C f
       (CHARWD R 0.305557)
       (CHARHT R 0.694445)
       (CHARIC R 0.077779)
       (COMMENT
          (LIG C i O 14)
          (LIG C f O 13)
          (LIG C l O 15)
          (KRN O 47 R 0.077779)
          (KRN O 77 R 0.077779)
          ...
          )
       )
    ...

As you can see, the general format is a list of parenthesized properties, nested where necessary.

- The first few items (`FAMILY`, `FACE`, and so on) are the so-called headerbyte information from Metafont, giving general information about the font.
- The `FONTDIMEN` property defines the TeX `\fontdimen` values.
- The `LIGTABLE` property defines the ligature and kerning table. `LIG` properties define ligatures: in the example above, an ‘`f`’ (in the ‘`LABEL`’) followed by an ‘`i`’ is a ligature, i.e., a typesetting program like TeX replaces those two consecutive characters by the character at position octal ’014 in the current font—presumably the ‘fi’ ligature. `KRN` properties define kerns: if an ‘`f`’ is followed by character octal ’047 (an apostrophe), TeX inserts a small amount of space between them: 0.077779 times the design size the font was loaded at (about three-quarters of a printer’s point by default in this case, or .001 inches).
- The `CHARACTER` property defines the dimensions of a character: its width, height, depth, and italic correction, also in design-size units, as explained in the previous item. For our example ‘f’, the depth is zero, so that property is omitted. TFtoPL also inserts any kerns and ligatures for this character as a comment.

### 11.7 PLtoTF: Property list to TeX font metric conversion ¶

PLtoTF translates a property list file (as output by TFtoPL, for example) to TeX font metric (TFM, see Metric files in Dvips) format. It’s much easier for both programs and humans to create the (plain text) property list files and let PLtoTF take care of creating the binary TFM equivalent than to output TFM files directly. Synopsis:

    pltotf [option]... plfile[.pl] [tfmfile[.tfm]]

If tfmfile (extended with ‘`.tfm`’ if necessary) is not specified, the TFM file is written to the basename of ‘`plfile.tfm`’, e.g., ‘`pltotf /wherever/cmr10.pl`’ creates `./cmr10.tfm`. (Since TFM files are binary, writing to standard output by default is undesirable.)

The only options are ‘`-verbose`’, ‘`-help`’, and ‘`-version`’ (see Common options).

For an example of property list format, see the previous section.

### 11.8 VFtoVP: Virtual font to virtual property lists ¶

VFtoVP translates a virtual font metric (VF, see Virtual fonts in Dvips) file and its accompanying TeX font metric (TFM, see Metric files in Dvips) file (as output by VPtoVF, for example) to virtual property list format (a list of parenthesized items describing the virtual font) that humans can edit or read. This program is mostly used by people debugging virtual font utilities. Synopsis:

    vftovp [option]... vfname[.vf] [tfmname[.tfm] [vplfile[.vpl]]]

The fonts vfname and tfmname (extended with ‘`.vf`’ and ‘`.tfm`’ if necessary) are searched for in the usual places (see Supported file formats in Kpathsea). To see all the relevant paths, set the environment variable `KPATHSEA_DEBUG` to ‘`-1`’ before running the program. If tfmname is not specified, vfname (without a trailing ‘`.vf`’) is used.

If vplfile (extended with ‘`.vpl`’ if necessary) is not specified, the property list file is written to standard output. The property list file can be converted back to VF and TFM format by the companion program VFtoVP (see the next section).

The program accepts the following option, as well as the standard ‘`-verbose`’, ‘`-help`’ and ‘`-version`’ (see Common options):

‘`-charcode-format=type`’ ¶

  Output character codes in the PL file according to type: either ‘`octal`’ or ‘`ascii`’. Default is ‘`ascii`’ for letters and digits, octal for all other characters. Exception: if the font’s coding scheme starts with ‘`TeX math sy`’ or ‘`TeX math ex`’, all character codes are output in octal.

  In ‘`ascii`’ format, character codes that correspond to graphic characters, except for left and right parentheses, are output as a ‘`C`’ followed by the single character: ‘`C K`’, for example. In octal format, character codes are output as the letter ‘`O`’ followed by octal digits, as in ‘`O 113`’ for ‘`K`’.

  ‘`octal`’ format is useful for symbol and other non-alphabetic fonts, where using ASCII characters for the character codes is merely confusing.

### 11.9 VPtoVF: Virtual property lists to virtual font ¶

VPtoVF translates a virtual property list file (as output by VFtoVP, for example) to virtual font (VF, see Virtual fonts in Dvips) and TeX font metric (TFM, see Metric files in Dvips) files. It’s much easier for both programs and humans to create the (plain text) property list files and let VPtoVF take care of creating the binary VF and TFM equivalents than to output them directly. Synopsis:

    vptovf [option]... vplfile[.vpl] [vffile[.vf] [tfmfile[.tfm]]]

If vffile (extended with ‘`.vf`’ if necessary) is not specified, the VF output is written to the basename of ‘`vplfile.vf`’; similarly for tfmfile. For example, ‘`vptovf /wherever/ptmr.vpl`’ creates `./ptmr.vf` and `./ptmr.tfm`.

The only options are ‘`-verbose`’, ‘`-help`’, and ‘`-version`’ (see Common options).

### 11.10 Font utilities available elsewhere ¶

The Web2c complement of font utilities merely implements a few basic conversions. Many other more sophisticated font utilities exist; most are in `CTAN:/fonts/utilities` (for CTAN info, see unixtex.ftp in Kpathsea). Here are some of the most commonly-requested items:

- AFM (Adobe font metric) to TFM conversion: see Invoking afm2tfm in Dvips, and `CTAN:/fonts/utilities/afmtopl`.
- BDF (the X bitmap format) conversion: ftp://ftp.tug.org/tex/bdf.tar.gz.
- Creating fonts using MetaPost: MetaType1: https://ctan.org/pkg/metatype1. This was used to create the Latin Modern font family (https://ctan.org/pkg/lm), which extends Computer Modern to a larger repertoire of scripts.
- Editing of bitmap fonts: Xbfe from the GNU font utilities mentioned below; the X BDF-editing programs `xfed` and `xfedor`; finally, if your fonts have only 128 characters, you can use the old `gftopxl`, `pxtoch`, and `chtopx` programs from ftp://ftp.tug.org/tex/web.
- Editing of outline fonts: FontForge, https://fontforge.sourceforge.net. This is a very elaborate program with support for many outline formats (Type 1, OpenType, TrueType, …), and many advanced font editing features.
- PK bitmaps from PostScript outline fonts: gsftopk from the ‘`xdvi`’ distribution. Alternatively, `ps2pk`, from `CTAN:/fonts/utilities/ps2pk`.
- PostScript Type 1 font format conversion (i.e., between PFA and PFB formats): https://www.lcdf.org/type.
- Tracing bitmaps to fitted outlines: Autotrace (http://autotrace.sourceforge.net), Potrace (http://potrace.sourceforge.net). For Metafont fonts, either of the two programs `mftrace` (http://www.xs4all.nl/~hanwen/mftrace) or `textrace` (http://textrace.sourceforge.net) make the job easier.
- Virtual font creation: https://ctan.org/pkg/fontinst.

## Appendix A Legalisms ¶

In general, each file has its own copyright notice stating the copying permissions for that file. Following is a summary.

The Stanford TeX programs and Web2c system itself are in the public domain (https://tug.org/texlive/copying.html). The sources may be copied verbatim, or used as the starting point of new software under different names; however, per the wishes of the authors, they should be modified only through a `.ch` file, but this is in the nature of a development request rather than a legal requirement.

MLTeX, pdfTeX, LuaTeX, XeTeX, and all the other derived engines have used various license terms for their additions to the base code, often the GPL (see https://www.gnu.org/licenses/#GPL) or (for example) the file `web2c/pdftexdir/COPYINGv2`. They also mostly make use of additional libraries with their own (compatible) terms. Please see each program’s sources.

The Kpathsea library is covered by the GNU Lesser General Public License (see Introduction in Kpathsea). Therefore, the binaries resulting from a standard Web2c compilation are also covered by the LGPL; so if you (re)distribute the binaries, you must also (offer to) distribute the complete source that went into those binaries. See https://gnu.org/licenses/#LGPL or the file `kpathsea/COPYING.LESSERv2`.

## Appendix B References ¶

1. Kpathsea: See Introduction in Kpathsea.
2. Dvips and Afm2tfm: See Introduction in Dvips.
3. The TeX Users Group: https://tug.org. For an introduction to the TeX system, see https://tug.org/begin.html.
4. TUGboat, the principal journal for the TeX world: https://tug.org/TUGboat.
5. TeX and computer typesetting in general:
   https://ftp.math.utah.edu/pub/tex/bib/texbook1.bib and `texbook3.bib`, among others.
6. For a bibliography of formal articles and technical reports on the TeX project, see the books TeX: The Program or Metafont: The Program cited below.
7. [Bil87] Neenie Billawala. Write-white printing engines and tuning fonts with Metafont. TUGboat, 8(1):29–32, April 1987. https://tug.org/TUGboat/tb08-1/tb17billawala.pdf.
8. [Hob89] John D. Hobby. A Metafont-like system with PS output. TUGboat, 10(4):505–512, December 1989. https://tug.org/metapost.
9. [Hob92] John D. Hobby. A User’s Manual for MetaPost. Technical Report CSTR-162, AT&T Bell Laboratories, 1992.
10. [Hob93] John D. Hobby. Drawing Graphs with MetaPost. Technical Report CSTR-164, AT&T Bell Laboratories, 1993.
11. [HS91] Samuel P. Harbison and Guy L. Steele Jr. C—A Reference Manual. Prentice-Hall, Upper Saddle River, NJ 07458, USA, third edition, 1991. An authoritative reference to the C programming language, and a good companion to Kernighan and Ritchie.
12. [KL93] Donald E. Knuth and Silvio Levy. The CWEB System of Structured Documentation, Version 3.0. Addison-Wesley, Reading, MA, USA, 1993. https://ctan.org/pkg/cweb.
13. [Knu84] Donald E. Knuth. A torture test for TeX. Report No. STAN-CS-84-1027, Stanford University, Department of Computer Science, 1984.
14. [Knu86a] Donald E. Knuth. A Torture Test for METAFONT. Report No. STAN-CS-86-1095, Stanford University, Department of Computer Science, 1986.
15. [Knu86b] Donald E. Knuth. The TeXbook, volume A of Computers and Typesetting. Addison-Wesley, Reading, MA, USA, 1986.
16. [Knu86c] Donald E. Knuth. TeX: The Program, volume B of Computers and Typesetting. Addison-Wesley, Reading, MA, USA, 1986.
17. [Knu86d] Donald E. Knuth. The METAFONTbook, volume C of Computers and Typesetting. Addison-Wesley, Reading, MA, USA, 1986.
18. [Knu86e] Donald E. Knuth. METAFONT: The Program, volume D of Computers and Typesetting. Addison-Wesley, Reading, MA, USA, 1986.
19. [Knu86f] Donald E. Knuth. Computer Modern Typefaces, volume E of Computers and Typesetting. Addison-Wesley, Reading, MA, USA, 1986.
20. [Knu89] Donald E. Knuth. The errors of TeX. Software—Practice and Experience, 19(7):607–681, July 1989. This is an updated version of Knuth:1988:ET.
21. [Knu90] Donald Knuth. Virtual Fonts: More Fun for Grand Wizards. TUGboat, 11(1):13–23, April 1990. https://tug.org/TUGboat/tb11-1/tb27knut.pdf.
22. [Knu92] Donald E. Knuth. Literate Programming. CSLI Lecture Notes Number 27. Stanford University Center for the Study of Language and Information, Stanford, CA, USA, 1992.
23. [Lam94] Leslie Lamport. LaTeX: A Document Preparation System: User’s Guide and Reference Manual. Addison-Wesley, Reading, MA, USA, second edition, 1994. Reprinted with corrections, 1996.
24. [Lia83] Franklin Mark Liang. Word hy-phen-a-tion by com-put-er. Technical Report STAN-CS-83-977, Stanford University, August 1983. https://tug.org/docs/liang/liang-thesis.pdf.
25. [Mac91] Pierre A. MacKay. Looking at the pixels: Quality control for 300 dpi laser printer fonts, especially Metafonts. In Robert A. Morris and Jacques Andre, editors, Raster Imaging and Digital Typography II—Papers from the second RIDT meeting, held in Boston, Oct. 14–16, 1991, pages 205–215, New York, 1991. Cambridge University Press.

## Index ¶

Jump to: | - . " \ # % ^ ~ $ 2 3 6 8 A B C D E F G H I J K L M N O P Q R S T U V W X Y

| Index Entry | Section

-
| `- starting a filename` | Option conventions
| `- starts option names` | Option conventions
| `-- starts option names` | Option conventions
| `--disable-dump-share configure option` | Hardware and memory dumps
| `--disable-mf-nowin` | Online Metafont graphics
| `--enable-amigawin` | Online Metafont graphics
| `--enable-epsfwin` | Online Metafont graphics
| `--enable-hp2627win` | Online Metafont graphics
| `--enable-ipc configure option` | tex invocation
| `--enable-mftalkwin` | Online Metafont graphics
| `--enable-next` | Online Metafont graphics
| `--enable-regiswin` | Online Metafont graphics
| `--enable-suntoolswin` | Online Metafont graphics
| `--enable-tektronixwin` | Online Metafont graphics
| `--enable-unitermwin` | Online Metafont graphics
| `--help common option` | Common options
| `--verbose common option` | Common options
| `--version common option` | Common options
| `--with-editor=cmd` | Editor invocation
| `--with-mf-x-toolkit` | Online Metafont graphics
| `--with-x` | Online Metafont graphics
| `-8bit` | Common options
| `-base=base` | Determining the memory dump to use
| `-base=dumpname` | Common options
| `-change=chfile` | mft invocation
| `-charcode-format=type` | tftopl invocation
| `-charcode-format=type` | vftovp invocation
| `-cnf-line` | Common options
| `-D compiler options` | Compile-time options
| `-debug` | mpost invocation
| `-disable-write18` | tex invocation
| `-dpi=real` | dvitype invocation
| `-enable-write18` | tex invocation
| `-enc` | tex invocation
| `-file-line-error` | Common options
| `-file-line-error-style` | Common options
| `-fmt=dumpname` | Common options
| `-fmt=fmt` | Determining the memory dump to use
| `-geometry, supported with Xt` | Online Metafont graphics
| `-halt-on-error` | Common options
| `-images` | gftype invocation
| `-ini` | Common options
| `-ini` | Initial and virgin
| `-interaction=string` | Common options
| `-ipc` | tex invocation
| `-ipc-start` | tex invocation
| `-jobname=string` | Common options
| `-kpathsea-debug=number` | Common options
| `-length=number` | tangle invocation
| `-loose` | tangle invocation
| `-lowercase` | tangle invocation
| `-magnification=integer` | dvicopy invocation
| `-magnification=integer` | dvitype invocation
| `-max-pages=n` | dvicopy invocation
| `-max-pages=n` | dvitype invocation
| `-mem` | mpost invocation
| `-mem=dumpname` | Common options
| `-metapost` | mft invocation
| `-min-crossrefs=n` | bibtex invocation
| `-mixedcase` | tangle invocation
| `-mktex=filetype` | tex invocation
| `-mktex=filetype` | mf invocation
| `-mltex` | tex invocation
| `-mnemonics` | gftype invocation
| `-no-file-line-error` | Common options
| `-no-mktex=filetype` | tex invocation
| `-no-mktex=filetype` | mf invocation
| `-no-parse-first-line` | Common options
| `-no-shell-escape` | tex invocation
| `-numbersystem` | mpost invocation
| `-output-comment=string` | tex invocation
| `-output-directory` | Common options
| `-output-directory` | Output file location
| `-output-level=n` | dvitype invocation
| `-overflow-label-offset=points` | gftodvi invocation
| `-page-start=page-spec` | dvicopy invocation
| `-page-start=page-spec` | dvitype invocation
| `-parse-first-line` | Common options
| `-progname=string` | Common options
| `-progname=string` | Determining the memory dump to use
| `-recorder` | Common options
| `-restricted` | mpost invocation
| `-s` | mpost invocation
| `-shell-escape` | tex invocation
| `-shell-restricted` | tex invocation
| `-show-opcodes` | dvitype invocation
| `-strict` | tangle invocation
| `-style=mftfile` | mft invocation
| `-T` | mpost invocation
| `-terse` | bibtex invocation
| `-tex=texprogram` | mpost invocation
| `-translate-file=tcxfile` | Common options
| `-troff` | mpost invocation
| `-underline` | tangle invocation
| `-uppercase` | tangle invocation
| `-x` | weave invocation

.
| `., used for output` | Output file location
| `.2602gf` | mf invocation
| `.aux cross-reference files` | bibtex invocation
| `.base` | Initial Metafont
| `.bbl bibliography files` | bibtex invocation
| `.bib bibliography databases` | bibtex invocation
| `.blg BibTeX log file` | bibtex invocation
| `.fmt` | Initial TeX
| `.mf` | mf invocation
| `.mp` | mpost invocation
| `.mps` files and PDF | mpost invocation
| `.nnn PostScript figures` | mpost invocation
| `.nnngf generic fonts` | mf invocation
| `.tcx character translation files` | Common options
| `.tcx character translation files` | TCX files
| `.tex` | tex invocation
| `.tfm output` | mf invocation
| `.tfm output` | mpost invocation
| `.Xdefaults` | Online Metafont graphics
| `.Xresources` | Online Metafont graphics

"
| `"` character, ignored in filenames | \input filenames

\
| `\bibliography` | bibtex invocation
| `\bibliographystyle` | bibtex invocation
| `\charsubdef and MLTeX` | \charsubdef
| `\countn` | dvicopy invocation
| `\countn` | dvitype invocation
| `\font and dynamic generation` | tex invocation
| `\fontdimen` | tftopl invocation
| `\immediate\write18` | Shell escapes
| `\input` braced (grouped) filename | \input braced filename
| `\input` filename caveats | \input filename caveats
| `\input filenames` | \input filenames
| `\input` quoted filename | \input quoted filename
| `\input, and pipes` | Shell escapes
| `\mag` | dvicopy invocation
| `\mag` | dvitype invocation
| `\openin, and pipes` | Shell escapes
| `\openout and security` | tex invocation
| `\openout, and pipes` | Shell escapes
| `\output routine, and `\write`` | Shell escapes
| `\pdfshellescape` | Shell escapes
| `\string, and `\input filenames`` | \input filename caveats
| `\tracingcharsubdef and MLTeX` | \tracingcharsubdef
| `\tracinglostchars and MLTeX` | \tracingcharsubdef
| `\write18 shell escape extension` | Shell escapes
| `\write18, output location for` | Output file location

#
| ‘`#define`’ options | Compile-time options

%
| `%& magic number` | Determining the memory dump to use

^
| `^^ notation, avoiding` | TCX files

~
| `~ expansion in filenames` | \input filename caveats

$
| `$ expansion in filenames` | \input filename caveats

2
| `2602gf` | mf invocation

3
| 32-bit architecture | Hardware and memory dumps

6
| 64-bit architecture | Hardware and memory dumps

8
| 8 bit clean | Common options
| `8 bit clean output, specifying` | Common options
| 8-bit characters | TCX files

A
| `abbrv.bst` | Basic BibTeX style files
| accented character | TCX files
| accents, hyphenating words with | MLTeX
| acknowledgements | Introduction
| `acm.bst` | Basic BibTeX style files
| Ada, WEB for | WEB
| additional Make targets | Additional targets
| AFM to TFM conversion | Font utilities available elsewhere
| `afm2tfm` | Font utilities available elsewhere
| `afmtopl` | Font utilities available elsewhere
| Aleph | TeX extensions
| aliases for fonts | Path searching
| `alpha.bst` | Basic BibTeX style files
| American Mathematical Society, typesetting system | Formats
| `amiga` | Online Metafont graphics
| AMSTeX | Formats
| `apalike.bst` | Basic BibTeX style files
| architecture dependencies | Hardware and memory dumps
| array limit, fixed | Runtime options
| array sizes | Runtime options
| assembly language routines | Compile-time options
| `autotrace` | Font utilities available elsewhere
| Awk, WEB for | WEB

B
| base file, determining | Determining the memory dump to use
| base files | Initial Metafont
| base files, need mode definitions | Modes
| base files, plain only | Initial Metafont
| base files, sharing | Hardware and memory dumps
| `bases Make target` | Additional targets
| basic BibTeX style files | Basic BibTeX style files
| basic fonts and macros | Installation
| batch languages | TeX
| BDF and GF conversion | Font utilities available elsewhere
| `beamer, package` | Formats
| `beginfig` | mpost invocation
| Berry, Karl | Introduction
| `BIBINPUTS, search path for bib files` | bibtex invocation
| bibliographies, creating | BibTeX
| bibliography | References
| bibliography items, cross-referenced | bibtex invocation
| `bibtex` | bibtex invocation
| BibTeX | BibTeX
| BibTeX collection | bibtex invocation
| BibTeX style files | Basic BibTeX style files
| BigEndian machines | Hardware and memory dumps
| binaries, linking | Common options
| blank lines, in TCX files | TCX files
| boxes, memory for | Runtime options
| braced filename for `\input` | \input braced filename
| breakpoints, memory for | Runtime options
| Breitenlohner, Peter | Introduction
| `BSTINPUTS, search path for bst files` | bibtex invocation
| `btex for MetaPost labels` | mpost invocation
| `btxdoc.bib` | bibtex invocation
| `btxdoc.tex` | bibtex invocation
| `btxhak.tex` | bibtex invocation
| byte position | pktype invocation
| byte position | gftype invocation
| byte swapping | Hardware and memory dumps

C
| `c-sources Makefile target` | Additional targets
| caveats for `\input` filenames | \input filename caveats
| change files, and MFT | mft invocation
| change files, and Tangle | tangle invocation
| change files, and Weave | weave invocation
| changing error messages style | Common options
| character codes, in GFtype output | gftype invocation
| character codes, in PKtype output | pktype invocation
| character codes, in TCX files | TCX files
| character proofs of fonts | gftodvi invocation
| `CHARACTER property` | tftopl invocation
| character translation files | TCX files
| `CHARDP property` | tftopl invocation
| `CHARHT property` | tftopl invocation
| `CHARIC property` | tftopl invocation
| `CHARWD property` | tftopl invocation
| `chtopx` | Font utilities available elsewhere
| class name for Metafont | Online Metafont graphics
| `cm.base` | Initial Metafont
| `cmbase.mf` | Initial Metafont
| `cmbase.mft` | mft invocation
| `cmmf.base not recommended` | Initial Metafont
| color, in DVItoMP | dvitomp invocation
| `COM1`..0`, reserved filename on Windows` | \input filename caveats
| comments, in TCX files | TCX files
| comments, MFT control | mft invocation
| common options | Common options
| commonalities | Commonalities
| compilation | Installation
| compile-time options | configure options
| compile-time options | Compile-time options
| Computer Modern fonts, and Troff | mpost invocation
| Computer Modern macros | Initial Metafont
| Computer Modern Typefaces, production of | mft invocation
| `CON, reserved filename on Windows` | \input filename caveats
| configuration | Installation
| configuration file reading | Path searching
| configuration file values | Runtime options
| configuration, compile-time | configure options
| `configure --with/--enable options` | configure options
| `CONTENTS.tex` | weave invocation
| ConTeXt | Formats
| conventions for options, | Option conventions
| conversion, DVI to plain text | dvitype invocation
| conversion, GF to PK | gftopk invocation
| conversion, GF to plain text | gftype invocation
| conversion, PK to GF | pktogf invocation
| conversion, PK to plain text | pktype invocation
| conversion, property list to TFM | pltotf invocation
| conversion, property list to VF | vptovf invocation
| conversion, TFM to property list | tftopl invocation
| conversion, VF to VPL | vftovp invocation
| copyright notices | Legalisms
| Cork encoding and ISO input | TCX files
| creating memory dumps | Creating memory dumps
| cross-engine functionality | TeX extensions
| cross-referenced bibliography items | bibtex invocation
| cross-references, omitting | weave invocation
| current directory, used for output | Output file location
| Curtis, Pavel | Introduction
| Cweb | WEB
| CWEB | WEB

D
| date and time, in memory dumps | Hardware and memory dumps
| debugging DVI utilities | dvitype invocation
| debugging flags, specifying | Common options
| decimal character codes, in TCX files | TCX files
| dependencies, hardware | Hardware and memory dumps
| design-size units | tftopl invocation
| device definitions, for Metafont | Modes
| device-independent width | pktype invocation
| device-independent width | gftype invocation
| directory structure | Installation
| `DISPLAY` | Online Metafont graphics
| `DISPLAY` | Online Metafont graphics
| dot files, written by TeX programs | tex invocation
| double quote character, ignored in filenames | \input filenames
| downloading of fonts for MetaPost labels | mpost invocation
| `DrawingServant` | Online Metafont graphics
| dump file | Common options
| dumping memory | Memory dumps
| DVI comment, specifying | tex invocation
| DVI files, converting to MPX | dvitomp invocation
| DVI files, explained | Font file formats
| DVI format definition | DVI utilities
| DVI opcodes, showing | dvitype invocation
| DVI utilities | DVI utilities
| `dvicopy` | dvicopy invocation
| `dvitomp` | dvitomp invocation
| `dvitype DVI validation` | dvitype invocation
| dvitype output example | dvitype output example
| `dvitype.web` | DVI utilities
| dx horizontal escapement | pktype invocation
| dx horizontal escapement | gftype invocation
| dy vertical escapement | gftype invocation
| dynamic array allocation | Runtime options
| dynamic Metafont mode definitions with `smode` | Modes
| dynamic packing variable | pktype invocation

E
| `e response at error prompt` | Editor invocation
| e-circumflex | \charsubdef
| e-TeX | TeX extensions
| `e.mft` | mft invocation
| EC fonts | mf invocation
| editing of bitmap fonts | Font utilities available elsewhere
| editor invoked at error | Editor invocation
| eight-bit characters in filenames | \input filename caveats
| `empty.tcx` | TCX files
| endian dependencies | Hardware and memory dumps
| `eoc GF command` | gftype invocation
| Eplain | Formats
| `epsf` | Online Metafont graphics
| epTeX | TeX extensions
| errors, editor invoked at | Editor invocation
| escapement, horizontal | pktype invocation
| escapement, horizontal | gftype invocation
| escapement, vertical | gftype invocation
| `etex for MetaPost labels` | mpost invocation
| `etex is pdfTeX` | TeX extensions
| eupTeX | TeX extensions
| executables, shared initial and virgin | Initial and virgin
| exit status, of shell escape | Shell escapes
| `expand_depth` | Runtime options
| expanded plain format | Formats
| expansion limit, recursive | Runtime options
| expansion, and `\input` filenames | \input filename caveats
| extensions to TeX | TeX extensions
| `extra_mem_bot` | Runtime options

F
| `FACE property` | tftopl invocation
| `FAMILY property` | tftopl invocation
| `FAMILY property` | tftopl invocation
| Ferguson, Michael | MLTeX
| file formats for fonts | Font file formats
| file recorder | Common options
| filename conventions, in input files | \input filenames
| filenames starting with ‘`-`’ | Option conventions
| first line of the main input file | Common options
| fixed-point arithmetic | Compile-time options
| `FIXPT` | Compile-time options
| flag byte | pktype invocation
| floating-point arithmetic | Compile-time options
| floating-point values | Hardware and memory dumps
| fmt file, determining | Determining the memory dump to use
| fmt files | Initial TeX
| fmt files, sharing | Hardware and memory dumps
| `fmts Make target` | Additional targets
| font aliases | Path searching
| font character code, translating | TCX files
| font design | Metafont
| font downloading for MetaPost labels | mpost invocation
| font file formats | Font file formats
| font proofs | gftodvi invocation
| font utilities | Font utilities
| font utilities, non-Web2c | Font utilities available elsewhere
| `fontforge` | Font utilities available elsewhere
| `fontinst, for creating virtual fonts` | Font utilities available elsewhere
| fonts, basic | Installation
| format files | Initial TeX
| formats for TeX | Formats
| `formats Make target` | Additional targets
| fraction routines | Compile-time options
| Free Software Foundation documentation system | Formats
| freedom of Web2c | Introduction
| `ftp.math.utah.edu` | bibtex invocation

G
| generating source specials | tex invocation
| geometric designs | Metafont
| geometric font scaling | Font file formats
| geometry for Metafont | Online Metafont graphics
| `getopt_long_only` | Option conventions
| GF files, explained | Font file formats
| GF files, output by Metafont | mf invocation
| GF format definition | Font utilities
| GF output | mf invocation
| GF, converting PK to | pktogf invocation
| GF, converting to PK | gftopk invocation
| `gftodvi` | gftodvi invocation
| `gftopk` | gftopk invocation
| `gftopxl` | Font utilities available elsewhere
| `gftype GF validation` | gftype invocation
| `gftype.web` | Font utilities
| glue ratio representations | Hardware and memory dumps
| glue, memory for | Runtime options
| glyph substitutions | MLTeX
| gray font | gftodvi invocation
| group-delimited filename for `\input` | \input braced filename
| Gruff, Billy Goat | Triptrap
| `gsftopk` | Font utilities available elsewhere

H
| Harbison, Samuel P. | Hardware and memory dumps
| hardware and memory dumps | Hardware and memory dumps
| `headerbyte information` | tftopl invocation
| height, in pixels | pktype invocation
| help, online | Common options
| Herberts, Mathias | Online Metafont graphics
| hex character codes, in TCX files | TCX files
| HINT (Hint Is Not TeX) | TeX extensions
| history | Introduction
| hiTeX | TeX extensions
| Hobby, John | Introduction
| horizontal escapement | pktype invocation
| horizontal escapement | gftype invocation
| `hp2627` | Online Metafont graphics
| human languages, supported in TeX | Languages and hyphenation
| human-readable text, converting DVI to | dvitype invocation
| human-readable text, converting GF to | gftype invocation
| human-readable text, converting PK to | pktype invocation
| human-readable text, converting TFM to | tftopl invocation
| human-readable text, converting VF to | vftovp invocation
| hypertext | TeX extensions
| hyphenation and languages | Languages and hyphenation
| hyphenation patterns, creating | patgen invocation

I
| ice cream | Introduction
| identifier case | tangle invocation
| identifier collisions | tangle invocation
| identifier length | tangle invocation
| identifiers with underlines | tangle invocation
| `ieeetr.bst` | Basic BibTeX style files
| `il1-t1.tcx` | TCX files
| `il2-t1.tcx` | TCX files
| Info format | Formats
| initial form, enabling | Common options
| initial Metafont | Initial Metafont
| initial MetaPost | Initial MetaPost
| initial programs | Initial and virgin
| initial TeX | Initial TeX
| initializations, lengthy | Initial and virgin
| input filenames | \input filenames
| input from the output directory | Output file location
| `install-bases Make target` | Additional targets
| `install-fmts Make target` | Additional targets
| `install-formats Make target` | Additional targets
| `install-mems Make target` | Additional targets
| installation | Installation
| interaction between TCX files and ‘`-8bit`’. | TCX files
| interaction mode | Common options
| international characters | TCX files
| introduction | Introduction
| IPC | IPC and TeX
| `IPC_DEBUG` | Compile-time options
| `IPC_DEBUG` | IPC and TeX

J
| job name | Common options

K
| kerning table, in TFM files | tftopl invocation
| keyboard character code, translating | TCX files
| Knuth, Donald E. | Introduction
| Knuth, Donald E. | mft invocation
| `KPATHSEA_DEBUG` | Common options
| `KRN property` | tftopl invocation

L
| label font | gftodvi invocation
| `LABEL property` | tftopl invocation
| language support in TeX | Languages and hyphenation
| languages, hyphenation rules for | patgen invocation
| LaTeX | Formats
| LaTeX testing | Formats
| `latex-dev` | Formats
| Latin Modern | Font utilities available elsewhere
| left side bearing | pktype invocation
| left side bearing | gftype invocation
| legalisms | Legalisms
| `libsigsegv library` | Runtime options
| licensing terms | Introduction
| `LIG property` | tftopl invocation
| ligature table, in TFM files | tftopl invocation
| `LIGTABLE property` | tftopl invocation
| linking binaries | Common options
| links to binaries | Determining the memory dump to use
| literate programming | WEB
| LittleEndian machines | Hardware and memory dumps
| location of `texmf.cnf` in TeX Live | Runtime options
| log file, BibTeX | bibtex invocation
| `long` data type, size of | Hardware and memory dumps
| `ltx-talk, package` | Formats
| Lua | TeX extensions
| Lua, and unportable memory dumps | Hardware and memory dumps
| LuaTeX | TeX extensions

M
| machine dependencies | Hardware and memory dumps
| machine-readable, converting property lists to | pltotf invocation
| machine-readable, converting property lists to | vptovf invocation
| MacKay, Pierre | Font file formats
| macro packages, major TeX | Formats
| macros, basic | Installation
| macros, predefining in memory dumps | Memory dumps
| magnification | dvicopy invocation
| magnification | dvitype invocation
| `main_memory` | Runtime options
| Make targets, additional | Additional targets
| Martin, Rick | Introduction
| Mathematical Reviews | Formats
| mathematical typesetting | TeX
| memory dump to use, determining | Determining the memory dump to use
| memory dumps | Memory dumps
| memory dumps and hardware | Hardware and memory dumps
| memory dumps, contain date and time | Hardware and memory dumps
| memory dumps, creating | Creating memory dumps
| `mems Make target` | Additional targets
| meta characters in filenames | \input filename caveats
| Metafont | Metafont
| Metafont geometry | Online Metafont graphics
| Metafont graphics | Online Metafont graphics
| Metafont input files | mf invocation
| Metafont invocation | mf invocation
| Metafont meets PostScript | MetaPost
| Metafont online support, new devices | Online Metafont graphics
| Metafont or MetaPost source, prettyprinting | mft invocation
| Metafont without online graphics | Online Metafont graphics
| Metafont, compatibility in MetaPost | Initial MetaPost
| Metafont, initial | Initial Metafont
| Metafont, MetaPost, and TeX | Three programs
| MetaPost | MetaPost
| MetaPost and plain Metafont compatibility | Initial MetaPost
| MetaPost input files | mpost invocation
| MetaPost invocation | mpost invocation
| MetaPost source, prettyprinting | mft invocation
| MetaPost, initial | Initial MetaPost
| MetaPost, TeX, and Metafont | Three programs
| `metatype1` | Font utilities available elsewhere
| `mf` | mf invocation
| `mf.base` | Initial Metafont
| `MFEDIT` | Editor invocation
| `mfplain` | Initial MetaPost
| `mfput` | mf invocation
| `mft` | mft invocation
| `mftalk` | Online Metafont graphics
| `MFTERM` | Online Metafont graphics
| `mftmac.tex` | mft invocation
| micro-typography | TeX extensions
| `mktexmf, disabling` | mf invocation
| `mktextfm, disabling` | tex invocation
| `mltex` | MLTeX
| MLTeX, enabling | tex invocation
| mode needed to run Metafont | mf invocation
| `mode_def` | Modes
| `mode_setup` | Modes
| modes file needed for Metafont | Modes
| `modes.mf recommended modes file` | Modes
| modifying `texmf.cnf` in TeX Live | Runtime options
| Morgan, Tim | Introduction
| Morris, Bob | Introduction
| `MPEDIT` | Editor invocation
| `mpgraph.pdf` | mpost invocation
| `mpman.pdf` | mpost invocation
| `mpost` | mpost invocation
| `mpost, reason for name change` | Installation
| `mpout` | mpost invocation
| `mproof.tex` | mpost invocation
| `mptrap Make target` | Additional targets
| mptrap test | Triptrap
| `mptrap.readme` | Triptrap
| MPX files, converting from DVI files | dvitomp invocation
| Multi-lingual TeX | MLTeX
| multiple spaces, and `\input` filenames | \input filename caveats

N
| N tilde | \charsubdef
| new graphics support for Metafont | Online Metafont graphics
| `newrow GF command` | gftype invocation
| `next` | Online Metafont graphics
| non-Unix system, compiling on | Additional targets
| non-windows-capable Metafont | Online Metafont graphics
| NUL bytes, not allowed in filenames | \input filename caveats
| `NUL, reserved filename on Windows` | \input filename caveats

O
| octal character codes, in TCX files | TCX files
| offset for overflow labels | gftodvi invocation
| Omega | TeX extensions
| online Metafont graphics | Online Metafont graphics
| opcodes, showing DVI | dvitype invocation
| OpenType support | TeX extensions
| optical font scaling | Font file formats
| option conventions | Option conventions
| origin | pktype invocation
| output directory, specifying | Common options
| output directory, specifying | Output file location
| output file location | Output file location
| output files, written by TeX programs | tex invocation
| `output_comment for DVI files` | tex invocation
| overflow label offset | gftodvi invocation
| overflow, of runtime stack | Runtime options

P
| packet length | pktype invocation
| page, starting | dvicopy invocation
| page, starting | dvitype invocation
| parsing the first line | Common options
| Pascal, creating from WEB | tangle invocation
| `patgen` | patgen invocation
| path searching | Path searching
| path searching debugging | Common options
| PDF | TeX extensions
| PDF, and `.mps` files | mpost invocation
| pdfTeX | TeX extensions
| permissions, legal | Legalisms
| PFA and PFB conversion | Font utilities available elsewhere
| `pfaedit` | Font utilities available elsewhere
| PiCTeX, increasing memory for | Runtime options
| pid, used in recorder filename | Common options
| pipes, reading and writing | Shell escapes
| pixel height | pktype invocation
| pixel width | pktype invocation
| PK bitmaps from PostScript | Font utilities available elsewhere
| PK files, explained | Font file formats
| PK files, not output by Metafont | mf invocation
| PK format definition | Font utilities
| PK, converting GF to | gftopk invocation
| PK, converting to GF | pktogf invocation
| `pktogf` | pktogf invocation
| `pktype PK validation` | pktype invocation
| `pktype.web` | Font utilities
| PL files, explained | Font file formats
| plain Metafont, compatibility in MetaPost | Initial MetaPost
| plain text, converting DVI to | dvitype invocation
| plain text, converting GF to | gftype invocation
| plain text, converting PK to | pktype invocation
| plain text, converting TFM to | tftopl invocation
| plain text, converting VF to | vftovp invocation
| `plain.base` | Initial Metafont
| `plain.bst` | Basic BibTeX style files
| `plain.fmt` | Initial TeX
| `plain.mft` | mft invocation
| `pltotf` | pltotf invocation
| pool file, writing | tangle invocation
| Poole, Simon | Online Metafont graphics
| `pooltype` | pooltype invocation
| portable filenames | \input filenames
| portable memory dumps | Hardware and memory dumps
| PostScript fonts, and Troff | mpost invocation
| PostScript meets Metafont | MetaPost
| PostScript output | mpost invocation
| PostScript to PK bitmaps | Font utilities available elsewhere
| PostScript Type 1 font conversion | Font utilities available elsewhere
| PostScript, and font scaling | Font file formats
| `potrace` | Font utilities available elsewhere
| predefined macros and memory dumps | Memory dumps
| prettyprinting Metafont or MetaPost source | mft invocation
| prettyprinting WEB programs | weave invocation
| primitives, new | TeX extensions
| printable characters, specifying | TCX files
| printer characteristics, for Metafont | Modes
| production use | Initial and virgin
| program name, determines memory dump | Determining the memory dump to use
| program names, special | Common options
| program names, special | Common options
| program names, special | tex invocation
| `prologues` | mpost invocation
| `prologues, and EPSF output` | mpost invocation
| `proof mode` | mf invocation
| proof sheets, of fonts | gftodvi invocation
| property list format | tftopl invocation
| property list, converting TFM to | tftopl invocation
| property list, converting VF to virtual | vftovp invocation
| `ps2pk` | Font utilities available elsewhere
| `psfonts.map, read by MetaPost` | mpost invocation
| pTeX | TeX extensions
| PXL files, explained | Font file formats
| `pxtoch` | Font utilities available elsewhere

Q
| quoted filename for `\input` | \input quoted filename

R
| Raichle, Bernd | MLTeX
| reading from the output directory | Output file location
| reading, additional | Introduction
| readonly directory, running TeX in | Output file location
| readonly directory, running TeX in | Output file location
| reallocation of arrays | Runtime options
| recursive expansion limit | Runtime options
| redefined character substitutions | \tracingcharsubdef
| reference pixel | pktype invocation
| references | References
| `regis` | Online Metafont graphics
| Regis graphics support | Online Metafont graphics
| regression testing | tex invocation
| repeated rows | pktype invocation
| representation of strings | pooltype invocation
| restricted shell escapes | Shell escapes
| right side bearing | pktype invocation
| right side bearing | gftype invocation
| Rokicki, Tomas | Introduction
| run length encoded bitmaps | pktype invocation
| run length encoded bitmaps | gftype invocation
| runtime options | Runtime options
| runtime stack overflow | Runtime options

S
| scaled pixels | pktype invocation
| scaled pixels | gftype invocation
| scaling of fonts | Font file formats
| security, and `\openout` | tex invocation
| security, and output files | tex invocation
| security, and shell escapes | Shell escapes
| security, and `write` | mpost invocation
| segmentation fault | Runtime options
| shapes | Metafont
| sharing memory dumps | Hardware and memory dumps
| shell commands in TeX | Shell escapes
| `shell_escape enabling in TeX` | Shell escapes
| `shell_escape_commands` | Shell escapes
| `siam.bst` | Basic BibTeX style files
| side bearings | pktype invocation
| side bearings | gftype invocation
| `SIGSEGV` | Runtime options
| slant font | gftodvi invocation
| `slides, package` | Formats
| slides, producing | Formats
| SliTeX | Formats
| small Metafont memory and modes | Modes
| `smode and dynamic Metafont mode definition` | Modes
| sockets | IPC and TeX
| space-terminated filenames | \input filenames
| Spiderweb | WEB
| Stallman, Richard | Introduction
| starting page | dvicopy invocation
| starting page | dvitype invocation
| Steele Jr., Guy L. | Hardware and memory dumps
| stopping at the first error | Common options
| strategy, overall | Introduction
| string numbers, displaying | pooltype invocation
| string pool, writing | tangle invocation
| string representation | pooltype invocation
| style design, for BibTeX | bibtex invocation
| style files | mft invocation
| substitutions of font glyphs | MLTeX
| `sun` | Online Metafont graphics
| `sun-gfx.c` | Online Metafont graphics
| Suntools | Online Metafont graphics
| SunView | Online Metafont graphics
| swap space, as array limit | Runtime options
| swapping bytes | Hardware and memory dumps
| syntax of TCX files | TCX files
| `system C library function` | Shell escapes
| system command | Shell escapes
| system fonts, using | TeX extensions

T
| T1 encoding and ISO input | TCX files
| tabs, and `\input` filenames | \input filename caveats
| Tachikawa, Elizabeth | Font file formats
| `tangle` | tangle invocation
| targets, additional Make | Additional targets
| `TCX character translation files` | TCX files
| technical illustrations, creating | MetaPost
| `tek` | Online Metafont graphics
| Tektronix | Online Metafont graphics
| Tektronix 4014 | Online Metafont graphics
| `TERM` | Online Metafont graphics
| terminator for filenames | \input filenames
| terse output | bibtex invocation
| testing LaTeX | Formats
| teTeX distribution | Introduction
| `tex` | tex invocation
| TeX, bibliographies for | bibtex invocation
| TeX, creating from Metafont or MetaPost | mft invocation
| TeX, creating from WEB | weave invocation
| TeX, description of | TeX
| TeX, extensions to | TeX extensions
| TeX, format packages for | Formats
| TeX, initial | Initial TeX
| TeX, input files found | tex invocation
| TeX, invocation | tex invocation
| TeX, Metafont, and MetaPost | Three programs
| TeX, Web2c implementation of | Introduction
| `tex.fmt` | Initial TeX
| `TEXBIB, search path for bib files` | bibtex invocation
| `TEXEDIT` | Editor invocation
| `texfonts.map` | Path searching
| Texinfo | Formats
| `texmf_casefold_search` | Runtime options
| `TEXMF_OUTPUT_DIRECTORY` | Output file location
| `texmf.cnf` | Path searching
| `texmf.cnf` | Runtime options
| `texmf.cnf for editors` | Editor invocation
| `texmf.cnf for shell escapes` | Shell escapes
| `texmfmp.c` | Online Metafont graphics
| `TEXMFOUTPUT, used if ‘`.`’ unwritable` | Output file location
| `texput` | tex invocation
| TFM files, converting property lists to | pltotf invocation
| TFM files, explained | Font file formats
| TFM files, output by Metafont | mf invocation
| TFM files, output by MetaPost | mpost invocation
| TFM width of characters | pktype invocation
| TFM width of characters | gftype invocation
| `tftopl` | tftopl invocation
| three programs | Three programs
| time and date, in memory dumps | Hardware and memory dumps
| title font | gftodvi invocation
| `tl-check-fmtshare` | Hardware and memory dumps
| tokenization, and `\input` filenames | \input filename caveats
| toolkits, X | Online Metafont graphics
| torture tests | Triptrap
| translation file for TeX, specifying | Common options
| translation from WEB to C | Introduction
| `trap Make target` | Additional targets
| trap test | Triptrap
| `trapman.tex` | Triptrap
| Trickey, Howard | Introduction
| `trip Make target` | Additional targets
| trip test | Triptrap
| `tripman.tex` | Triptrap
| `triptrap Make target` | Additional targets
| Troff, and MetaPost | mpost invocation
| `troff, supported in MetaPost` | MetaPost
| Troff, WEB for | WEB
| Trojan horses and TeX programs | tex invocation
| TrueType support | TeX extensions
| TUGboat bibliography | bibtex invocation
| Type 1 conversion | Font utilities available elsewhere
| type design, personal | Initial Metafont
| type programs, DVI | dvitype invocation
| type programs, GF | gftype invocation
| type programs, PK | pktype invocation
| type programs, pool | pooltype invocation
| typeface families | Metafont
| typesetting | TeX

U
| Unicode | TeX extensions
| Unicode input | tex invocation
| Unicode input, native | TeX extensions
| `uniterm` | Online Metafont graphics
| `unsrt.bst` | Basic BibTeX style files
| upTeX | TeX extensions
| UTF-8 input | tex invocation
| UTF-8 input, native | TeX extensions

V
| validation, of DVI files | dvitype invocation
| validation, of GF files | gftype invocation
| validation, of PK files | pktype invocation
| validation, of TFM files | tftopl invocation
| validation, of VF files | vftovp invocation
| verbose BibTeX output, suppressing | bibtex invocation
| verbosity, enabling | Common options
| version number, finding | Common options
| vertical escapement | gftype invocation
| VF files, converting property lists to | vptovf invocation
| `vftovp` | vftovp invocation
| virgin programs | Initial and virgin
| virtual font creation | Font utilities available elsewhere
| virtual fonts, expanding | dvicopy invocation
| `virtual-fonts.knuth` | Font file formats
| `virtualfonts.txt` | Font file formats
| `vptovf` | vptovf invocation

W
| `weave` | weave invocation
| WEB | WEB
| web environments, and security | Shell escapes
| WEB pool files, displaying | pooltype invocation
| WEB programs, compiling | tangle invocation
| WEB programs, typesetting | weave invocation
| `WEB2C, search path for TCX files` | TCX files
| Weber, Olaf | Introduction
| `webmac.tex` | weave invocation
| `webman.tex` | WEB
| whitespace-terminated filenames | \input filenames
| whitespace, in TCX files | TCX files
| width, device-independent | pktype invocation
| width, device-independent | gftype invocation
| width, in pixels | pktype invocation
| `win32win` | Online Metafont graphics
| word processor, not | TeX
| writing memory dumps | Creating memory dumps

X
| X bitmap fonts | Font utilities available elsewhere
| X class name for Metafont | Online Metafont graphics
| x offset | pktype invocation
| X resources | Online Metafont graphics
| X server, and Metafont | Online Metafont graphics
| X toolkits and Metafont | Online Metafont graphics
| `xampl.bib` | bibtex invocation
| `xbfe, bitmap font editor` | Font utilities available elsewhere
| XeTeX | TeX extensions
| `xfed, bitmap font editor` | Font utilities available elsewhere
| `xfedor, bitmap font editor` | Font utilities available elsewhere
| `Xlib` | Online Metafont graphics
| Xlib support | Online Metafont graphics
| `Xt` | Online Metafont graphics
| Xt support | Online Metafont graphics
| `xterm` | Online Metafont graphics

Y
| y offset | pktype invocation