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.3, which was released in March 1999, and forms the basis of the present TeX
Live CD-ROM.
The Web2c 7.3 system runs on Unix, Windows 3.1, 9x/NT, DOS, 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
- troœ to MPX (MetaPost pictures).
-
dvicopy
- Produces modified copy of DVI file.
-
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.3 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 32) 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:
- 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.
- A program-specific configuration file, for example, a line “S /a:/b” in dvips’s config.ps.
- A Kpathsea configuration file texmf.cnf, containing a line like “TEXINPUTS=/c:/d” (see below).
- 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 40).
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 9,
starting on page 48, which lists the texmf.cnf file on the CD-ROM.
- Comments start with “%” and continue to the end of the line.
- Blank lines are ignored.
- A \ at the end of a line acts as a continuation character, i.e., the next line is appended. Whitespace
at the beginning of continuation lines is not ignored.
- Each remaining line has the form:
variable[.progname] [=] value
where the “=” and surrounding whitespace are optional.
- The “variable” name may contain any character other than whitespace, “=”, or “.”, but sticking to
“A-Za-z_” is safest.
- If “.progname” is present, the definition only applies if the program that is running is named progname
or progname.exe. This allows different flavors of TeX to have different search paths, for
example.
- “value” may contain any characters except “%” and “@”. The “$var.prog” feature is not available on
the right-hand side; instead, you must use an additional variable. A “;” in “value” is translated to “:” if
running under Unix; this is useful to be able to have a single texmf.cnf for Unix, MSDOS and Windows
systems.
- All definitions are read before anything is expanded, so variables can be referenced before they are
defined.
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 28) 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
then the final value used for searching will be:
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 the following definition:
TEXMF = {$HOMETEXMF,$TEXMFLOCAL,!!$VARTEXMF,!!$TEXMFMAIN}
Using this you can then write something like
TEXINPUTS = .;$TEXMF/tex//
which means that, after looking in the current directory, the $HOMETEXMF/tex, $TEXMFLOCAL/tex,
$VARTEXMF/tex and $TEXMFMAIN/tex trees only) will be searched (the last two use using ls-R data base files).
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 1: | Kpathsea 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 |
| bitmap
fonts | GLYPHFONTS,
TEXFONTS | |
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 | GFFONTS | .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 |
| miscellaneous
fonts | MISCFONTS | |
mp | MetaPost
source | MPINPUTS | .mp |
mppool | MetaPost
program
strings | MPPOOL,
TEXMFINI | .pool |
MetaPost
support | MetaPost
support
files,
used
by
DMP | MPSUPPORT | |
ocp |
compiled
process
files | OCPINPUTS | .ocp |
ofm |
font
metrics | OFMFONTS,
TEXFONTS | .ofm,
.tfm |
opl |
property
lists | OPLFONTS,
TEXFONTS | .opl |
otp |
translation
process
files | OTPINPUTS | .otp |
ovf |
virtual
fonts | OVFFONTS,
TEXFONTS | .ovf |
ovp |
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.
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 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 look 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:
- stat calls (file tests). When running with an up-to-date ls-R database this should almost give no
output.
- References to hash tables (like ls-R database, map files, configuration files).
- File open and close operations.
- General path information for file types searched by Kpathsea. This is useful to find out where a
particular path for the file was defined.
- Directory list for each path element (only relevant for searches on disk).
- File searches.
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.
(Note for Windows users: it is not easy to redirect all messages to a file in this system. For diagnostic
purposes you can temporarily SET KPATHSEA_DEBUG_OUTPUT=err.log).
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). The output (slightly rearranged) appears
in Figure 4.
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
Figure 4: | Finding configuration files |
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
Figure 5: | Finding the prolog file |
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]
Figure 6: | Finding the font file |
|
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.78 Copyright 1998 Radical Eye Software (www.radicaleye.com)
...and 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.3 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 9, starting on page 48; the settings of all parameters can be found in Part 3 of that file. The more
important control variables are:
-
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 (compare the generic value and 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 PI CTeX.
-
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.
-
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. You can see that both the hugetex and pdÆatex program
invocations ask for an extra 15,000 control sequences (the default value of hash_extra is zero).
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.