Go to the first, previous, next, last section, table of contents.

Top-level directories

The directories under the `texmf' root identify the major components of a TeX system (see Section section Summary for a summary). A site may omit any unneeded directories.

Although the TDS by its nature can specify precise locations only for implementation-independent files, we recognize that installers may well wish to place other files under `texmf' to simplify administration of the TeX tree, especially if it is maintained by someone other than the system administrator. Therefore, additional top-level directories may be present.

The top-level directories specified by the TDS are:


TeX macro files shall be stored in separate directories, segregated by TeX format and package name (we use `format' in its traditional TeX sense to mean a usefully `\dump'-able package):



Font files shall be stored in separate directories, segregated by file type, font supplier, and typeface (`PK' and `GF' files need additional structure, as detailed in the next section):


Some concrete examples:


For complete supplier and typeface name lists, consult Filenames for TeX fonts (see Appendix section Related references).

Font bitmaps

Font bitmap files require two characteristics in addition to the above to be uniquely identifiable: (1) the type of device (i.e., mode) for which the font was created; (2) the resolution of the bitmap.

Following common practice, the TDS segregates fonts with different device types into separate directories. See `modes.mf' in Appendix section Related references for recommended mode names.

Some printers operate at more than one resolution (e.g., at 300dpi and 600dpi), but each such resolution will necessarily have a different mode name. Nothing further is needed, since implicit in the TeX system is the assumption of a single target resolution.

Two naming strategies are commonly used to identify the resolution of bitmap font files. On systems that allow long filenames (and in the original METAFONT program itself), the resolution is included in the filename (e.g., `cmr10.300pk'). On systems which do not support long filenames, fonts are generally segregated into directories by resolution (e.g., `dpi300/cmr10.pk').

Because the TDS cannot require long filenames, we must use the latter scheme for naming fonts. So we have two more subdirectory levels under `pk' and `gf':


Implementations may provide extensions to the basic naming scheme, such as long filenames (as in the original METAFONT) and font library files (as in emTeX's `.fli' files), provided that the basic scheme is also supported.

Valid font bitmaps

The TWG recognizes that the use of short filenames has many disadvantages. The most vexing is that it results in the creation of dozens of different files with the same name. At a typical site, `cmr10.pk' will be the filename for Computer Modern Roman 10pt at 5--10 magnifications for 2--3 modes. (Section section Duplicate filenames discusses duplicate filenames in general.)

To minimize this problem, we strongly recommend that `PK' files contain enough information to identify precisely how they were created: at least the mode, base resolution, and magnification used to create the font.

This information is easy to supply: a simple addition to the local modes used for building the fonts with METAFONT will automatically provide the required information. If you have been using a local modes file derived from (or that is simply) `modes.mf' (see Appendix section Related references), the required information is already in your `PK' files. If not, a simple addition based on the code found in `modes.mf' can be made to your local modes file and the `PK' files rebuilt.

Non-font METAFONT files

Most METAFONT input files are font programs or parts of font programs and are thus covered by the previous section. However, a few non-font input files do exist. Such files shall be stored in:


`package' is the name of a METAFONT package (for example, `mfpic').

The TDS reserves the following `package' names:


MetaPost is a picture-drawing language developed by John Hobby, derived from Knuth's METAFONT. Its primary purpose is to output Encapsulated PostScript instead of bitmaps.

MetaPost input files and the support files for MetaPost-related utilities shall be stored in:


`package' is the name of a MetaPost package. At the present writing none exist, but the TWG thought it prudent to leave room for contributed packages that might be written in the future.

The TDS reserves the following `package' names:


BibTeX-related files shall be stored in:


The `bib' directory is for BibTeX database (`.bib') files, the `bst' directory for style (`.bst') files.

`package' is the name of a BibTeX package. The TDS reserves the following `package' names (the same names are reserved under both `bib' and `bst'):


Most packages come with some form of documentation: user manuals, example files, programming guides, etc. In addition, many independent files not part of a macro or other package describe various aspects of the TeX system.

The TDS specifies that these additional documentation files shall be stored in a structure that parallels to some extent the `fonts' and `tex' directories, as follows:


`category' identifies the general topic of documentation that resides below it; for example, a TeX format name (`latex'), program name (`bibtex', `tex'), language (`french', `german'), or other system components (`web', `fonts').

The TDS reserves the following categories:

The `doc' directory is intended for implementation-independent and operating system-independent documentation files. Implementation-dependent files shall be stored elsewhere, as provided for by the implementation and/or TeX administrator (for example, VMS help files under `texmf/vms/help').

The documentation directories may contain TeX sources, DVI files, PostScript files, text files, example input files, or any other useful documentation format(s).

See Section section Documentation tree summary for a summary.


New programs that are extensions of old ones shall use a new top-level directory name for their extension-specific input files. The new directory shall have the same general structure as the top-level directory of the original program, and the new program almost certainly should search the original top-level directory.

For example, several variants of TeX that recognize additional commands have been released. Input files that use these new commands cannot be placed in the top-level `tex' directory, since the original TeX program cannot read them. So they must go in a new directory, with the same package structure as `tex' (see Section section Macros).

Using e-TeX as an example, we have the following:

These same principles hold for PDFTeX, Omega, and (most probably) future variants of TeX or METAFONT.

Go to the first, previous, next, last section, table of contents.