roff7
Concepts and history of roff typesetting
Overview
The term roff denotes a family of document formatting systems known by names like troff, nroff, and ditroff. A roff system consists of an interpreter for an extensible text formatting language and a set of programs for preparing output for various devices and file formats. Unix-like operating systems often distribute a roff system. The manual pages on Unix systems (“man pages”) and bestselling books on software engineering, including Brian Kernighan and Dennis Ritchie's The C Programming Language and W. Richard Stevens's Advanced Programming in the Unix Environment, have been written using roff systems. GNU roff—groff—is arguably the most widespread roff implementation.
Below we present typographical concepts foundational to understanding any roff implementation, narrate the development history of some roff systems, detail the command pipeline managed by groff(1), survey the formatting language, suggest tips for editing roff input, and recommend further reading materials.
Concepts
AT&T troff was designed to take input as it would be composed on a typewriter, including the teletypewriters used as early computer terminals, and relieve the user drafting a document of concern with details like line length maintenance, hyphenation breaking, and consistent paragraph indentation. Early in its development, the program gained the ability to prepare output for a phototypesetter; a document could then be prepared for output to a teletypewriter, a phototypesetter, or both. GNU troff continues this tradition of permitting an author to compose a single master version of a document which can then be rendered upon a variety of output formats or devices, including PDF, HTML, laser printers, and terminal displays.
roff input contains text interspersed with instructions to control the formatter. Even in the absence of such instructions, a roff formatter still processes its input in several ways, by filling, hyphenating, breaking, and adjusting it, and supplementing it with inter-sentence space. These processes are basic to typesetting, and can be controlled at the input document's discretion.
Instructions to roff take two forms. One is the request, which occupies an input line and starts with the control character, a dot “.”. The other is the escape sequence, which can occur almost anywhere and starts with the escape character, a backslash “\”. Both characters are configurable.
.br \" break the output line
When a device-independent roff formatter starts up, it obtains information about the device for which it is preparing output from the latter's description file (see groff_font(5)). An essential property is the length of the output line, such as “6.5 inches”.
The formatter interprets plain text files employing the Unix line-ending convention. It reads input a character at a time, collecting words as it goes, and fits as many words together on an output line as it can—this is known as filling. To a roff system, a word is any sequence of one or more characters that aren't spaces or newlines. The exceptions separate words.
A roff formatter attempts to detect boundaries between sentences, and supplies supplemental inter-sentence space between them. It flags certain characters (normally “!”, “?”, and “.”) as potentially ending a sentence. When the formatter encounters one of these end-of-sentence characters at the end of an input line, or one of them is followed by two (unescaped) spaces on the same input line, it appends an inter-word space followed by an inter-sentence space in the output. The dummy character escape sequence \& can be used after an end-of-sentence character to defeat end-of-sentence detection on a per-instance basis. Normally, the occurrence of a visible non-end-of-sentence character (as opposed to a space or tab) immediately after an end-of-sentence character cancels detection of the end of a sentence. However, the formatter treats several characters transparently after the occurrence of an end-of-sentence character—it does not cancel end-of-sentence status upon encountering them. Such characters are often used as footnote marks or to close quotations and parentheticals. The default set is ", ', ), ], *, \[dg], \[dd], \[rq], and \[cq]. The last four are examples of special characters, escape sequences whose purpose is to obtain glyphs that are not easily typed at the keyboard, or which have special meaning to the formatter (like \ itself).
When an output line is nearly full, it is uncommon for the next word collected from the input to exactly fill it—often, there is room left over for only part of the next word. Hyphenation is the process of splitting a word so that it appears partially on one line, followed by a hyphen to indicate to the reader that the word has been broken, and that its remainder lies on the next. Hyphenation break points can be manually specified; GNU troff also uses a hyphenation algorithm and language-specific pattern files (based on TeX's) to decide which words can be hyphenated and where. Hyphenation does not always occur even when the hyphenation rules for a word allow it; it can be disabled, and when not disabled there are several parameters that can prevent it in certain circumstances.
Once an output line is full, the formatter places the next word (or remainder of a hyphenated one) on a different output line; this is called a break. In this document and in roff discussions generally, a “break” if not further qualified always refers to the termination of an output line. When the formatter is filling text, it introduces breaks automatically to keep output lines from exceeding the configured line length. After an automatic break, the formatter adjusts the line if applicable (see below), and then resumes collecting and filling text on the next output line.
Sometimes, a line cannot be broken automatically. This usually does not happen with natural language text unless the output line length has been manipulated to be extremely short, but it can with specialized text like program source code. groff provides a means of telling the formatter where the line may be broken without hyphens. This is done with the non-printing break point escape sequence \:.
There are several ways to cause a break at a predictable location. A blank input line not only causes a break, but by default it also outputs a one-line vertical space (effectively a blank output line). Macro packages may discourage or disable this “blank line method” of paragraphing in favor of their own macros. A line that begins with one or more spaces causes a break. The spaces are output at the beginning of the next line without being adjusted (see below). Again, macro packages may provide other methods of producing indented paragraphs. Trailing spaces on text lines (see below) are discarded. The formatter breaks the pending output line without adjustment upon encountering the end of input.
After performing an automatic break, the formatter may then adjust the line, widening inter-word spaces until the text reaches the right margin. Extra spaces between words are preserved. Leading and trailing spaces are handled as noted above. You can align text to the left or right margin only, or center it, using requests.
A roff formatter translates horizontal tab characters, also called simply “tabs”, in the input into movements to the next tab stop. Tab stops are by default located every half inch measured from the drawing position corresponding to the beginning of the input line; see subsection “Page geometry” below. With them, simple tables can be made. However, this method can be deceptive, as the appearance (and width) of the text in an editor and the results from the formatter can vary greatly, particularly when proportional typefaces are used. A tab character does not cause a break and therefore does not interrupt filling. The formatter provides facilities for sophisticated table composition; there are many details to track when using the “tab” and “field” low-level features, so most users turn to the tbl(1) preprocessor to lay out tables.
Requests and macros
A request is an instruction to the formatter that occurs after a control character, which is recognized at the beginning of an input line. The regular control character is a dot “.”. Its counterpart, the no-break control character, a neutral apostrophe “'”, suppresses the break implied by some requests. These characters were chosen because it is uncommon for lines of text in natural languages to begin with them. If you require a formatted period or apostrophe (closing single quotation mark) where the formatter expects a control character, prefix the dot or neutral apostrophe with the dummy character escape sequence, “\&”.
An input line beginning with a control character is called a control line. Every line of input that is not a control line is a text line.
Requests often take arguments, words (separated from the request name and each other by spaces) that specify details of the action you expect the formatter to perform. If a request is meaningless without arguments, it is typically ignored. Requests and escape sequences comprise the control language of the formatter. Of key importance are the requests that define macros. Macros are invoked like requests, enabling the request repertoire to be extended or overridden. (Argument handling in macros is more flexible but also more complex.)
A macro can be thought of as an abbreviation you can define for a collection of control and text lines. When the macro is called by giving its name after a control character, it is replaced with what it stands for. The process of textual replacement is known as interpolation. Interpolations are handled as soon as they are recognized, and once performed, a roff formatter scans the replacement for further requests, macro calls, and escape sequences. In roff systems, the “de” request defines a macro.
Page geometry
roff systems format text under certain assumptions about the size of the output medium, or page. For the formatter to correctly break a line it is filling, it must know the line length, which it derives from the page width. For it to decide whether to write an output line to the current page or wait until the next one, it must know the page length. A device's resolution converts practical units like inches or centimeters to basic units, a convenient length measure for the output device or file format. The formatter and output driver use basic units to reckon page measurements. The device description file defines its resolution and page dimensions (see groff_font(5)).
A page is a two-dimensional structure upon which a roff system imposes a rectangular coordinate system with its its origin near the upper left corner. Coordinate values are in basic units and increase down and to the right. Useful ones are typically positive and within numeric ranges corresponding to the page boundaries.
Text is arranged on a one-dimensional lattice of text baselines from the top to the bottom of the page. A text baseline is a (usually invisible) line upon which the glyphs of a typeface are aligned. Vertical spacing is the distance between adjacent text baselines. Typographic tradition sets this quantity to 120% of the type size. The initial vertical drawing position is one unit of vertical spacing below the page top. Typographers term this unit a vee.
While the formatter (and, later, output driver) is processing a page, it keeps track of its drawing position, which is the location at which the next glyph will be written, from which the next motion will be measured, or where a geometric object will commence rendering. Notionally, glyphs are drawn from the text baseline upward and to the right. (groff does not yet support right-to-left scripts.) A glyph therefore “starts” at its bottom-left corner. The formatter's origin is one vee below the page top to prevent a glyph from lying partially or wholly off the page.
Further, it is conventional not to write or draw at the extreme edges of the page. Typesetters configure a page offset, a rightward shift from the left edge that defines the zero point from which the formatter reckons the line indentation and length. (groff's terminal output devices have page offsets of zero.)
Combining the foregoing facts results in an origin that lies at the page offset in the horizontal dimension and at the text baseline (using the default vertical spacing) in the vertical dimension. A document can change these prior to its first written or drawn output.
Vertical spacing has an impact on page-breaking decisions. Generally, when a break occurs, the formatter automatically moves the drawing position to the next text baseline. If the formatter were already writing to the last line that fits on the page, advancing by one vee would place the next text baseline off the page. To avoid that, roff formatters instruct the output driver to eject the page, start a new one, and again place the drawing position at the page offset one vee below the page top; this is a page break.
When the last line of input text corresponds to the last output line that fits on the page, the break caused by the end of input also breaks the page, producing a useless blank one. Macro packages keep users from having to confront this difficulty by setting “traps”; moreover, all but the simplest page layouts tend to have headers and footers, or at least bear vertical margins of at least one vee.
Other language elements
Escape sequences start with the escape character, a backslash \, and are followed by at least one additional character. They can appear anywhere in the input.
With requests, the escape and control characters can be changed; further, escape sequence recognition can be turned off and back on.
Strings store character sequences. In groff, they can be parameterized (given arguments) as macros can.
Registers store numerical values, including measurements. The latter are generally in basic units; scaling units can be appended to numeric expressions to clarify their meaning when stored or interpolated. Each register can be assigned a format, causing its value to interpolate with leading zeroes, in Roman numerals, or alphabetically. Some read-only registers are string-valued, meaning that they interpolate text and lack a format.
Fonts are identified either by a name or by a mounting position (a non-negative number). Four styles are available on all devices. R is “roman”: normal, upright text. B is bold, an upright typeface with a heavier weight. I is italic, a face that is oblique on typesetter output devices and usually underlined instead on terminal devices. BI is bold-italic, combining both of the foregoing style variations. Typesetting devices group these four styles into families of text fonts; they also typically offer one or more special fonts that provide unstyled glyphs; see groff_char(7).
groff supports named colors for glyph rendering and drawing of geometric objects. Stroke and fill colors are distinct; the stroke color is used for glyphs.
Glyphs are visual representation forms of characters. In groff, the distinction between those two elements is not always obvious (and a full discussion is beyond our scope). In brief, “A” is a character when we consider it in the abstract: to make it a glyph, we must select a typeface with which to render it, and determine its type size and color. The formatting process turns input characters into output glyphs. A few characters commonly seen on keyboards are treated specially by the roff language and may not look correct in output if used unthinkingly; they are the (double) quotation mark ("), the neutral apostrophe ('), the minus sign (-), the backslash (\), the caret or circumflex accent (^), the grave accent (`), and the tilde (~). All of these and more can be produced with special character escape sequences; see groff_char(7).
groff offers streams, identifiers for writable files, but for security reasons this feature is disabled by default.
A further few language elements arise as page layouts become more sophisticated and demanding. Environments collect formatting parameters like line length and typeface. A diversion stores formatted output for later use. A trap is a condition on the input or output, tested automatically by the formatter, that is associated with a macro: fulfilling the condition springs the trap—calls the macro.
Footnote support often exercises all three of the foregoing features. A simple implementation might work as follows. The author writes a pair of macros: one starts a footnote and the other ends it. They further set a trap a small distance above the page bottom, reserving a footnote area. The author calls the first macro where a footnote mark is desired. The macro establishes a diversion so that the footnote text is collected at the place in the body text where its corresponding mark appears. It further creates an environment for the footnote so that it sets at a smaller typeface. The footnote text is formatted in the diversion using that environment, but it does not yet appear in the output. The document author calls the footnote end macro, which returns to the previous environment and ends the diversion. Later, after body text nearly fills the page, the trap springs. The macro called by the trap draws a line across the page and emits the stored diversion by calling it like a macro. Thus, the footnote is rendered.
Using roff
When you read a man page, often a roff is the program rendering it. Some roff implementations provide wrapper programs that make it easy to use the roff system from the shell's command line. These can be specific to a macro package, like mmroff(1), or more general. groff(1) provides command-line options sparing the user from constructing the long, order-dependent pipelines familiar to AT&T troff users. Further, a heuristic program, grog(1), is available to infer from a document's contents which groff arguments should be used to process it.
The roff pipeline
A typical roff document is prepared by running one or more preprocessors in series, followed by a a formatter program and then an output driver (or “device postprocessor”). Commonly, these programs are structured into a pipeline; that is, each is run in sequence such that the output of one is taken as the input to the next, without passing through secondary storage. (Non-Unix systems may simulate pipelines with temporary files.)
$ preproc1
< input-file | preproc2 |
... | troff
[option]
... \
| output-driver
Once all preprocessors have run, they deliver pure roff language input to the formatter, which in turn generates a document in a page description language that is then interpreted by a postprocessor for viewing, printing, or further handling.
Each program interprets input in a language that is independent of the others; some are purely descriptive, as with tbl(1) and roff output, and some permit the definition of macros, as with eqn(1) and roff input. Most roff input employs the macros of a document formatting package, intermixed with instructions for one or more preprocessors, and is seasoned with escape sequences and requests from the roff language. Some documents are simpler still, since their formatting packages discourage direct use of roff requests; man pages are a prominent example. Many features of the roff language are seldom needed by users; only authors of macro packages require a substantial command of them.
Preprocessors
A roff preprocessor is a program that, directly or ultimately, generates output in the roff language. Typically, each preprocessor defines a language of its own that transforms its input into that for roff or another preprocessor. As an example of the latter, chem produces pic input. Preprocessors must consequently be run in an appropriate order; groff(1) handles this automatically for all preprocessors supplied by the GNU roff system.
Portions of the document written in preprocessor languages are usually bracketed by tokens that look like roff macro calls. roff preprocessor programs transform only the regions of the document intended for them. When a preprocessor language is used by a document, its corresponding program must process it before the input is seen by the formatter, or incorrect rendering is almost guaranteed.
GNU roff provides several preprocessors, including eqn, grn, pic, tbl, refer, and soelim. See groff(1) for a complete list. Other preprocessors for roff systems are known.
| dformat | depicts data structures; |
| grap | constructs statistical charts; and |
| ideal | draws diagrams using a constraint-based language. |
Formatter programs
A roff formatter transforms roff language input into a single file in a page description language, described in groff_out(5), intended for processing by a selected device. This page description language is specialized in its parameters, but not its syntax, for the selected device; the format is device-independent, but not device-agnostic. The parameters the formatter uses to arrange the document are stored in device and font description files; see groff_font(5).
AT&T Unix had two formatters—nroff for terminals, and troff for typesetters. Often, the name troff is used loosely to refer to both. When generalizing thus, groff documentation prefers the term “roff”. In GNU roff, the formatter program is always troff(1).
Devices and output drivers
To a roff system, a device is a hardware interface like a printer, a text or graphical terminal, or a standardized file format that unrelated software can interpret. An output driver is a program that parses the output of troff and produces instructions or markup specific to the device or file format it supports. An output driver might support multiple devices, particularly if they are similar.
The names of the devices and their driver programs are not standardized. Technological fashions evolve; the devices popular for document preparation when AT&T troff was first written in the 1970s are no longer used in production environments. Device capabilities have tended to increase, improving resolution and font repertoire, and adding color output and hyperlinking. Further, to reduce file size and processing time, AT&T troff's page description language placed low limits on the magnitudes of some quantities it could represent. Its PostScript output driver, dpost(1), had a resolution of 720 units per inch; groff's grops(1) uses 72,000.
roff programming
Documents using roff are normal text files interleaved with roff formatting elements. The roff language is powerful enough to support arbitrary computation and it supplies facilities that encourage extension. The primary such facility is macro definition; with this feature, macro packages have been developed that are tailored for particular applications.
Macro packages
Macro packages can have a much smaller vocabulary than roff itself; this trait combined with their domain-specific nature can make them easy to acquire and master. The implementation of a package name is typically kept in a file called “name.tmac” (historically, “tmac.name”). Find details on the naming and placement of macro packages in groff_tmac(5).
A macro package anticipated for use in a document can be declared to the formatter by the command-line option -m; see troff(1). It can alternatively be specified within a document using the mso request of the groff language; see groff(7).
Well-known packages include man for traditional man pages and mdoc for BSD-style manual pages. Packages for typesetting books, articles, and letters include ms (from “manuscript macros”), me (named by a system administrator from the first name of its creator, Eric Allman), mm (from “memorandum macros”), and mom, a punningly named package exercising many groff extensions. See groff_tmac(5) for more.
The roff formatting language
The roff language provides requests, escape sequences, macro definition facilities, string variables, registers for storage of numbers or dimensions, and control of execution flow. The theoretically minded will observe that a roff is not a mere markup language, but Turing-complete. It has storage (registers), it can perform tests (as in conditional expressions like “(\n[i] >= 1)”), its “if” and related requests alter the flow of control, and macro definition permits unbounded recursion.
Requests and escape sequences are instructions, predefined parts of the language, that perform formatting operations, interpolate stored material, or otherwise change the state of the parser. The user can define their own request-like elements by composing together text, requests, and escape sequences ad libitum. A document writer will not (usually) note any difference in usage for requests or macros; both are found on control lines. However, there is a distinction; requests take either a fixed number of arguments (sometimes zero), silently ignoring any excess, or consume the rest of the input line, whereas macros can take a variable number of arguments. Since arguments are separated by spaces, macros require a means of embedding a space in an argument; in other words, of quoting it. This then demands a mechanism of embedding the quoting character itself, in case it is needed literally in a macro argument. AT&T troff had complex rules involving the placement and repetition of the double quote to achieve both aims. groff cuts this knot by supporting a special character escape sequence for the neutral double quote, “\[dq]”, which never performs quoting in the typesetting language, but is simply a glyph, ‘"’.
Escape sequences start with a backslash, “\”. They can appear almost anywhere, even in the midst of text on a line, and implement various features, including the insertion of special characters with “\(xx” or “\[xxx]”, break suppression at input line endings with “\c”, font changes with “\f”, type size changes with “\s”, in-line comments with “\"”, and many others.
Strings store text. They are populated with the ds request and interpolated using the \* escape sequence.
Registers store numbers and measurements. A register can be set with the request nr and its value can be retrieved by the escape sequence \n.
File naming conventions
The structure or content of a file name, beyond its location in the file system, is not significant to roff tools. roff documents employing “full-service” macro packages (see groff_tmac(5)) tend to be named with a suffix identifying the package; we thus see file names ending in .man, .ms, .me, .mm, and .mom, for instance. When installed, man pages tend to be named with the manual's section number as the suffix. For example, the file name for this document is roff.7. Practice for “raw” roff documents is less consistent; they are sometimes seen with a .t suffix.
Input conventions
Since a roff formatter fills text automatically, its experienced users tend to avoid visual composition of text in input files: the esthetic appeal of the formatted output is what matters. Therefore, roff input should be arranged such that it is easy for authors and maintainers to compose and develop the document, understand the syntax of roff requests, macro calls, and preprocessor languages used, and predict the behavior of the formatter. Several traditions have accrued in service of these goals.
- •
-
Follow sentence endings in the input with newlines to ease their recognition. It is frequently convenient to end text lines after colons and semicolons as well, as these typically precede independent clauses. Consider doing so after commas; they often occur in lists that become easy to scan when itemized by line, or constitute supplements to the sentence that are added, deleted, or updated to clarify it. Parenthetical and quoted phrases are also good candidates for placement on text lines by themselves.
- •
-
Set your text editor's line length to 72 characters or fewer; see the subsections below. This limit, combined with the previous item of advice, makes it less common that an input line will wrap in your text editor, and thus will help you perceive excessively long constructions in your text. Recall that natural languages originate in speech, not writing, and that punctuation is correlated with pauses for breathing and changes in prosody.
- •
-
Use \& after “!”, “?”, and “.” if they are followed by space or newline characters and don't end a sentence.
- •
-
In filled text lines, use \& before “.” and “'” if they are preceded by space, so that revisions to the input don't turn them into control lines.
- •
-
Do not use spaces to perform indentation or align columns of a table. Leading spaces are reliable when text is not being filled. (Exception: when laying out a table with GNU tbl, specifying the
nospacesregion option causes the program to ignore spaces at the boundaries of table cells.)
- •
-
Comment your document. It is never too soon to apply comments to record information of use to future document maintainers (including your future self). The \" escape sequence causes the formatter to ignore the remainder of the input line.
- •
-
Use the empty request—a control character followed immediately by a newline—to visually manage separation of material in the input. Many of the groff project's own documents use an empty request between sentences, after macro definitions, and where a break is expected, and two empty requests between paragraphs or other requests or macro calls that will introduce vertical space into the document. You can combine the empty request with the comment escape sequence to include whole-line comments in your document, and even “comment out” sections of it.
An example sufficiently long to illustrate most of the above suggestions in practice follows. An arrow → indicates a tab character.
.\" nroff this_file.roff | less .\" groff -T ps this_file.roff > this_file.ps →The theory of relativity is intimately connected with the theory of space and time. . I shall therefore begin with a brief investigation of the origin of our ideas of space and time, although in doing so I know that I introduce a controversial subject. \" remainder of paragraph elided . . →The experiences of an individual appear to us arranged in a series of events; in this series the single events which we remember appear to be ordered according to the criterion of \[lq]earlier\[rq] and \[lq]later\[rq], \" punct swapped which cannot be analysed further. . There exists, therefore, for the individual, an I-time, or subjective time. . This itself is not measurable. . I can, indeed, associate numbers with the events, in such a way that the greater number is associated with the later event than with an earlier one; but the nature of this association may be quite arbitrary. . This association I can define by means of a clock by comparing the order of events furnished by the clock with the order of a given series of events. . We understand by a clock something which provides a series of events which can be counted, and which has other properties of which we shall speak later. .\" Albert Einstein, _The Meaning of Relativity_, 1922
Editing with Emacs
Official GNU doctrine holds that the best program for editing a roff document is Emacs; see emacs(1). It provides an nroff major mode that is suitable for all kinds of roff dialects. This mode can be activated by the following methods.
When editing a file within Emacs the mode can be changed by typing “M-x nroff-mode”, where M-x means to hold down the meta key (often labelled “Alt”) while pressing and releasing the “x” key.
It is also possible to have the mode automatically selected when a roff file is loaded into the editor.
- •
-
The most general approach includes file-local variables at the end of the file; we can also configure the fill column this way.
.\" Local Variables: .\" fill-column: 72 .\" mode: nroff .\" End:
- •
-
Certain file name extensions, like those often used by man pages, activate nroff mode automatically.
- •
-
Loading a file with the sequence
.\" -*- nroff -*-
in its first line into an Emacs buffer causes the editor to enter its nroff major mode. Unfortunately, some implementations of the man(1) program are confused by this practice, so we discourage it.
Editing with Vim
Other editors provide support for roff-style files too, such as vim(1), an extension of the vi(1) program. Vim's highlighting can be made to recognize roff files by setting the filetype option in a Vim modeline. For this feature to work, your copy of vim must be built with support for, and configured to enable, several features; consult the editor's online help topics “auto-setting”, “filetype”, and “syntax”. Then put the following at the end of your roff files, after any Emacs configuration.
-
.\" vim: set filetype=groff textwidth=72:
Replace “groff” in the above with “nroff” if you want highlighting that does not recognize many of the GNU extensions to roff, such as request, register, and string names longer than two characters.
Releases
13 releases since Debian 3.0 (Woody); the text changed 12 times.