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).
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.
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.
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 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 commandsTeX 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 \specials 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.
.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.
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 (hyphenation of accented words).
The only METAFONT-fonts that conform to the Cork encoding are the DC fonts (available as fonts/dc; ensure you have version 1.2, patch level 1, released in December 1995, or later). They look CM-like, and should be regarded as an interim version of a hypothetical set of EC fonts (which, it is hoped, will be available some time in 1997). Their serious disadvantage for the casual user is that they are large - each DC 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 Cork encoding is also implemented by the PSNFSS system, for PostScript fonts.