| groff_tmac(5) | File Formats Manual | groff_tmac(5) |
groff_tmac - macro files in the GNU roff typesetting system
Definitions of macros, strings, and registers for use in a roff(7) document can be collected into macro files, roff input files designed to produce no output themselves but instead ease the preparation of other roff documents. There is no syntactical difference between a macro file and any other roff document; only its purpose distinguishes it. When a macro file is installed at a standard location, named according to a certain convention, and suitable for use by a general audience, it is termed a macro package. Macro packages can be loaded by supplying the -m option to troff(1) or a groff front end.
Each macro package stores its macro, string, and register definitions in one or more tmac files. This name originated in early Unix culture as an abbreviation of “troff macros”.
A macro file must have a name in the form name.tmac (or tmac.name) and be placed in a “tmac directory” to be loadable with the -mname option. Section “Environment” of troff(1) lists these directories. Alternatively, a groff document requiring a macro file can load it with the mso (“macro source”) request.
Like any other roff document, a macro file can use the “so” request (“source”) to load further files relative to its own location.
Macro files are named for their most noteworthy application, but a macro file need not define any macros. It can restrict itself to defining registers and strings or invoking other groff requests. It can even be empty.
Macro packages come in two varieties; those which assume responsibility for page layout and other critical functions (“major” or “full-service”) and those which do not (“supplemental” or “auxiliary”). GNU roff provides most major macro packages found in AT&T and BSD Unix systems, an additional full-service package, and many supplemental packages. Multiple full-service macro packages cannot be used by the same document. Auxiliary packages can generally be freely combined, though attention to their use of the groff language name spaces for identifiers (particularly registers, macros, strings, and diversions) should be paid. Name space management was a significant challenge in AT&T troff; groff's support for arbitrarily long identifiers affords few excuses for name collisions, apart from attempts at compatibility with the demands of historical documents.
Because readers of man pages often do not know in advance which macros are used to format a given document, a wrapper is available.
The packages in this section provide a complete set of macros for writing documents of any kind, up to whole books. They are similar in functionality; it is a matter of taste which one to use.
For Western languages, the localization file sets the hyphenation mode and loads hyphenation patterns and exceptions. Localization files can also adjust the date format and provide translations of strings used by some of the full-service macro packages; alter the input encoding (see the next section); and change the amount of additional inter-sentence space. For Eastern languages, the localization file defines character classes and sets flags on them. By default, troffrc loads the localization file for English.
groff provides the following localization files.
Because different input character codes constitute valid GNU troff input on ISO and EBCDIC systems, the latin macro files cannot be used on EBCDIC systems, and cp1047 cannot be used on ISO systems.
The macro packages in this section are not intended for stand-alone use, but can add functionality to any other macro package or to plain (“raw”) groff documents.
.am PSPIC
. vpt 0
\h'(\\n[ps-offset]u + \\n[ps-deswid]u)'
. sp -1
. vpt 1
..
.am pspic*error-hook
. ab
..
AT&T nroff and troff were implemented before the conventions of the modern C getopt(3) call evolved, and used a naming scheme for macro packages that looks odd to modern eyes. Macro packages were typically loaded using the -m option to the formatter; when directly followed by its argument without an intervening space, this looked like a long option preceded by a single minus—a sensation in the computer stone age. Macro packages therefore came to be known by names that started with the letter “m”, which was omitted from the name of the macro file as stored on disk. For example, the manuscript macro package was stored as tmac.s and loaded with the option -ms.
groff commands permit space between an option and its argument. The syntax “groff -m s” makes the macro file name more clear but may surprise users familiar with the original convention, unaware that the package's “real” name was “s” all along. For such packages of long pedigree, groff accommodates different users' expectations by supplying wrapper macro files that load the desired file with mso requests. Thus, all of “groff -m s”, “groff -m ms”, “groff -ms”, and “groff -mms” serve to load the manuscript macros.
Wrappers are not provided for packages of more recent vintage, like www.tmac.
As noted in passing above, AT&T troff named macro files in the form tmac.name. It has since become conventional in operating systems to use a suffixed file name extension to suggest a file type or format.
The traditional method of employing a macro package is to specify the -m package option to the formatter, which then reads package's macro file prior to any input files. Historically, package was sought in a file named tmac.package (that is, with a “tmac.” prefix). GNU troff searches for package.tmac in the macro path; if not found, it looks for tmac.package instead, and vice versa.
Alternatively, one could include a macro file by using the request “.so file-name” in the document; file-name is resolved relative to the location of the input document. GNU troff offers an improved feature in the similar request “mso package-file-name”, which searches the macro path for package-file-name. Because its argument is a file name, its “.tmac” component must be included for the file to be found; however, as a convenience, if opening it fails, mso strips any such suffix and tries again with a “tmac.” prefix, and vice versa.
If a sourced file requires preprocessing, for example if it includes tbl tables or eqn equations, the preprocessor soelim(1) must be used. This can be achieved with a pipeline or, in groff, by specifying the -s option to the formatter (or front end). man(1) librarian programs generally call soelim automatically. (Macro packages themselves generally do not require preprocessing.)
A roff(7) document is a text file that is enriched by predefined formatting constructs, such as requests, escape sequences, strings, numeric registers, and macros from a macro package. These elements are described in roff(7).
To give a document a personal style, it is most useful to extend the existing elements by defining some macros for repeating tasks; the best place for this is near the beginning of the document or in a separate file.
Macros without arguments are just like strings. But the full power of macros occurs when arguments are passed with a macro call. Within the macro definition, the arguments are available as the escape sequences \$1, ..., \$9, \$[...], \$*, and \$@, the name under which the macro was called is in \$0, and the number of arguments is in register \n[.$]; see groff(7).
Writing groff macros is easy when the escaping mechanism is temporarily disabled. In groff, this is done by enclosing the macro definition(s) within a pair of .eo and .ec requests. Then the body in the macro definition is just like a normal part of the document — text enhanced by calls of requests, macros, strings, registers, etc. For example, the code above can be written in a simpler way by
.eo
.ds midpart was called with the following
.de print_args
\f[I]\$0\f[] \*[midpart] \n[.$] arguments:
\$*
..
.ec
Unfortunately, draft mode cannot be used universally. Although it is good enough for defining normal macros, draft mode fails with advanced applications, such as indirectly defined strings, registers, etc. An optimal way is to define and test all macros in draft mode and then do the backslash doubling as a final step; do not forget to remove the .eo request.
.de Text
. if (\\n[.$] == 0) \
. return
. nop \)\\$*\)
..
.de c
..
.c This is like a comment line.
Diversions can be used to implement quite advanced programming constructs. They are comparable to pointers to large data structures in the C programming language, but their usage is quite different.
In their simplest form, diversions are multi-line strings, but diversions get their power when used dynamically within macros. The (formatted) information stored in a diversion can be retrieved by calling the diversion just like a macro.
Most of the problems arising with diversions can be avoided if you remember that diversions always store complete lines. Using diversions when the line buffer has not been flushed produces strange results; not knowing this, many people get desperate about diversions. To ensure that a diversion works, add line breaks at the right places. To be safe, enclose everything that has to do with diversions within a pair of line breaks; for example, by explicitly using .br requests. This rule should be applied to diversion definition, both inside and outside, and to all calls of diversions. This is a bit of overkill, but it works nicely.
(If you really need diversions which should ignore the current partial line, use environments to save the current partial line and/or use the .box request.)
The most powerful feature using diversions is to start a diversion within a macro definition and end it within another macro. Then everything between each call of this macro pair is stored within the diversion and can be manipulated from within the macros.
This document was written by Bernd Warken, Werner Lemberg, and G. Branden Robinson.
Groff: The GNU Implementation of troff, by Trent A. Fisher and Werner Lemberg, is the primary groff manual. You can browse it interactively with “info groff”.
The Filesystem Hierarchy Standard is maintained by the Linux Foundation.
| 31 March 2024 | groff 1.23.0 |