6 A user's guide to the Web2c system

Web2c contains a set of TeX-related programs, i.e., TeX itself, Metafont, MetaPost, BIBTeX, etc. The original implementation was by Tomas Rokicki who, in 1987, developed a first TeX-to-C system adapting change files under Unix, which were primarily the work of Howard Trickey and Pavel Curtis. Tim Morgan became the maintainer of the system, and during this period the name changed to Web-to-C. In 1990, Karl Berry took over the work, assisted by dozens of additional contributors, and in 1997 he handed the baton to Olaf Weber. The latest result is Web2c Version 7.2, which was released in March 1998, and forms the basis of the present TeX Live CD-ROM.

The Web2c 7.2 system runs on Unix, Windows 3.1, 9x/NT, DOS, Amiga and other operating systems. It uses Knuth's original sources for TeX and other basic programs written in web and translates them into C source code. Moreover, the system offers a large set of macros and functions developed to augment the original TeX software. The core TeX family components are:

bibtex
Maintaining bibliographies.
dmp
troff to MPX (MetaPost pictures).
dvicopy
Virtual font expansion.
dvitomp
DVI to MPX (MetaPost pictures).
dvitype
DVI to human-readable text.
gftodvi
Generic font proofsheets.
gftopk
Generic to packed fonts.
gftype
GF to human-readable text.
makempx
MetaPost label typesetting.
mf
Creating typeface families.
mft
Prettyprinting Metafont source.
mpost
Creating technical diagrams.
mpto
MetaPost label extraction.
newer
Compare modification times.
patgen
Creating hyphenation patterns.
pktogf
Packed to generic fonts.
pktype
PK to human-readable text.
pltotf
Property list to TFM.
pooltype
Display web pool files.
tangle
web to Pascal.
tex
Typesetting.
tftopl
TFM to property list.
vftovp
Virtual font to virtual property list
vptovf
Virtual property list to virtual font.
weave
web to TeX.

The precise functions and syntax of these programs are described in the documentation of the individual packages or of Web2c itself. However, knowing a few principles governing the whole family of programs will help you to benefit optimally from your Web2c installation.

All programs honor the standard GNU options:

--help   
print basic usage summary.
--verbose
print detailed progress report.
--version
print version information, then exit.

For locating files the Web2c programs use the path searching library Kpathsea. This library uses a combination of environment variables and a few configuration files to optimize searching the TeX directory tree. Web2c 7.2 can handle more than one directory tree simultaneously, which is useful if one wants to maintain TeX's standard distribution and local extensions in two distinct trees. To speed up file searches the root of each tree has a file ls-R, containing an entry showing the name and relative pathname for all files "hanging" under that root.

6.1 Kpathsea path searching

Let us first describe the generic path searching mechanism of the Kpathsea library.

We call a search path a colon- or semicolon-separated list of path elements, which are basically directory names. A search path can come from (a combination of) many sources. To look up a file "my-file" along a path ".:/dir", Kpathsea checks each element of the path in turn: first ./my-file, then /dir/my-file, returning the first match (or possibly all matches).

In order to adapt optimally to all operating systems' conventions, on non-Unix systems Kpathsea can use filename separators different from "colon" (":") and "slash" ("/").

To check a particular path element p, Kpathsea first checks if a prebuilt database (see "Filename database" on page 33) applies to p, i.e., if the database is in a directory that is a prefix of p. If so, the path specification is matched against the contents of the database.

If the database does not exist, or does not apply to this path element, or contains no matches, the filesystem is searched (if this was not forbidden by a specification starting with "!!" and if the file being searched for must exist). Kpathsea constructs the list of directories that correspond to this path element, and then checks in each for the file being sought.

The "file must exist" condition comes into play with ".vf" files and input files read by TeX's \openin command. Such files may not exist (e.g., cmr10.vf), and so it would be wrong to search the disk for them. Therefore, if you fail to update ls-R when you install a new ".vf" file, it will never be found. Each path element is checked in turn: first the database, then the disk. If a match is found, the search stops and the result is returned.

