This document describes the main features of the TEX Live software distribution — TEX and related programs for GNU/Linux and other Unix flavors, Mac OS X, and Windows systems.
You may have acquired TEX Live by downloading, or on the TEX Collection DVD, which TEX usergroups distribute among their members. Section 2.1 briefly describes the contents of this DVD. Both TEX Live and the TEX Collection are cooperative efforts by the TEX user groups. This document mainly describes TEX Live itself.
TEX Live includes executables for TEX, LaTeX2e, ConTEXt, Metafont, MetaPost, BibTeX and many other programs; an extensive collection of macros, fonts and documentation; and support for typesetting in many different scripts from around the world.
TEX Live packages are regularly updated from CTAN: http://www.ctan.org.
For a brief summary of the major changes in this edition of TEX Live, see the end of the document, section 10 (p. 74).
TEX Live contains binaries for many Unix-based architectures, including Mac OS X. The included sources should enable installation on platforms for which we do not have binaries.
As to Windows: only Windows 2000 and later are supported. Windows 9x, ME and NT have been dropped. Because of this change, Windows requires much less special treatment compared to the Unix systems. There are no 64-bit executables for Windows, but the 32-bit executables should run on 64-bit systems.
See section 2.1 for alternate solutions for Windows and Mac OS X.
You can install TEX Live either from DVD or over the Internet. The net installer itself is small, and downloads everything requested from the Internet. The net installer is an attractive option if you need only a fraction of the complete TEX Live.
The DVD installer lets you install to a local disk, but you can also run TEX Live directly from the DVD (or from a DVD image, if your system supports that).
This is described in the installation sections following, but here is a quick start:
The TEX community is both active and friendly, and most serious questions end up getting answered. However, the support is informal, done by volunteers and casual readers, so it’s especially important that you do your homework before asking. (If you prefer guaranteed commercial support, you can forego TEX Live completely and purchase a vendor’s system; http://tug.org/interest.html#vendors has a list.)
Here is a list of resources, approximately in the order we recommend using them:
The other side of the coin is helping others who have questions. Both comp.text.tex and texhax are open to anyone, so feel free to join, start reading, and help out where you can.
This section describes the contents of TEX Live and the TEX Collection of which it is a part.
The TEX Collection DVD comprises the following:
CTAN, protext, and texmf-extra do not necessarily follow the same copying conditions as TEX Live, so be careful when redistributing or modifying.
Here is a brief listing and description of the top level directories in the TEX Live distribution. On the live DVD, the entire TEX Live hierarchy is in a subdirectory texlive, not at the top level of the disc.
The TEX system programs, arranged by platform.
Web pages with a quick introduction and useful links, in various languages.
The source to all included programs, including the main Web2C TEX and Metafont distributions.
Various auxiliary packages and programs. These are not installed automatically. This includes assorted editors and TEX shells.
See TEXMFMAIN below.
See TEXMFDIST below.
Tree for self-contained pure documentation, arranged by language.
Scripts, programs and data for managing the installation. It also contains private copies of Perl and Ghostscript for Windows, which are invisible outside TEX Live, and a new Windows PostScript viewer PSView.
In addition to the directories above, the installation scripts and README files (in various languages) are at the top level of the distribution.
The texmf-doc directory contains documentation which does not belong to any particular package or program. The documentation for the programs (manuals, man pages, Info files) is in texmf/doc. The documentation for TEX packages and formats is in texmf-dist/doc. You can use the texdoc or texdoctk programs to find any documentation wherever it is located. The comprehensive links in the top-level file doc.html may also be helpful.
This TEX Live documentation itself is in texmf-doc and is available in several languages:
This section lists all predefined variables specifying the texmf trees used by the system, and their intended purpose, and the default layout of a TEX Live system. The command texconfig conf shows you the values of these variables, so that you can easily find out how they map to directory names in your installation.
The tree which holds vital parts of the system such as helper scripts (e.g., web2c/mktexdir) and other support files and their documentation. Does not include TEX formats and packages.
The tree which holds the main set of macro packages, fonts, etc., as originally distributed.
The tree which administrators can use for system-wide installation of additional or updated macros, fonts, etc.
The tree which users can use for their own individual installations of additional or updated macros, fonts, etc. The expansion of this variable dynamically adjusts for each user to their own individual directory.
The tree used by the utilities texconfig, updmap, and fmtutil to store modified configuration data. Under TEXMFHOME by default.
The tree used by the utilities texconfig-sys, updmap-sys, and fmtutil-sys to store modified configuration data.
The tree used by texconfig, updmap and fmtutil to store (cached) runtime data such as format files and generated map files. Under TEXMFHOME by default.
The tree used by texconfig-sys, updmap-sys and fmtutil-sys, and also by tlmgr, to store (cached) runtime data such as format files and generated map files.
The default layout is:
A previous release.
The current release.
GNU/Linux binaries
Mac OS X binaries
Windows binaries
This is TEXMFMAIN.
TEXMFDIST
TEXMFDOC
TEXMFSYSVAR
TEXMFSYSCONFIG
TEXMFLOCAL, intended to be retained from release to release.
Privately generated and configuration data for a previous release.
Privately generated and configuration data for the current release.
TEXMFVAR
TEXMFCONFIG
TEXMFHOME Personal macros. etc.
TEX itself is frozen, apart from rare bug fixes. It is still present in TEX Live as the program tex, and will remain so in the foreseeable future. TEX Live contains several extended versions of TEX:
Here are a few other commonly-used programs included in TEX Live:
bibliography support.
index support.
convert DVI to PostScript.
DVI previewer for the X Window System.
DVI drive for the HP LaserJet family.
convert DVI to/from plain text.
cut and paste pages from DVI files.
convert DVI to PDF, an alternative approach to pdfTEX (mentioned above). See the ps4pdf and pdftricks packages for still more alternatives.
PostScript utilities.
LATEX syntax checker.
ConTEXt and PDF processor.
TEX to HTML (and XML and more) converter.
TEX Live comes with many high-quality scalable fonts. See http://tug.org/fonts and texmf-doc/english/free-math-fonts-survey.
To start with, get the TEX Collection DVD or download the TEX Live net installer, and locate the installer script: install-tl for Unix, install-tl.bat for Windows.
The following sections explain in more detail.
Below, > denotes the shell prompt; user input is bold. Starting in a terminal window on a Unix-compatible system, the simplest way:
To install in GUI mode (you’ll need the Perl/TK module), use:
For a complete listing of the various options:
Warning about Unix permissions: Your umask at the time of installation will be respected by the TEX Live installer. Therefore, if you want your installation to be usable by users other than you, make sure your setting is sufficiently permissive, for instance, umask 002. For more information about umask, consult your system documentation.
As mentioned in section 2.1, a separate distribution is prepared for Mac OS X, named MacTEX ( http://tug.org/mactex). We recommend using the native MacTEX installer instead of the TEX Live installer on Mac OS X, because the native installer can make a few Mac-specific adjustments, in particular to allow easily switching between the various TEX distributions for Mac OS X (MacTEX, gwTEX, Fink, MacPorts, …).
MacTEX is firmly based on TEX Live, and the main TEX trees are precisely the same. It does add a few extra folders with Mac-specific documentation and applications.
If you are using the net installer, or the DVD installer failed to start automatically, double-click install-tl.bat.
You can also start the installer from the command-prompt. Below, > denotes the prompt; user input is bold. If you are in the installer directory, run just:
Or you can invoke it with an absolute location, such as:
To install in text mode, use:
For a complete listing of the various options:
Figure 1 displays the main text mode screen under Unix.
This is only a command-line installer; there is no cursor support at all. For instance, you cannot tab around checkboxes or input fields. You just type something (case-sensitive) at the prompt and press the Enter key, and then the entire terminal screen will be rewritten, with adjusted content.
The text installer interface is this primitive for a reason: it is designed to run on as many platforms as possible, even with a very barebones Perl (for Windows, a Perl subset is included).
Figure 2 displays the graphical installer under Windows. Most differences in available options are due to this screenshot being from Windows, and the previous text screen being from GNU/Linux.
The installer is intended to be mostly self-explanatory. Still, a few quick notes about the various options and submenus:
Available sets of binaries:
=============================================================================== a [ ] alpha-linux DEC Alpha with GNU/Linux b [ ] amd64-freebsd x86_64 with FreeBSD c [ ] hppa-hpux HP-UX d [ ] i386-freebsd Intel x86 with FreeBSD e [X] i386-linux Intel x86 with GNU/Linux f [ ] i386-openbsd Intel x86 with OpenBSD g [ ] i386-solaris Intel x86 with Sun Solaris h [ ] mips-irix SGI IRIX i [ ] powerpc-aix PowerPC with AIX j [ ] powerpc-linux PowerPC with GNU/Linux k [ ] sparc-linux Sparc with GNU/Linux l [ ] sparc-solaris Sparc with Solaris m [ ] universal-darwin universal binaries for MacOSX/Darwin o [ ] win32 Windows p [ ] x86_64-linux x86_64 with GNU/Linux
|
Figure 3 displays the text mode binaries menu. By default, only the binaries for your current platform will be installed. From this menu, you can select installation of binaries for other architectures as well. This can be useful if you are sharing a TEX tree across a network of heterogenous machines, or for a dual-boot system.
Select a scheme:
=============================================================================== a [ ] TeX Live basic scheme b [ ] TeX Live scheme for ConTeXt c [X] TeX Live full scheme d [ ] GUST TeX Live scheme e [ ] GUTenberg TeX Live scheme f [ ] TeX Live medium scheme g [ ] TeX Live minimal scheme h [ ] TeX Live for Omega users i [ ] teTeX scheme j [ ] XML typesetting scheme
|
Figure 4 displays the TEX Live scheme menu; from here, you choose a “scheme”, which is an overall set of package collections. The default full scheme installs everything available, but you can also choose the basic scheme for a small system, minimal for testing purposes, and medium or teTeX to get something in between. There are also various specialized and country-specific schemes.
You can refine your scheme selection with the ‘standard collections’ and ‘language collections’ menus (figure 5, shown in GUI mode for a change).
Collections are one level more detailed than schemes — in essence, a scheme consists of several collections, a collection consists of one or more packages, and a package (the lowest level grouping in TEX Live) contains the actual TEX macro files, font files, and so on.
If you want more control than the collection menus provide, you can use the tlmgr program after installation (see section 6); using that, you can control the installation at the package level.
The default layout is described in section 2.3, p. 8. The default location of TEXDIR is different between Windows (%PROGRAMFILES%\texlive\2008) and Unix (/usr/local/texlive/2008).
The main reason to change this default is if you lack write permission for the default location. You don’t have to be root or adminstrator to install TEX Live, but you do need write access to the target directory.
A logical alternate choice is a directory under your home directory, especially if you will be the sole user. Use ‘~’ to indicate this, as in ‘~/texlive/2008’.
We recommend including the year in the name, to enable keeping different releases of TEX Live side by side. (You may wish to make a version-independent name such as /usr/local/texlive-cur via a symbolic link, which you can then update after testing the new release.)
Changing TEXDIR in the installer will also change TEXMFLOCAL, TEXMFSYSVAR and TEXMFSYSCONFIG.
TEXMFHOME is the recommended location for personal macro files or packages. The default value is ~/texmf. In contrast to TEXDIR, here a ~ is preserved in the newly-written configuration files, since it usefully refers to the home directory of each individual running TEX. It expands to $HOME on Unix and %USERPROFILE% on Windows.
<P> use letter size instead of A4 by default: [ ]
<F> create all format files: [X] <D> install font/macro doc tree: [X] <S> install font/macro source tree: [X] <L> create symlinks in standard directories: [ ] binaries to: manpages to: info to:
|
Figure 6 displays the text mode options menu. Three of the options here need mentioning:
Now when all these settings are to your liking, you can type ‘I’ to start the installation process. When it is done, skip to section 3.4 to read what else needs to be done, if anything.
Type ‘V’ to select this option. This changes the main menu into something like figure 7.
======================> TeX Live installation procedure <=====================
=======> Note: Letters/digits in <angle brackets> indicate menu items <======= =======> for commands or configurable options <======= <D> directories: TEXDIRW (Writable root): !! default location: /usr/local/texlive/2008 !! is not writable, please select a different one! TEXMFLOCAL (directory for site-wide local files): /usr/local/texlive/texmf-local TEXMFSYSVAR (directory for variable and automatically generated data): /usr/local/texlive/2008/texmf-var TEXMFSYSCONFIG (directory for local config): /usr/local/texlive/2008/texmf-config TEXMFHOME (directory for user-specific files): ~/texmf <O> options: [ ] use letter size instead of A4 by default [X] create all format files <V> set up for installing to hard disk Other actions: <I> start installation for running from DVD <H> help <Q> quit
|
Note the changes: all options about what to install have disappeared, and the directories section now talks about TEXDIRW or writable root. The symlinks option has also disappeared.
The installer will still create various directories and configuration files, but won’t copy texmf, texmf-dist or texmf-doc to hard disk.
Post-install configuration for Unix will be slightly more complicated, because now the directory layout deviates from the default; see section 3.4.
Due to time constraints, this option didn’t make it into the GUI installer, but it is available both for Unix and for Windows. Windows users have to start the installer from a command prompt, see section 3.3.
Section 5 describes a more strictly portable way to run TEX Live, which doesn’t make or require changes in the system’s configuration, but doesn’t allow any configuration either.
Type
If possible, use the GUI installer. This requires the Perl/Tk module ( http://tug.org/texlive/distro.html#perltk); if Perl/Tk is not available, installation continues in text mode.
Force using the text mode installer, even under Windows; you’ll need this if you want a ‘from DVD’ installation, since that is not available in GUI mode.
Specify the installer interface language as its standard two-letter code LL. Currently supported languages: English (en, default), German (de), French (fr), Dutch (nl), Polish (pl), Slovenian (sl) and Vietnamese (vi). The installer tries to determine the right language itself but if it fails, or if the right language is not available, then it uses English as a fallback.
The installer always writes a file texlive.profile to the 2008/tlpkg- or tlpkg subdirectory of your installation. This option tells the installer to re-use such a profile file. Here’s an excerpt:
Thus, using this option you can install in batch mode on subsequent systems, reproducing the choices you made for the original installation.
Specify a non-default source for packages; see below.
The location value can be a url starting with ftp:, http:, or file:/ url, or a plain path. If the given argument is on a local drive (either a path or a file:/ url), the installation type (compressed or live) is automatically determined: if an archive subdirectory with .tar.lzma files is found then it will be used, even if uncompressed files are available as well.
When giving an http: or ftp: location, trailing ‘/’ characters and/or a trailing ‘/tlpkg’ component are ignored. For example, you could choose a particular CTAN mirror with something like: http://ctan.example.org/tex-archive/texlive/tlnet/2008, substituting of course a proper hostname and its particular top-level CTAN path (the list of CTAN mirrors is maintained at http://ctan.org/mirrors) for ctan.example.org/tex-archive. The default is to pick a mirror automatically, using http://mirror.ctan.org; in any case, the chosen host is used for the entire download.
Some post-install may be required.
But on Windows, the installer takes care of everything.
If you elected to create symlinks in standard directories (mentioned in section 3.2.4), then there is no need to edit environment variables.
The directory of the binaries for your platform must be added to the search path. Each supported platform has its own subdirectory under TEXDIR/bin. See figure 3 for the list of subdirectories and corresponding platforms.
You can also add the documentation man and Info directories to their respective search paths, if you want the system tools to find them.
For Bourne-compatible shells such as bash, and using Intel x86 GNU/Linux and a default directory setup as an example, the file to edit might be $HOME/.profile (or another file sourced by .profile, and the lines to add would look like this:
For csh or tcsh, the file to edit is typically $HOME/.cshrc, and the lines to add might look like:
Of course, you may well already have settings somewhere in your “dot” files, and so then the TEX Live directories should simply be merged in as appropriate.
If you want to make these changes globally, or for a user newly added to the system, then you are on your own; there is just too much variation between systems in how and where these things are configured.
Our two hints are: 1) you may want to check for a file /etc/manpath.config and, if present, add lines such as
And 2) check for a file /etc/environment which may define the search path and other default environment variables.
Normally, a TEX Live program consults a file texmf.cnf for the location of the various trees. It looks for this file in a series of locations relative to its own location. However, this scheme breaks down when a program is run from DVD: the DVD is read-only. Some of the paths to be recorded in texmf.cnf are only known at installation time, so this file cannot be on the DVD and must be placed somewhere else. This makes it necessary to define an environment TEXMFCNF variable which tells TEX Live programs in what directory to find this texmf.cnf. It is also still necessary to modify the PATH environment variable, as described before.
At the end of the installation, the installer should have printed a message giving the value to which TEXMFCNF should be set. In case you missed it: this value is $TEXMFSYSVAR/web2c. For the default, /usr/local/texlive/2008/texmf-var/web2c, you need the lines
or, for [t]csh:
The ‘old’ ConTEXt should run out of the box. The new ‘Mark IV’ ConTEXt will require manual setup; see http://wiki.contextgarden.net/Running_Mark_IV.
This is already mentioned implicitly in section 2.3: TEXMFLOCAL (by default, /usr/local/texlive/texmf-local or C:\Program Files\texlive\texmf-local)
is intended for system-wide local fonts and macros; and TEXMFHOME (by default, $HOME/texmf or %USERPROFILE%\texmf), is for personal fonts and macros. These directories are intended to stick around from release to release, and have their content seen automatically by a new TEX Live release. Therefore, it is best to refrain from changing the definition of TEXMFLOCAL to be too far away from the main TEX Live directory, or you will need to manually change future releases.
For both trees, files should be placed in their proper subdirectories; see http://tug.org/tds or consult texmf/web2c/texmf.cnf. For instance, a LATEX class file or package should be placed in TEXMFLOCAL/tex/latex or TEXMFHOME/tex/latex, or a subdirectory thereof.
TEXMFLOCAL requires an up-to-date filename database, or files will not be found. You can update it with the command mktexlsr or use the ‘Reinit file database’ button on the configuration tab of tlmgr in GUI mode.
This is unfortunately a very complicated and messy topic. Forget about it unless you really know your way around blindfolded in a TEX installation. Don’t forget to check first what you get for free: see section 2.6.
A possible alternative is to use XeTEX (see section 2.4), which lets you use operating system fonts without any installation in TEX.
After installing TEX Live as best you can, you naturally want to test it out, so you can start creating beautiful documents and/or fonts.
This section gives some basic procedures for testing that the new system is functional. We give Unix commands here; under Mac OS X and Windows, you’re more likely to run the tests through a graphical interface, but the principles are the same.
A simpler document than sample2e, to reduce the input size if you’re having troubles.
Test if your printer introduces any offsets.
For printing font tables and tests.
Also for font tables, but using plain TEX.
The most canonical (plain) TEX test file of all. You must type ‘\bye’ to the * prompt after ‘tex story.tex’.
If you are new to TEX, or otherwise need help with actually writing TEX or LATEX documents, please visit http://tug.org/begin.html for some introductory resources.
TEX Live has been designed to be shared between different users, and even different systems on a network. With a standard directory layout, no hard paths are configured: the locations for files needed by TEX Live programs are defined relative to the places of those programs. You can see this at work in the configuration file $TEXMFMAIN/web2c/texmf.cnf, which contains lines such as
This means that other systems or other users merely need to add the directory for TEX Live binaries for their platform to their search path.
By the same token, you can also install TEX Live locally and then move the entire hierarchy afterwards to a network location.
Of course, Windows users have different expectations. The directory texmf-doc/source/texlive/texlive-common/w32client contains a sample script install-w32client which creates settings and menu shortcuts for using an existing TEX Live installation on a LAN. It is to be invoked through a batch file install-w32client.bat in the same directory.
You can read more about TEX Live configuration and path searching in section 8.1.
The ‘running from DVD’ option described in section 3.2.5 is fine for your own system, but if you are a guest on somebody else’s system then you would probably like something with minimal side effects.
In the root of the TEX Live DVD, or the texlive subdirectory of the TEX Collection DVD, are a tl-portable script (Unix) and a tl-portable.bat batchfile (Windows) which start up a secondary shell/command prompt with environment settings suitable for directly accessing the TEX Live on the DVD.
When it runs for the first time, some files will be generated in a directory /.tlportable2008, which will take a little time. On subsequent runs, though, it will start almost instantaneously.
The rest of the system will be unaware of TEX Live. If you want your editor to be aware of this TEX Live, then you can start it from a second, parallel, such tl-portable session.
You can also use tl-portable to run TEX Live on a USB stick. In this case, copy all the top-level files and the contents of the bin, texmf, texmf-dist, and tlpkg directories (at least) to the stick. This may take quite a while! If you are copying to a FAT32-formatted USB stick, make sure to dereference symbolic links (cp -L). A texmf-local directory on the stick will also be found and used.
Then run tl-portable from the root of the stick, as above. In this case, the script will notice that the stick is writable and use it for generated files. You could burn the resulting contents of the stick back to DVD if that is more convenient to (for example) give to others.
|
The installer installs a program named tlmgr for managing TEX Live after the initial installation. The programs updmap, fmtutil and texconfig are still included and will be retained in the future, but tlmgr is now the preferred interface. Its capabilities include:
Warning: tlmgr has not been designed for or tested with installations which run from DVD.
tlmgr can be started in GUI mode with
Figure 9 shows the configuration tab.
This example adds several packages, including a new ‘engine’, from a non-default location:
As you see, tlmgr installs dependencies, and takes care of any necessary post-install actions, including updating the filename database and (re)generating formats. (Here we generated new formats for XeTEX.)
This example installs a new language. This also triggers format regeneration:
Updating your entire installation to the latest versions available:
TEX Live has a single installer which runs on both Windows and Unix. This was only possible by dropping support for older Windows versions, so TEX Live can now be installed only on Windows 2000 and later.
Under Windows, the installer does some extra things:
To be complete, a TEX Live installation needs support packages that are not commonly found on a Windows machine. TEX Live provides the missing pieces:
This TEX Live release unfortunately doesn’t offer a preinstalled DVI previewer for Windows. However, you can install dviout by Toshio Oshima from the support/dviout/ directory, which contains also a short README describing how to install and configure dviout for TEX Live. Please read this carefully before installation.
At first, when you preview files with dviout, it will create fonts, because screen fonts were not installed. After a while, you will have created most of the fonts you use, and you will rarely see the font-creation window. More information can be found in the (very good) on-line help.
Urls for some other tools you may consider installing:
The Windows counterpart of a Unix home directory is the %USERPROFILE% directory. Under Windows XP and Windows 2000, this is usually C:/Documents and Settings/<username>, and under Windows Vista C:/Users/<username>. In the texmf.cnf file, and Kpathsea in general, ~ will expand appropriately on both Windows and Unix.
Windows stores nearly all configuration data in its registry. The registry contains a set of hierarchically organized keys, with several root keys. The most important ones for installation programs are HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE, HKCU and HKLM in short. The HKCU part of the registry is in the user’s home directory (see section 7.5). HKLM is normally in a subdirectory of the Windows directory.
In some cases, system information could be obtained from environment variables but for other information, for example the location of shortcuts, it is necessary to consult the registry. Setting environment variables permanently also requires registry access.
In later versions of Windows, a distinction is made between regular users and administrators, where only the latter have free access to the entire operating system. In practice, though, you could better describe these classes of users as unprivileged users and normal users: being an administrator is the rule, not the exception. Nevertheless, we have made an effort to make TEX Live installable without administrative privileges.
If the user is an administrator, shortcuts are created for all users, and the system environment is modified. Otherwise, shortcuts and menu entries are created for the current user, and the user environment is modified. Use the non-admin option to install-tl if you prefer per-user settings even as an administrator.
Regardless of administrator status, the default root of TEX Live proposed by the installer is always under %PROGRAMFILES%. The installer always tests whether the root is writable for the current user.
A problem may arise if the user is not an administrator and TEX already exists in the search path. Since the effective path consists of the system path followed by the user path, the new TEX Live will never get precedence. As a workaround, in this case the installer creates shortcuts to the command-prompt in which the new TEX Live binary directory is prepended to the local searchpath. The new TEX Live will be usable when run in a command-line session started from such a shortcut.
Web2C is an integrated collection of TEX-related programs: TEX itself, Metafont, MetaPost, BibTeX, etc. It is the heart of TEX Live. The home page for Web2C, with the current manual and more, is http://tug.org/web2c.
A bit of history: The original implementation was by Tomas Rokicki who, in 1987, developed a first TEX-to-C system based on change files under Unix, which were primarily the original 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, who returned it to Karl in 2006.
The Web2C system runs on Unix, 32-bit Windows systems, Mac OS X, and other operating systems. It uses Knuth’s original sources for TEX and other basic programs written in the WEB literate programming system and translates them into C source code. The core TEX programs handled in this way are:
Maintaining bibliographies.
troff to MPX (MetaPost pictures).
Expands virtual font references in DVI files.
DVI to MPX (MetaPost pictures).
DVI to human-readable text.
Generic font proofsheets.
Generic to packed fonts.
GF to human-readable text.
MetaPost label typesetting.
Creating typeface families.
Prettyprinting Metafont source.
Creating technical diagrams.
MetaPost label extraction.
Compare modification times.
Creating hyphenation patterns.
Packed to generic fonts.
PK to human-readable text.
Plain text property list to TFM.
Display WEB pool files.
WEB to Pascal.
Typesetting.
TFM to plain text property list.
Virtual font to virtual property list.
Virtual property list to virtual font.
WEB to TEX.
The precise functions and syntax of these programs are described in the documentation of the individual packages and of Web2C itself. However, knowing a few principles governing the whole family of programs will help you take advantage of your Web2C installation.
All programs honor these standard GNU options:
print basic usage summary.
print detailed progress report.
print version information, then exit.
For locating files the Web2C programs use the path searching library Kpathsea ( http://tug.org/kpathsea). This library uses a combination of environment variables and a configuration files to optimize searching the (huge) collection of TEX files. Web2C can look at many directory trees simultaneously, which is useful in maintaining TEX’s standard distribution and local and personal extensions in 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 under that root.
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 63) 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.
A search path can come from many sources. In the order in which Kpathsea uses them:
You can see each of these values for a given search path by using the debugging options (see “Debugging actions” on page 67).
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.
A configuration file fragment illustrating most of these points is shown below:
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.
If the highest-priority search path (see “Path sources” on page 58) 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
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 ‘:’.
A useful feature is brace expansion, which means that, for instance, v{a,b}w expands to vaw:vbw. Nesting is allowed. This is used to implement multiple TEX hierarchies, by assigning a brace list to $TEXMF. For example, in texmf.cnf, the following definition (appproximately; there are actually even more trees) is made:
Using this you can then write something like
which means that, after looking in the current directory, the $TEXMFHOME/tex, $TEXMFLOCAL/tex, $TEXMFVAR/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, 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.
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.
The following list summarizes the 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.
Subdirectory expansion (can occur anywhere in a path, except at its beginning).
Start of comment.
Continuation character (allows multi-line entries).
Search only database to locate file, do not search the disk.
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 plain text “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 confirm to DOS 8.3 filename conventions in source files.
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
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.
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).
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 most common options are described next.
Set the resolution to num; this only affects ‘gf’ and ‘pk’ lookups. ‘-D’ is a synonym, for compatibility with dvips. Default is 600.
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 known to Kpathsea, such as
tex or enc files. Run kpsewhich --help for a list.
Set the mode name to string; this only affects ‘gf’ and ‘pk’ lookups. No default: any mode
will be found.
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.
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.
Set the program name to name. This can affect the search paths via the .progname feature.
The default is kpsewhich.
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.
sets the debugging options to num.
Let us now have a look at Kpathsea in action. Here’s a straightforward search:
By the way, that last is a BibTeX bibliography database for TUGBoat articles.
Next we turn our attention to dvips’s header and configuration files. We first look at one of the commonly used files, the general prologue tex.pro for TEX support, before turning our attention to the generic configuration file (config.ps) and the PostScript font map psfonts.map — as of 2004, map and encoding files have their own search paths and new location in texmf trees. As the ‘.ps’ suffix is ambiguous we have to specify explicitly which type we are considering (dvips config) for the file config.ps.
We now take a closer look at the URW Times PostScript support files. The prefix for these in the standard font naming scheme is ‘utm’. The first file we look at is the configuration file, which contains the name of the map file:
It should be evident from these 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.
Sometimes it is necessary to investigate how a program resolves file references. To make this practical, Kpathsea offers various levels of debugging output:
stat calls (disk lookups). When running with an up-to-date ls-R database this should almost give no output.
References to hash tables (such as ls-R databases, 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.
Variable values.
A value of -1 will set all the above options; in practice, this is usually the most convenient.
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.
This little file only uses the font cmr10, so let us look at how dvips prepares the PostScript file (we want to use the Type 1 version of the Computer Modern fonts, hence the option -Pcms).
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
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
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]
|
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.
At this point dvips identifies itself to the user:
After having found the file in question, dvips outputs the 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” (no bitmaps needed):
Another useful feature of Web2C is its possibility to control a number of memory parameters (in particular, array sizes) via the runtime file texmf.cnf read by Kpathsea. The memory settings can be found in Part 3 of that file in the TEX Live distribution. The more important are:
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.
Extra space for “large” TEX data structures: boxes, glue, breakpoints, etc. Especially useful if you use PI CTEX.
Number of words for font information available for TEX. This is more or less the total size of all TFM files read.
Additional space for the hash table of control sequence names. Only ≈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. The default value of hash_extra is 50000.
Of course, this facility is no substitute for truly dynamic arrays and memory allocation, but since these are extremely difficult to implement in the present TEX source, these runtime parameters provide a practical compromise allowing some flexibility.
TEX Live is a joint effort by virtually all of the TEX user groups. This edition of TEX Live was overseen by Karl Berry. The other principal contributors, past and present, are listed below.
Builders of the binaries: Tigran Aivazian (x86_64-linux), Tim Arnold (hppa-hpux), Randy Au (amd64-freebsd), Edd Barrett (i386-openbsd), Karl Berry (i386-linux), Akira Kakuto (win32), Dick Koch (universal-darwin), Manfred Lotz (i386-freebsd), Norbert Preining (alpha-linux), Arthur Reutenauer (sparc-linux), Thomas Schmitz (powerpc-linux), Apostolos Syropoulos (i386-solaris), Vladimir Volovich (powerpc-aix, sparc-solaris), Olaf Weber (mips-irix). For information on the TEX Live build process, see http://tug.org/texlive/build.html.
Documentation and translation updates: Karl Berry (English), Daniel Flipo (French), Klaus Höppner (German), Petr Sojka & Jan Busa (Czech/Slovak), Boris Veytsman (Russian), Staszek Wawrykiewicz (Polish). The TEX Live documentation web page is http://tug.org/texlive/doc.html.
Of course the most important acknowledgement must go to Donald Knuth, first for inventing TEX, and then for giving it to the world.
Discussion began in late 1993 when the Dutch TEX Users Group was starting work on its 4AllTEX CD for MS-DOS users, and it was hoped at that time to issue a single, rational, CD for all systems. This was too ambitious a target for the time, but it did spawn not only the very successful 4AllTEX CD, but also the TUG Technical Council working group on a TEX Directory Structure ( http://tug.org/tds), which specified how to create consistent and manageable collections of TEX support files. A complete draft of the TDS was published in the December 1995 issue of TUGboat, and it was clear from an early stage that one desirable product would be a model structure on CD. The distribution you now have is a very direct result of the working group’s deliberations. It was also clear that the success of the 4AllTEX CD showed that Unix users would benefit from a similarly easy system, and this is the other main strand of TEX Live.
We first undertook to make a new Unix-based TDS CD in the autumn of 1995, and quickly identified Thomas Esser’s teTEX as the ideal setup, as it already had multi-platform support and was built with portability across file systems in mind. Thomas agreed to help, and work began seriously at the start of 1996. The first edition was released in May 1996. At the start of 1997, Karl Berry completed a major new release of Web2c, which included nearly all the features which Thomas Esser had added in teTEX, and we decided to base the 2nd edition of the CD on the standard Web2C, with the addition of teTEX’s texconfig script. The 3rd edition of the CD was based on a major revision of Web2C, 7.2, by Olaf Weber; at the same time, a new revision of teTEX was being made, and TEX Live included almost all of its features. The 4th edition followed the same pattern, using a new version of teTEX, and a new release of Web2C (7.3). The system now included a complete Windows setup.
For the 5th edition (March 2000) many parts of the CD were revised and checked, updating hundreds of packages. Package details were stored in XML files. But the major change for TEX Live 5 was that all non-free software was removed. Everything in TEX Live is now intended to be compatible with the Debian Free Software Guidelines ( http://www.debian.org/intro/free); we have done our best to check the license conditions of all packages, but we would very much appreciate hearing of any mistakes.
The 6th edition (July 2001) had much more material updated. The major change was a new install concept: the user could select a more exact set of needed collections. Language-related collections were completely reorganized, so selecting any of them installs not only macros, fonts, etc., but also prepares an appropriate language.dat.
The 7th edition of 2002 had the notable addition of Mac OS X support, and the usual myriad of updates to all sorts of packages and programs. An important goal was integration of the source back with teTEX, to correct the drift apart in versions 5 and 6.
In 2003, with the continuing flood of updates and additions, we found that TEX Live had grown so large it could no longer be contained on a single CD, so we split it into three different distributions (see section 2.1, p. 7). In addition:
2004 saw many changes:
.map files are now searched for in subdirectories of fonts/map only (in each texmf tree), along the TEXFONTMAPS path. Similarly, .enc files are now searched for in subdirectories of fonts/enc only, along the ENCFONTS path. updmap will attempt to warn about problematic files.
For methods of handling this and other information, please see http://tug.org/texlive/mapenc.html.
It also means it’s more important than ever to use the ifpdf package (works with both plain and LATEX) or equivalent code, because simply testing whether \pdfoutput or some other primitive is defined is not a reliable way to determine if PDF output is being generated. We made this backward compatible as best we could this year, but next year, \pdfoutput may be defined even when DVI is being written.
See the Web2C manual for more: texmf/doc/web2c.
2005 saw the usual huge number of updates to packages and programs. The infrastructure stayed relatively stable from 2004, but inevitably there were some changes there as well:
In 2006–2007, the major new addition to TEX Live was the XeTEX program, available as the xetex and xelatex programs; see http://scripts.sil.org/xetex.
MetaPost also received a notable update, with more planned for the future ( http://tug.org/metapost/articles), likewise pdfTEX ( http://tug.org/applications/pdftex).
The TEX .fmt (high-speed format) and the similar files for MetaPost and Metafont are now stored in subdirectories of texmf/web2c, instead of in the directory itself (although the directory is still searched, for the sake of existing .fmt’s). The subdirectories are named for the ‘engine’ in use, such as tex or pdftex or xetex. This change should be invisible in normal use.
The (plain) tex program no longer reads %& first lines to determine what format to run; it is the pure Knuthian TEX. (LATEX and everything else do still read %& lines).
Of course the year also saw (the usual) hundreds of other updates to packages and programs. As usual, please check CTAN ( http://www.ctan.org) for updates.
Internally, the source tree is now stored in Subversion, with a standard web interface for viewing the tree, as linked from our home page. Although not visible in the final distribution, we expect this will provide a stable development foundation for future years.
Finally, in May 2006 Thomas Esser announced that he would no longer be updating teTEX ( http://tug.org/tetex). As a result, there was been a surge of interest in TEX Live, especially among GNU/Linux distributors. (There is a new tetex installation scheme in TEX Live, which provides an approximate equivalent.) We hope this will eventually translate to improvements in the TEX environment for everyone.
Final note on the past: all releases of TEX Live, along with ancillary material such as CD labels, are available at ftp://tug.org/historic/systems/texlive.
In 2008, the entire TEX Live infrastructure was redesigned and reimplemented. Complete information about an installation is now stored in a plain text file tlpkg/texlive.tlpdb.
Among other things, this finally makes possible upgrading a TEX Live installation over the Internet after the initial installation, a feature MiKTEX has provided for many years. We expect to regularly update new packages as they are released to CTAN.
The major new engine LuaTEX ( http://luatex.org) is included; besides a new level of flexibility in typesetting, this provides an excellent scripting language for use both inside and outside of TEX documents.
Support among Windows and the Unix-based platforms is now much more uniform. In particular, most Perl and Lua scripts are now available on Windows, using the Perl internally distributed with TEX Live.
The new tlmgr script (section 6) is the general interface for managing TEX Live after the initial installation. It handles package updates and consequent regeneration of formats, map files, and language files, optionally including local additions.
With the advent of tlmgr, the texconfig actions to edit the format and hyphenation configuration files are now disabled.
The xindy indexing program ( http://xindy.sourceforge.net/) is now included on most platforms.
The kpsewhich tool can now report all matches for a given file (option –all) and limit matches to a given subdirectory (option –subdir).
The dvipdfmx program now includes functionality to extract bounding box information, via the command name extractbb; this was one of the last features provided by dvipdfm not in dvipdfmx.
The font aliases Times-Roman, Helvetica, and so on have been removed. Different packages expected them to behave differently (in particular, to have different encodings), and there was no good way to resolve this.
The platex format has been removed, to resolve a name conflict with a completely different Japanese platex; the polski package is now the main Polish support.
Internally, the WEB string pool files are now compiled into the binaries, to ease upgrades.
TEX Live is not perfect! (And never will be.) We intend to continue to release new versions, and would like to provide more help material, more utilities, more installation programs, and (of course) an ever-improved and better-checked tree of macros and fonts. This work is all done by hard-pressed volunteers in their limited spare time, and a great deal remains to be done. Please see http://tug.org/texlive/contribute.html.
Please send corrections, suggestions, and offers of help to:
Happy TEXing!