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

# Bits and pieces of TeX

## What is a DVI file?

A DVI file (that is, a file with the type or extension `.dvi`) is TeX's main output file, using TeX in its broadest sense to include LaTeX, etc. `DVI' is supposed to be an acronym for DeVice-Independent, meaning that the file can be printed on almost any kind of typographic output device. The DVI file is designed to be read by a driver (DVI drivers) to produce further output designed specifically for a particular printer (e.g., a LaserJet) or to be used as input to a previewer for display on a computer screen. DVI files use TeX's internal coding; a TeX input file should produce the same DVI file regardless of which implementation of TeX is used to produce it.

A DVI file contains all the information that is needed for printing or previewing except for the actual bitmaps or outlines of fonts, and possibly material to be introduced by means of `\special` commands.

The canonical reference for the structure of a DVI file is the source of dvitype (`systems/knuth/texware/dvitype.web`).

## What is a driver?

A driver is a program that takes as input a `dvi` file (DVI files) and (usually) produces a file that can be sent to a typographic output device, called a printer for short.

A driver will usually be specific to a particular printer, although any PostScript printer ought to be able to print the output from a PostScript driver.

As well as the DVI file, the driver needs font information. Font information may be held as bitmaps or as outlines, or simply as a set of pointers into the fonts that the printer itself `has'. Each driver will expect the font information in a particular form. For more information on the forms of fonts, see questions `pk` files, `tfm` files, virtual fonts and Using PostScript fonts with TeX.

## What are PK files?

PK files (packed raster) contain font bitmaps. The output from METAFONT includes a generic font (GF) file and the utility gftopk produces the PK file from that. There are a lot of PK files, as one is needed for each font, that is each magnification (size) of each design (point) size for each weight for each family. Further, since the PK files for one printer do not necessarily work well for another, the whole set needs to be duplicated for each printer type at a site. As a result, they are often held in an elaborate directory structure, or in `font library files', to regularise access.

## What are TFM files?

TFM stands for TeX font metrics, and TFM files hold information about the sizes of the characters of the font in question, and about ligatures and kerns within that font. One TFM file is needed for each font used by TeX, that is for each design (point) size for each weight for each family; one TFM file serves for all magnifications, so that there are (typically) fewer TFM files than there are PK files. The important point is that TFM files are used by TeX (LaTeX, etc.), but are not, generally, needed by the printer driver.

## Virtual fonts

Virtual fonts for TeX were first implemented by David Fuchs in the early days of TeX, but for most people they started when Knuth redefined the format, and wrote some support software, in 1989. Virtual fonts provide a way of telling TeX about something more complicated than just a one-to-one character mapping. The entities you define in a virtual font look like characters to TeX (they appear with their sizes in a font metric file), but the DVI processor may expand them to something quite different. You can use this facility just to remap characters, to make a composite font with glyphs drawn from several sources, or to build up an effect in arbitrarily complicated ways - a virtual font may contain anything which is legal in a DVI file. In practice, the most common use of virtual fonts is to remap PostScript fonts (see font metrics) or to build `fake' maths fonts.

It is important to realise that TeX itself does not see virtual fonts; for every virtual font read by the DVI driver there is a corresponding TFM file read by TeX. Virtual fonts are normally created in a single ASCII `vpl` (Virtual Property List) file, which includes both sets of information. The vptovf program is then used to the create the binary TFM and VF files. The commonest way (nowadays) of generating `vpl` files is to use the fontinst package, which is described in detail together with the discussion of PostScript font metrics. `fonts/utilities/qdtexvpl` is another utility for creating ad-hoc virtual fonts.

## `\special` commands

TeX provides the means to express things that device drivers can do, but about which TeX itself knows nothing. For example, TeX itself knows nothing about how to include PostScript figures into documents, or how to set the colour of printed text; but some device drivers do.

Such things are introduced to your document by means of `\special` commands; all that TeX does with these commands is to expand their arguments and then pass the command to the DVI file. In most cases, there are macro packages provided (often with the driver) that provide a comprehensible interface to the `\special`; for example, there's little point including a figure if you leave no gap for it in your text, and changing colour proves to be a particularly fraught operation that requires real wizardry. LaTeX2e has standard graphics and colour packages that make file inclusion, rotation, scaling and colour via `\special`s all easy.

The allowable arguments of `\special` depend on the device driver you're using. Apart from the examples above, there are `\special` commands in the emTeX drivers (e.g., dvihplj, dviscr, etc.) that will draw lines at arbitrary orientations, and commands in dvitoln03 that permit the page to be set in landscape orientation.

## Documented LaTeX sources (`.dtx` files)

LaTeX2e, and many support macro packages, are now written in a literate programming style, with source and documentation in the same file. This format, known as `doc', was originated by Frank Mittelbach. The documented sources conventionally have the suffix `.dtx`, and should normally be stripped of documentation before use with LaTeX. Alternatively you can run LaTeX on a `.dtx` file to produce a nicely formatted version of the documented code. An installation script (with suffix `.ins`) is usually provided, which needs the standard LaTeX2e docstrip package (among other things, the installation process strips all the comments that make up the documentation for speed when loading the file into a running LaTeX system). Several packages can be included in one `.dtx` file, with conditional sections, and there facilities for indices of macros etc. Anyone can write `.dtx` files; the format is explained in The LaTeX Companion (see books on TeX). There are no programs yet to assist in composition.

`.dtx` files are not used by LaTeX after they have been processed to produce `.sty` or `.cls` (or whatever) files. They need not be kept with the working system; however, for many packages the `.dtx` file is the primary source of documentation, so you may want to keep `.dtx` files elsewhere.

## What are the EC fonts?

A font consists of a number of glyphs. In order that the glyphs may be printed, there has to be some way of accessing them; in TeX they're arranged in a numerical order called an encoding, and their number in the encoding is used. For various reasons, Knuth chose rather eccentric encodings; in particular, he chose different encodings for different fonts.

When TeX version 3 arrived, some at least of the reasons for the eccentricity of Knuth's encodings went away, and at TUG's Cork meeting, an encoding for a set of 256 glyphs, for use in TeX text, was defined. The intention was that these glyphs should cover `most' European languages, in the sense of including all accented letters needed. (Knuth's CMR fonts missed things necessary for Icelandic, Polish and Sami, for example, but the Cork fonts have them.) LaTeX2e refers to the Cork encoding as T1, and provides the means to use fonts thus encoded to avoid problems with the interaction of accents and hyphenation (see hyphenation of accented words).

The only METAFONT-fonts that conform to the Cork encoding are the EC fonts (available as `fonts/ec`). They look CM-like, and are now regarded as `stable' (in the same sense that the CM fonts are stable: their metrics are unlikely ever to change). Their serious disadvantage for the casual user is that they are large - each EC font is roughly twice the size of the corresponding CM font; what's more, until corresponding fonts for mathematics are produced, the CM fonts must be retained.

The EC fonts supersede the experimental DC fonts, which have now been removed from the archives. They are distributed with a set of `Text Companion' (TC) fonts that provide glyphs for symbols commonly used in text. The TC fonts are encoded according to the LaTeX TS1 encoding, and are not viewed as `stable' in the same way as are the EC fonts are.

The Cork encoding is also implemented by the PSNFSS system, for PostScript fonts.

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