From Rosetta Code
This programming language may be used to instruct a computer to perform a task.
See Also:

Listed below are all of the tasks on Rosetta Code which have been solved using N/t/roff.

N/t/roff or /.ROFF/ (regular expression) is a document formatting language used to instruct an automated typesetter/typewriter (i.e. printer) to set/print a document's text. Its name is an acronym of New Runoff and Typesetter Runoff respectively. For document preparation purposes (i.e. its designed use), the rules of how text is laid out is written in a /.ROFF/ source file. /.ROFF/ is a predecessor of TeX, and so its ability is a subset of that of TeX and its core values is indeed very similar to that of TeX. To assist the writer in writing documents, macro packages, such as -me, -ms, -mm, and -mom; typefaces and their fonts, such as Avant Garde, Helvetica, and Times Roman; and preprocessors like eqn, pic, and tbl are available at the writer's disposal. These macro packages and extensions are similar to what LaTeX provides to plain TeX.

/.ROFF/ are also compilers for the /.ROFF/ formatting language. The regular expression /.ROFF/ in this page metaphorically matches TROFF and NROFF (but it technically matches more than that). Thus, TROFF and NROFF are compilers. The two compilers understand and parse the same language of /.ROFF/, but their outputs are not the same. Document output from the TROFF compiler is better-suited for typesetters: photo-typesetters, laser printers, etc.; whereas output from the NROFF compiler is better-suited for typewriter-like printers: line printers, daisy wheel printers, or glass teletypes. This holds, even if both compilers get the exact same input verbatim; although all logical flow controls are executed in the same manner.

A typical /.ROFF/ source file for documents is a plaintext file with the extensions: *.roff, *.me, *.ms, *.mm, or *.mom. The extension depends on what macro package is used to set the pages of the document, although the /.ROFF/ compiler treats all of them the same way and associates no special meanings thither. Such a /.ROFF/ document contains the document's text itself (i.e. the writer's actual words) interspersed with some formatting requests that instruct the computer how to set the text on a page.

The complexity of those such requests, their subtleties, and how they intertwine is what makes up the basic /.ROFF/ formatting language. For more complex formatting work, the language offers logical constructs (if-else's), numerical registers (.nr), macro definitions with formal parameters (.de, akin to function definitions), and recursive macro calls. These features are what make the /.ROFF/ language Turing-complete as well, although tasks easy in most programming languages won't necessarily be easy in /.ROFF/. To quote Professor Brian W. Kernighan, a user of TROFF, in an email about this (November 23, 2017):

Eric Raymond observed that troff was Turing complete in his book on Unix, back in 2003. I think that's true even of the original version, because it has recursion and a conditional; it's probably easier in groff, though I haven't tried either.

With the availability of such complex requests in plain /.ROFF/ come the macro packages (sets of pre-written macros) that utilize much of the intrinsic requests. A typical collection of macros or macro packages for /.ROFF/ is known as a tmac (troff macros); these files bear the extensions: *.tmac or tmac.*, although the former is preferred to the classical latter. Since macro definitions are not documents and should only contain the typesetter's logic, it does not generally have any text. Thus, compiling a tmac as a document and printing the output usually results in a blank page. Errors pertaining to any of the macros can appear on Standard Error, but never on the typeset output.

Therefore, when using /.ROFF/ programmatically to solve problems on Rosettacode, output is most often succinct, as almost the entire source file should contain program logic or comments. When there is output, it is merely to present the final output of the algorithm's execution.

Since the output is on paper, the left-right margins will generally be set (1 inch on either side), the output will mostly mercilessly be wrapped if its width is longer than the paper-size specified during compile-time (usually US Letter or A4), and long output may be printed onto another page. This default typesetting behaviour can be overridden to mimic more well-behaved outputs by most programming languages, but there generally is no need to do so. All error/warning/debug messages should be output to Standard Error, which likely ends up on the terminal, not the output paper.

Since one does not desire their algorithm's output to be exceptionally well-typeset, one need not use any typesetting macro packages (e.g. -me, -ms, -mm), although it can be helpful to write macros that aid in writing more complex algorithms. If you do have such macros and are planning to use them, please mention about that and how to obtain them, when making submissions on Rosettacode. You should import your macros using .so or .mso, so that they can easily be expanded later using soelim prior to your submission to Rosettacode.


Classical TROFF from Bell Labs was written in Assembly by the late Joseph F. Ossanna in 1973. It was then rewritten in C in 1975 and received active maintenance until Joseph F. Ossanna died as a consequence of heart disease in 1977. In 1979, Professor Brian W. Kernighan modified classical TROFF so that it could produce output for a variety of output devices and typesetters, not just the Graphic Systems CAT typesetter. Since then until 1989, the internals of TROFF had been modestly revised, though much of the original code that Joseph F. Ossanna had written and the /.ROFF/ formatting language's specification remain intact. The /.ROFF/ specification and compilers developed during 1973 to 1989 will henceforth be referred to as Classical /.ROFF/, with the regular expression expanded if necessary.

Then came 1990, James Clark wrote GROFF (GNU TROFF) in C++ as a free and open-source alternative to the then-proprietary classical TROFF compiler. In 1999, Werner Lemberg and Ted Harding took over maintenance of GROFF. GROFF is now part of the GNU suite of utilities and is included in almost all distributions of GNU/Linux and available as a package for various BSDs and other UNIX-like systems. The GROFF compiler also extends the traditional TROFF language. In this way, the features found in the GROFF dialect is a superset of those found in classical TROFF. These features, such as .while, aid in writing algorithms.


Given the availability, computational superiority, and free/open-source nature of GROFF, it is one of the best implementations, not only to typeset exceptionally beautiful documents, but also to implement algorithms and solve problems on Rosettacode. Heirloom Troff is also a good candidate as well and works pretty much the same as GROFF when .cp 0 is set.