Although the simplest and most common path element is a directory name, Kpathsea supports additional features in search paths: layered default values, environment variable names, config file values, users' home directories, and recursive subdirectory searching. Thus, we say that Kpathsea expands a path element, meaning it transforms all the specifications into basic directory name or names. This is described in the following sections in the same order as it takes place.

Note that if the filename being searched for is absolute or explicitly relative, i.e., starts with "/" or "./" or "../", Kpathsea simply checks if that file exists.

6.1.1 Path sources

A search path can come from many sources. In the order in which Kpathsea uses them:

  1. A user-set environment variable, for instance, TEXINPUTS. Environment variables with a period and a program name appended override; e.g., if "latex" is the name of the program being run, then TEXINPUTS.latex will override TEXINPUTS.
  2. A program-specific configuration file, for example, a line "S /a:/b" in dvips's config.ps.
  3. A Kpathsea configuration file texmf.cnf, containing a line like "TEXINPUTS=/c:/d" (see below).
  4. The compile-time default.

You can see each of these values for a given search path by using the debugging options (see "Debugging actions" on page 41).

6.1.2 Config files

Kpathsea reads runtime configuration files named texmf.cnf for search path and other definitions. The search path used to look for these files is named TEXMFCNF (by default such a file lives in the texmf/web2c subdirectory). All texmf.cnf files in the search path will be read and definitions in earlier files override those in later files. Thus, with a search path of .:$TEXMF, values from ./texmf.cnf override those from $TEXMF/texmf.cnf.

While reading the description of the format of the file texmf.cnf below, please also refer to appendix A, starting on page 54, which lists the texmf.cnf file on the CD-ROM.

A configuration file fragment illustrating most of these points is shown below:

    TEXMF              = {$TEXMFLOCAL;!!$TEXMFMAIN}

    TEXINPUTS.latex    = .;$TEXMF/tex/{latex;generic;}//

    TEXINPUTS.fontinst = .;$TEXMF/tex//;$TEXMF/fonts/afm//

    % e-TeX related files

    TEXINPUTS.elatex   = .;$TEXMF/{etex;tex}/{latex;generic;}//

    TEXINPUTS.etex     = .;$TEXMF/{etex;tex}/{eplain;plain;generic;}//

6.1.3 Path expansion

Kpathsea recognizes certain special characters and constructions in search paths, similar to those available in Unix shells. As a general example, the complex path, ~$USER/{foo,bar}//baz, expands to all subdirectories under directories foo and bar in $USER's home directory that contain a directory or file baz. These expansions are explained in the sections below.

6.1.4 Default expansion

If the highest-priority search path (see "Path sources" on page 29) contains an extra colon (i.e., leading, trailing, or doubled), Kpathsea inserts at that point the next-highest-priority search path that is defined. If that inserted path has an extra colon, the same happens with the next highest. For example, given an environment variable setting


>> setenv TEXINPUTS /home/karl:
and a TEXINPUTS value from texmf.cnf of


  .:$TEXMF//tex
then the final value used for searching will be:


  /home/karl:.:$TEXMF//tex

Since it would be useless to insert the default value in more than one place, Kpathsea changes only one extra ":" and leaves any others in place: it checks first for a leading ":", then a trailing ":", then a doubled ":".

6.1.5 Brace expansion

A useful feature is brace expansion, which means that, for instance, v{a,b}w expands to vaw:vbw. Nesting is allowed. This can be used to implement multiple TeX hierarchies, by assigning a brace list to $TEXMF. For example, in texmf.cnf, you find (line 52) the following definition:

    TEXMF = {$TEXMFLOCAL,!!$TEXMFMAIN}

Using this you can then write something like

    TEXINPUTS = .;$TEXMF/tex//

