This document is intended as a reference. The primary groff manual, Groff: The GNU Implementation of troff, by Trent A. Fisher and Werner Lemberg, is a better resource for learners, containing many examples and much discussion. It is written in Texinfo; you can browse it interactively with "info groff". Additional formats, including plain text, HTML, DVI, and PDF, may be available in /usr/share/doc/groff-base.
groff is also a name for an extended dialect of the roff language. We use "roff" to denote features that are universal, or nearly so, among implementations of this family. We apply the term "groff" to the language documented here, the GNU implementation of the overall system, the project that develops that system, and the command of that name.
GNU troff, installed on this system as is the formatter: a program that reads device and font descriptions ( interprets the groff language expressed in text input files, and translates that input into a device-independent output format ( that is usually then post-processed by an output driver to produce PostScript, PDF, HTML, DVI, or terminal output.
Additionally, the Control+A character (U+0001) in text is interpreted as a leader (see below).
Horizontal white space characters are significant to groff, but trailing spaces on text lines are ignored.
A backslash \ immediately followed by a newline, sometimes discussed as \newline, suppresses the effects of that newline on the input. The next input line thus retains the classification of its predecessor as a control or text line. \newline is useful for managing line lengths in the input during document maintenance; you can break an input line in the middle of a request invocation, macro calman2html: Unknown operator . man2html: Unknown operator . man2html: Unknown operator . man2html: Unknown operator . man2html: Unknown operator . l, or escape sequence. Input line continuation is invisible to the formatter, with two exceptions: the | operator recognizes the new input line, and the input line counter register .c is incremented.
The \c escape sequence continues an output line. Nothing on the input line after it is formatted. In contrast to \newline, a line after \c is treated as a new input line, so a control character is recognized at its beginning. The visual results depend on whether filling is enabled. An intervening control line that causes a break overrides \c, flushing out the pending output line in the usual way. The .int contains a positive value if the last output line was continued with \c; this datum is associated with the environment.
Each output device has a color named
"default",
which cannot be redefined.
A device's default stroke and fill colors are not necessarily the same.
For the
dvi,
html,
pdf,
ps,
and
xhtml
output devices,
troff
automatically loads a macro file defining many color names at startup.
By the same mechanism,
the devices supported by
recognize the eight standard ISO~6429/ECMA-48 color names
(also known vulgarly as "ANSI colors").
Measurements are scaled by the scaling unit and stored internally (with any fractional part discarded) in basic units. The device resolution can therefore be obtained by storing a value of "1i" to a register. The only constraint on the basic unit is that it is at least as small as any other unit.
The magnitudes of other scaling units depend on the text formatting parameters in effect.
| + | addition | |
| - | subtraction | |
| * | multiplication | |
| / | truncating division | |
| % | modulus | |
| unary + | assertion, motion, incrementation | |
| unary - | negation, motion, decrementation | |
| ; | scaling | |
| >? | maximum | |
| <? | minimum | |
| < | less than | |
| > | greater than | |
| <= | less than or equal | |
| >= | greater than or equal | |
| = | equal | |
| == | equal | |
| & | logical conjunction ("and") | |
| : | logical disjunction ("or") | |
| ! | logical complementation ("not") | |
| ( ) | precedence | |
| | | boundary-relative motion | |
troff provides a set of mathematical and logical operators familiar to programmers---as well as some unusual ones---but supports only integer arithmetic. (Provision is made for interpreting and reporting decimal fractions in certain cases.) The internal data type used for computing results is usually a 32-bit signed integer, which suffices to represent magnitudes within a range of ±2 billion. (If that's not enough, see for the 62bit.tmac macro package.)
Arithmetic infix operators perform a function on the numeric expressions to their left and right; they are + (addition), - (subtraction), * (multiplication), / (truncating division), and % (modulus). Truncating division rounds to the integer nearer to zero, no matter how large the fractional portion. Overflow and division (or modulus) by zero are errors and abort evaluation of a numeric expression.
Arithmetic unary operators operate on the numeric expression to their right; they are - (negation) and + (assertion---for completeness; it does nothing). The unary minus must often be used with parentheses to avoid confusion with the decrementation operator, discussed below.
The sign of the modulus of operands of mixed signs is determined by the sign of the first. Division and modulus operators satisfy the following property: given a dividend~a and a divisor~b, a quotient~q formed by "(a / b)" and a remainder~r by "(a % b)", then qb~+~r~=~a.
GNU troff's scaling operator, used with parentheses as (c;e), evaluates a numeric expression~e using~c as the default scaling unit. If c is omitted, scaling units are ignored in the evaluation of~e. GNU troff also provides a pair of operators to compute the extrema of two operands: >? (maximum) and <? (minimum).
Comparison operators comprise < (less than), > (greater than), <= (less than or equal), >= (greater than or equal), and = (equal). == is a synonym for =. When evaluated, a comparison is replaced with "0" if it is false and "1" if true. In the roff language, positive values are true, others false.
We can operate on truth values with the logical operators & (logical conjunction or "and") and : (logical disjunction or "or"). They evaluate as comparison operators do. A logical complementation ("not") operator, !, works only within "if", "ie", and "while" requests. Furthermore, ! is recognized only at the beginning of a numeric expression not contained by another numeric expression. In other words, it must be the "outermost" operator. Including it elsewhere in the expression produces a warning in the "number" category (see and its expression evaluates false. This unfortunate limitation maintains compatibility with AT&T troff. Test a numeric expression for falsity by comparing it to a false value.
The roff language has no operator precedence: expressions are evaluated strictly from left to right, in contrast to schoolhouse arithmetic. Use parentheses ( ) to impose a desired precedence upon subexpressions.
For many requests and escape sequences that cause motion on the page, the unary operators + and - work differently when leading a numeric expression. They then indicate a motion relative to the drawing position: positive is down in vertical contexts, right in horizontal ones.
+ and - are also treated differently by the following requests and escape sequences: bp, in, ll, pl, pn, po, ps, pvs, rt, ti, \H, \R, and \s. Here, leading plus and minus signs serve as incrementation and decrementation operators, respectively. To negate an expression, subtract it from zero or include the unary minus in parentheses with its argument.
A leading | operator indicates a motion relative not to the drawing position but to a boundary. For horizontal motions, the measurement specifies a distance relative to a drawing position corresponding to the beginning of the input line. By default, tab stops reckon movements in this way. Most escape sequences do not; | tells them to do so. For vertical motions, the | operator specifies a distance from the first text baseline on the page or in the current diversion, using the current vertical spacing.
The
\B
escape sequence tests its argument for validity as a numeric expression.
A register interpolated as an operand in a numeric expression must have an Arabic format; luckily, this is the default.
Due to the way arguments are parsed, spaces are not allowed in numeric expressions unless the (sub)expression containing them is surrounded by parentheses.
Invalid input characters are subset of control characters (from the sets "C0 Controls" and "C1 Controls" as Unicode describes them). When troff encounters one in an identifier, it produces a warning in category "input" (see section "Warnings" in They are removed during interpretation: an identifier "foo", followed by an invalid character and then "bar", is processed as "foobar".
On a machine using the ISO 646, 8859, or 10646 character encodings, invalid input characters are 0x00, 0x08, 0x0B, 0x0D-0x1F, and 0x80-0x9F. On an EBCDIC host, they are 0x00-0x01, 0x08, 0x09, 0x0B, 0x0D-0x14, 0x17-0x1F, and 0x30-0x3F. Some of these code points are used by troff internally, making it non-trivial to extend the program to accept UTF-8 or other encodings that use characters from these ranges.
An identifier with a closing bracket ("]") in its name can't be accessed with bracket-form escape sequences that expect an identifier as a parameter. Similarly, the identifier "(" can't be interpolated except with bracket forms.
If you begin a macro, string, or diversion name with either of the characters "[" or "]", you foreclose use of the preprocessor, which recognizes ".[" and ".]" as bibliographic reference delimiters.
The escape sequence \A tests its argument for validity as an identifier.
How GNU troff handles the interpretation of an undefined identifier depends on the context. There is no way to invoke an undefined request; such syntax is interpreted as a macro call instead. If the identifier is interpreted as a string, macro, or diversion, troff emits a warning in category "mac", defines it as empty, and interpolates nothing. If the identifier is interpreted as a register, troff emits a warning in category "reg", initializes it to zero, and interpolates that value. See section "Warnings" in and subsection "Interpolating registers" and section "Strings" below. Attempting to use an undefined typeface, style, special character, color, character class, environment, or stream generally provokes an error diagnostic.
Identifiers for requests, macros, strings, and diversions share one name space; special characters and character classes another. No other object types do.
A few requests cause a break implicitly; use the no-break control character to prevent the break. Break suppression is its sole behavioral distinction. Employing the no-break control character to invoke requests that don't cause breaks is harmless but poor style.
The control character "." and the no-break control character "'" can be changed with the cc and c2 requests, respectively. Within a macro definition, register .br indicates the control character used to call it.
There is no inherent limit on argument length or quantity.
Most requests take one or more arguments,
and ignore any they do not expect.
A request may be separated from its arguments by tabs or spaces,
but only spaces can separate an argument from its successor.
Only one between arguments is necessary;
any excess is ignored.
GNU
troff does not allow tabs for argument separation.
Generally, a space within a request argument is not relevant, not meaningful, or is supported by bespoke provisions, as with the tl request's delimiters. Some requests, like ds, interpret the remainder of the control line as a single argument. See section "Strings" below.
Spaces and tabs immediately after a control character are ignored. Commonly, authors structure the source of documents or macro files with them.
To embed spaces within a macro argument, enclose the argument in neutral double quotes '"'. Horizontal motion escape sequences are sometimes a better choice for arguments to be formatted as text.
The foregoing raises the question of how to embed neutral double quotes or backslashes in macro arguments when those characters are desired as literals. In GNU troff, the special character escape sequence \[rs] produces a backslash and \[dq] a neutral double quote.
In GNU troff's AT&T compatibility mode, these characters remain available as \(rs and \(dq, respectively. AT&T troff did not consistently define these special characters, but its descendants can be made to support them. See If even that is not feasible, see the "Calling Macros" section of the groff Texinfo manual for the complex macro argument quoting rules of AT&T troff.
Escape sequences vary in length. Some take an argument, and of those, some have different syntactical forms for a one-character, two-character, or arbitrary-length argument. Others accept only an arbitrary-length argument. In the former scheme, a one-character argument follows the function character immediately, an opening parenthesis "(" introduces a two-character argument (no closing parenthesis is used), and an argument of arbitrary length is enclosed in brackets "[]". In the latter scheme, the user selects a delimiter character. A few escape sequences are idiosyncratic, and support both of the foregoing conventions (\s), designate their own termination sequence (\?), consume input until the next newline (\!, \ , \#), or support an additional modifier character (\s again, and \n).
If an escape character is followed by a character that does not identify a defined operation, the escape character is ignored (producing a diagnostic of the "escape" warning category, which is not enabled by default) and the following character is processed normally.
Escape sequence interpolation is of higher precedence than escape
sequence argument interpretation.
This rule affords flexibility in using escape sequences to construct
parameters to other escape sequences.