The path from a TeX or troff source file to your printer is surprisingly complex. It's often useful to know exactly what is happening. It isn't knowledge that will help you "do anything" (i.e., you won't be able to make fancier documents), but it will come in handy - particularly when something goes wrong.
For TeX and troff , the processing is surprisingly similar, as shown in Figure 43.1 .
You start with a source file, containing your text and markup. First, it's processed by one or more preprocessors to handle figures, tables, and so on. Preprocessors are essential to troff ; they aren't used that often with TeX, but they do exist. What a preprocessor does is provide a simpler language for formatting complex elements like tables, equations, or figures; the preprocessor interprets this language, and outputs the low-level troff requests needed to implement the desired result.
The most commonly used preprocessors are listed in Table 43.1
After going through the preprocessors, you're left with a "pure" document that consists of basic commands and macros. This is fed into the TeX or troff processor, which starts by adding a "macro definition file" to the beginning of your text. The processor then produces a device independent file; this is a generic representation of your document in terms of low-level commands. You can't do much with device-independent output except (possibly) inspect it for bugs.
Before going on, a word about macro files.
A macro file is nothing
more than a file of troff
or TeX commands that defines macros,
sets up page borders, headers, footers, and so on.
Basically, a macro
file defines the look of your document, together with any
"high-level" (e.g., paragraph or heading) commands that you use.
, these files are kept in the directory /usr/lib/tmac
and have filenames like tmac.name
; when you invoke troff
you give the option
Since the macro file is nothing more than another file of troff commands, there's no reason you can't just stick it onto the front of your source file. That is, the command:
is completely equivalent to
Why would you want to insert the macro file "by hand"? You usually don't; but if you're debugging a new macro file, or if you're defining one or two special macros for your own purposes, adding the macros by hand can be a useful trick.
or TeX has finished grinding your file into
dust, you're left with a device independent (or DVI) file. I'm really
stretching terminology here, but (conceptually) this is the right way
to think. The problem is that there are two versions of
: device independent troff
, or ditroff
is the only one that really
generates device independent output: generic output that can
easily be translated into a file for any printer. The old troff
generates output for a C/A/T phototypesetter, an archaic beast that
probably exists only in museums. C/A/T output is not device
independent at all: it reflects lots of C/A/T idiosyncracies
that are a pain to deal with. However, conceptually, you can think of
C/A/T output as device independent output with a botched
design; it's certainly independent of any device you're likely to see!
The concept of device independent output really originated with TeX; TeX's DVI files are very well defined and quite elegant. Unfortunately, they're completely different from ditroff 's DVI files. And if you're using some "third-party" version of troff , like SoftQuad's sqtroff or the FSF's groff , you probably have yet another kind of device independent output to deal with. Although they sound like they're standardized, device independent formats aren't.
At any rate, once your processor is finished, its device independent output (of whatever type) needs to be converted to commands for your printer. This is done by a postprocessor. The name of the postprocessor depends entirely on what kind of printer you're using, which version of TeX or troff you're using, and where you bought your software. One such program is psroff , which is part of Adobe's transcript package; it converts ditroff output to PostScript.
Although this may seem complex, most of this is invisible to you; most often, you'll invoke troff through a script that will handle all the postprocessing (and possibly even the preprocessing) for you. However, when you need to debug something that isn't working, there's no substitute for understanding the machinery.