which means that, after looking in the current directory, first the full $TEXMFLOCAL/tex directory tree (on disk) and then the !!$TEXMFMAIN/tex tree (using the data base file ls-R only) will be searched. It is a convenient way for running two parallel TeX structures, one "frozen" (on a CD-ROM, for instance) and the other being continuously updated with new versions as they become available. By using the $TEXMF variable in all definitions, one is sure to always search the up-to-date tree first.

6.1.6 Subdirectory expansion

Two or more consecutive slashes in a path element following a directory d is replaced by all subdirectories of d: first those subdirectories directly under d, then the subsubdirectories under those, and so on. At each level, the order in which the directories are searched is unspecified.

If you specify any filename components after the "//", only subdirectories with matching components are included. For example, "/a//b" expands into directories /a/1/b, /a/2/b, /a/1/1/b, and so on, but not /a/b/c or /a/1.

Multiple "//" constructs in a path are possible, but "//" at the beginning of a path is ignored.

6.1.7 List of special characters and their meaning: a summary

The following list summarises the meaning of special characters in Kpathsea configuration files.

:
Separator in path specification; at the beginning or the end of a path it substitutes the default path expansion.
;
Separator on non-Unix systems (acts like :).
$
Variable expansion.
~
Represents the user's home directory.
{...}
Brace expansion, e.g., a{1,2}b will become a1b:a2b.
//
Subdirectory expansion (can occur anywhere in a path, except at its begining).
%
Start of comment.
\
Continuation character (allows multi-line entries).
!!
Search only database to locate file, do not search the disk.

6.2 Filename databases

Kpathsea goes to some lengths to minimize disk accesses for searches. Nevertheless, at installations with enough directories, searching each possible directory for a given file can take an excessively long time (this is especially true if many hundreds of font directories have to be traversed.) Therefore, Kpathsea can use an externally-built "database" file named ls-R that maps files to directories, thus avoiding the need to exhaustively search the disk.

A second database file aliases allows you to give additional names to the files listed in ls-R. This can be helpful to adapt to DOS-like "8.3" filename conventions in source files.

6.2.1 The filename database

As explained above, the name of the main filename database must be ls-R. You can put one at the root of each TeX hierarchy in your installation that you wish to be searched ($TEXMF by default); most sites have only one hierarchy. Kpathsea looks for ls-R files along the TEXMFDBS path.

The recommended way to create and maintain "ls-R" is to run the mktexlsr script included with the distribution. It is invoked by the various "mktex". . .  scripts. In principle, this script just runs the command


cd /your/texmf/root && ls -LAR ./ >ls-R
presuming your system's ls produces the right output format (GNU's ls is all right). To ensure that the database is always up to date, it is easiest to rebuild it regularly via cron, so that for changes in the installed files---perhaps after installing or updating a LaTeX package---the file ls-R is automatically updated.

If a file is not found in the database, by default Kpathsea goes ahead and searches the disk. If a particular path element begins with "!!", however, only the database will be searched for that element, never the disk.

6.2.2 kpsewhich: Standalone path searching

The kpsewhich program exercises path searching independent of any particular application. This can be useful as a sort of find program to locate files in TeX hierarchies (this is used heavily in the distributed "mktex". . .  scripts).


>> kpsewhich option... filename...
The options specified in "option " can start with either "-" or "--", and any unambiguous abbreviation is accepted.

Kpathsea looks up each non-option argument on the command line as a filename, and returns the first file found. There is no option to return all the files with a particular name (you can run the Unix "find" utility for that).

The more important options are described next.

--dpi=num
Set the resolution to "num "; this only affects "gf" and "pk" lookups. "-D" is a synonym, for compatibility with dvips. Default is 600.
--format=name
Set the format for lookup to "name". By default, the format is guessed from the filename. For formats which do not have an associated unambiguous suffix, such as MetaPost support files and dvips configuration files, you have to specify the name as found in the first column of Table 1, which lists currently recognized names, a description, associated environment variables1 , and possible file extensions.


Table 1Kpathsea file types
Name
Description
Variables
Suffixes








afm
Adobe font metrics
AFMFONTS
.afm
base
Metafont memory dump
MFBASES, TEXMFINI
.base
bib
BIBTeX bibliography source
BIBINPUTS, TEXBIB
.bib
bst
BIBTeX style files
BSTINPUTS
.bst
cnf
Runtime configuration files
TEXMFCNF
.cnf
dvips config
dvips configuration files, e.g., config.ps and psfonts.map
TEXCONFIG
.map
fmt
TeX memory dump
TEXFORMATS, TEXMFINI
.fmt, .efmt, .efm
gf
generic font bitmap
FONTS, GFFONTS, GLYPHFONTS, TEXFONTS
.gf
graphic/figure
Encapsulated PostScript figures
TEXPICTS, TEXINPUTS
.eps, .epsi
ist
makeindex style files
TEXINDEXSTYLE, INDEXSTYLE
.ist
ls-R
Filename databases
TEXMFDBS
map
Fontmaps
TEXFONTMAPS
.map
mem
MetaPost memory dump
MPMEMS, TEXMFINI
.mem
mf
Metafont source
MFINPUTS
.mf
mfpool
Metafont program strings
MFPOOL, TEXMFINI
.pool
mft
MFT style file
MFTINPUTS
.mft
mp
MetaPost source
MPINPUTS
.mp
mppool
MetaPost program strings
MPPOOL, TEXMFINI
.pool
MetaPost support
MetaPost support files, used by DMP
MPSUPPORT
ocp
Omega compiled process files
OCPINPUTS
.ocp
ofm
Omega font metrics
OFMFONTS, TEXFONTS
.ofm, .tfm
opl
Omega property lists
OPLFONTS, TEXFONTS
.opl
otp
Omega translation process files
OTPINPUTS
.otp
ovf
Omega virtual fonts
OVFFONTS, TEXFONTS
.ovf
ovp
Omega virtual property lists
OVPFONTS, TEXFONTS
.ovp
pk
packed bitmap fonts
programFONTS (program being XDVI, etc.), PKFONTS, TEXPKS, GLYPHFONTS, TEXFONTS
.pk
PostScript header
downloadable PostScript
TEXPSHEADERS, PSHEADERS
.pro, .enc
tex
TeX source
TEXINPUTS
.tex, .cls, .sty, .clo, .def
TeX system documentation
Documentation files for the TeX system
TEXDOCS
TeX system sources
Source files for the TeX system
TEXSOURCES
texpool
TeX program strings
TEXPOOL, TEXMFINI
.pool
tfm
TeX font metrics
TFMFONTS, TEXFONTS
.tfm
Troff fonts
Troff fonts, used by DMP
TRFONTS
truetype fonts
TrueType outline fonts
TTFONTS
.ttf, .ttc
type1 fonts
Type 1 PostScript outline fonts
T1FONTS, T1INPUTS, TEXPSHEADERS, DVIPSHEADERS
.pfa, .pfb
type42 fonts
Type 42 PostScript outline fonts
T42FONTS
vf
virtual fonts
VFFONTS, TEXFONTS
.vf
web2c files
Web2c support files
WEB2C
other text files
text files used by `foo'
FOOINPUTS
other binary files
binary files used by `foo'
FOOINPUTS

The last two entries in Table 1 are special cases, where the paths and environment variables depend on the name of the program: the variable name is constructed by converting the program name to upper case, and then appending INPUTS.

The environment variables are set by default in the configuration file texmf.cnf. It is only when you want to override one or more of the values specified in that file that you might want to set them explicitly in your execution environment.

Note that the "--format" and "--path" options are mutually exclusive.

--mode=string
Set the mode name to "string "; this only affects "gf" and "pk" lookups. No default: any mode will be found.
--must-exist
Do everything possible to find the files, notably including searching the disk. By default, only the ls-R database is checked, in the interest of efficiency.
--path=string
Search along the path "string " (colon-separated as usual), instead of guessing the search path from the filename. "//" and all the usual expansions are supported. The options "--path" and "--format" are mutually exclusive.
--progname=name
Set the program name to "name". This can affect the search paths via the ".prognam " feature in configuration files. The default is "kpsewhich".
--show-path=name
shows the path used for file lookups of file type "name". Either a filename extension (".pk", ".vf", etc.) or a name can be used, just as with "--format" option.
--debug=num
sets the debugging options to "num ".

6.2.3 Examples of use

Let us now have a look at Kpathsea in action.


>> kpsewhich  article.cls
   /usr/local/texmf/tex/latex/base/article.cls
We are looking for the file article.cls. Since the ".cls" suffix is unambiguous we do not need to specify that we want to look for a file of type "tex" (TeX source file directories). We find it in the subdirectory tex/latex/base below the "TEXMF" root directory. Similarly, all of the following are found without problems thanks to their unambiguous suffix.


>> kpsewhich array.sty
   /usr/local/texmf/tex/latex/tools/array.sty
>> kpsewhich latin1.def
   /usr/local/texmf/tex/latex/base/latin1.def
>> kpsewhich size10.clo
   /usr/local/texmf/tex/latex/base/size10.clo
>> kpsewhich small2e.tex
   /usr/local/texmf/tex/latex/base/small2e.tex
>> kpsewhich tugboat.bib
   /usr/local/texmf/bibtex/bib/beebe/tugboat.bib
The latter is a BIBTeX bibliography database for TUGBoat articles.


>> kpsewhich cmr10.pk
Font bitmap glyph files of type .pk are used by display programs like dvips and xdvi. Nothing is returned in this case since there are no pre-generated Computer Modern ".pk" files on our system (since we use the Type1 versions on the CD-ROM).


>> kpsewhich ecrm1000.pk
   /usr/local/texmf/fonts/pk/ljfour/jknappen/ec/ecrm1000.600pk
For the extended Computer Modern files we had to generate ".pk" files, and since the default Metafont mode on our installation is ljfour with a base resolution of 600 dpi (dots per inch), this instantiation is returned.


>> kpsewhich -dpi=300 ecrm1000.pk
In this case, when specifying that we are interested in a resolution of 300dpi (-dpi=300) we see that no such font is available on the system. In fact, a program like dvips or xdvi would go off and actually build the .pk files at the required resolution using the script mktexpk.

Next we turn our attention to dvips's header and configuration files. We first look at one of the commonly used files, the general prolog tex.pro for TeX support, before turning our attention to the generic configuration file (config.ps) and the PostScript font map psfonts.map. As the ".ps" suffix is ambiguous we have to specify explicitly which type we are considering ("dvips config") for the file config.ps.


>> kpsewhich tex.pro
   /usr/local/texmf/dvips/base/tex.pro
>> kpsewhich --format="dvips config" config.ps
   /usr/local/texmf/config/config.ps
>> kpsewhich psfonts.map
   /usr/local/texmf/dvips/base/psfonts.map

We now take a closer look at the URW Times PostScript support files. The name for these in Berry's font naming scheme is "utm". The first file we look at is the configuration file, which contains the name of the map file:


>> kpsewhich --format="dvips config"  config.utm
   /usr/local/texmf/dvips/psnfss/config.utm
The contents of that file is


  p +utm.map
which points to the file utm.map, which we want to locate next.


>> kpsewhich --format="dvips config" utm.map
   /usr/local/texmf/dvips/psnfss/utm.map
This map file defines the file names of the Type1 PostScript fonts in the URW collection. its contents looks like (we only show part of the lines):


  utmb8r  NimbusRomNo9L-Medi    ... <utmb8a.pfb
  utmbi8r NimbusRomNo9L-MediItal... <utmbi8a.pfb
  utmr8r  NimbusRomNo9L-Regu    ... <utmr8a.pfb
  utmri8r NimbusRomNo9L-ReguItal... <utmri8a.pfb
  utmbo8r NimbusRomNo9L-Medi "  ... <utmb8a.pfb
  utmro8r NimbusRomNo9L-Regu "  ... <utmr8a.pfb
Let us, for instance, take the Times Regular instance utmr8a.pfb and find its position in the texmf directory tree by using a search for Type1 font files:


>> kpsewhich utmr8a.pfb
   /usr/local/texmf/fonts/type1/urw/utm/utmr8a.pfb

It should be evident from these few examples how you can easily locate the whereabouts of a given file. This is especially important if you suspect that the wrong version of a file is picked up somehow, since kpsewhich will show you the first file encountered.

6.2.4 Debugging actions

Sometimes it is necessary to investigate how a program resolves file references. To make this feasible in a convenient way Kpathsea offers various debug levels:

A value of -1 will set all the above options; in practice you will probably always use these levels if you need any debugging.

Similarly, with the dvips program, by setting a combination of debug switches, one can follow in detail where files are being picked up from. Alternatively, when a file is not found, the debug trace shows in which directories the program looks for the given file, so that one can get an indication what the problem is.

Generally speaking, as most programs call the Kpathsea library internally, one can select a debug option by using the KPATHSEA_DEBUG environment variable, and setting it to (a combination of) values as described in the above list.

Let us consider, as an example, a small LaTeX source file, hello-world.tex, which contains the following input.

    \documentclass{article}

    \begin{document}

    Hello World!

    \end{document}

This little file only uses the font cmr10, so let us look how dvips prepares the PostScript file (we want to use the Type1 version of the Computer Modern fonts, hence the option -Pcms).


>> dvips -d4100 hello-world -Pcms -o
In this case we have combined dvips's debug class 4 (font paths) with Kpathsea's path element expansion (see dvips Reference Manual, texmf/doc/html/dvips/dvips_toc.html). We get something like the following (we have rearranged the output for easier display):


debug:start search(file=texmf.cnf, must_exist=1, find_all=1,
  path=.:/usr/local/bin/texlive:/usr/local/bin:
       /usr/local/bin/texmf/web2c:/usr/local:
       /usr/local/texmf/web2c:/.:/./teTeX/TeX/texmf/web2c:).
kdebug:start search(file=ls-R, must_exist=1, find_all=1,
  path=~/tex:/usr/local/texmf).
kdebug:search(ls-R) =>/usr/local/texmf/ls-R
kdebug:start search(file=aliases, must_exist=1, find_all=1,
  path=~/tex:/usr/local/texmf).
kdebug:search(aliases) => /usr/local/texmf/aliases
kdebug:start search(file=config.ps, must_exist=0, find_all=0,
  path=.:~/tex:!!/usr/local/texmf/dvips//).
kdebug:search(config.ps) => /usr/local/texmf/dvips/config/config.ps
kdebug:start search(file=/root/.dvipsrc, must_exist=0, find_all=0,
  path=.:~/tex:!!/usr/local/texmf/dvips//).
search(file=/home/goossens/.dvipsrc, must_exist=1, find_all=0,
  path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//).
kdebug:search($HOME/.dvipsrc) =>
kdebug:start search(file=config.cms, must_exist=0, find_all=0,
  path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//).
kdebug:search(config.cms)
=>/usr/local/texmf/dvips/cms/config.cms
dvips starts by locating its working files. First, texmf.cnf is found, which gives the definitions of the search paths for the other files, then the file database ls-R (to optimize file searching) and the file aliases, which makes it possible to declare several names (e.g., a short DOS-like "8.3" and a more natural longer version) for the same file. Then dvips goes on to find the generic configuration file config.ps before looking for the customization file .dvipsrc (which, in this case is not found). Finally, dvips locates the config file for the Computer Modern PostScript fonts config.cms (this was initiated with the -Pcms option on the dvips command). This file contains the list of the "map" files which define the relation between the TeX, PostScript and file system names of the fonts.


>> more /usr/local/texmf/dvips/cms/config.cms
   p +ams.map
   p +cms.map
   p +cmbkm.map
   p +amsbkm.map
dvips thus goes on to find all these files, plus the generic map file psfonts.map, which is always loaded (it contains declarations for commonly used PostScript fonts; see the last part of Section 6.2.3 for more details about PostScript map file handling).

At this point dvips identifies itself to the user:


This is dvips 5.76a Copyright 1997 Radical Eye Software (www.radicaleye.com)
then goes on to look for the prolog file texc.pro,


kdebug:start search(file=texc.pro, must_exist=0, find_all=0,
  path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//:
       ~/tex/fonts/type1//:!!/usr/local/texmf/fonts/type1//).
kdebug:search(texc.pro) => /usr/local/texmf/dvips/base/texc.pro
After having found the file in question, dvips outputs date and time, and informs us that it will generate the file hello-world.ps, then that it needs the font file cmr10, and that the latter is declared as "resident":


TeX output 1998.02.26:1204' -> hello-world.ps
Defining font () cmr10 at 10.0pt
Font cmr10 <CMR10> is resident.
Now the search is on for the file cmr10.tfm, which is found, then a few more prolog files (not shown) are referenced, and finally the Type1 instance cmr10.pfb of the font is located and included in the output file (see last line).


kdebug:start search(file=cmr10.tfm, must_exist=1, find_all=0,
  path=.:~/tex/fonts/tfm//:!!/usr/local/texmf/fonts/tfm//:
       /var/tex/fonts/tfm//).
kdebug:search(cmr10.tfm) => /usr/local/texmf/fonts/tfm/public/cm/cmr10.tfm
kdebug:start search(file=texps.pro, must_exist=0, find_all=0,
   ...
<texps.pro>
kdebug:start search(file=cmr10.pfb, must_exist=0, find_all=0,
  path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//:
       ~/tex/fonts/type1//:!!/usr/local/texmf/fonts/type1//).
kdebug:search(cmr10.pfb) => /usr/local/texmf/fonts/type1/public/cm/cmr10.pfb
<cmr10.pfb>[1]

6.3 Runtime options

Another of the nice features of Web2c 7.2 is its possibility to control a number of memory parameters (in particular, array sizes) via the runtime file texmf.cnf read by Kpathsea. The listing of texmf.cnf is shown in Appendix A, starting on page 54; the settings of all parameters can be found in Part 3 of that file. The more important control variables are (line numbers refer to the file texmf.cnf):

main_memory
Total words of memory available, for TeX, Metafont and MetaPost. You must make a new format file for each different setting. For instance, you could generate a "huge" version of TeX, and call the format file hugetex.fmt. Using the standard way of specifying the program name used by Kpathsea, the particular value of the main_memory variable will then be read from texmf.cnf (see line 327 for the generic value and line 329 for the "huge" one instantiated by hugetex, etc.).
extra_mem_bot
Extra space for "large" TeX data structures: boxes, glue, breakpoints, etc. Especially useful if you use PICTeX (line 300).
font_mem_size
Number of words for font information available for TeX. This is more or less the total size of all TFM files read (lines 310--314).
hash_extra
Additional space for the hash table of control sequence names. Approximately 10,000 control sequences can be stored in the main hash table; if you have a large book with numerous cross-references, this might not be enough. On lines 319 to 321 you see that both the hugetex and pdftex program invocations ask for an extra 10,000 control sequences (the default value of hash_extra is zero, as seen on line 296).

Of course, this facility is no substitute for truly dynamic arrays and memory allocation, but since this is extremely difficult to implement in present TeX, these runtime parameters provide a practical compromise allowing some flexibility.