Category:N/t/roff: Difference between revisions

From Rosetta Code
Content added Content deleted
m (Created language observed in User:Aks.)
 
(Add information)
Line 1: Line 1:
'''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. 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.
{{language}}{{stub}}

/.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 the 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: <code>*.roff</code>, <code>*.me</code>, <code>*.ms</code>, <code>*.mm</code>, or <code>*.mom</code>. 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 (<code>.nr</code>), macro definitions with formal parameters (<code>.de</code>, 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):

<blockquote>
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.
</blockquote>

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'' (''t''roff ''mac''ros); these files bear the extensions: <code>*.tmac</code> or <code>tmac.*</code>, 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 run.

Since the output is on paper, the left-right margins will generally be set, 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 it and how to obtain it when making submissions on Rosettacode. You should import your macros using <code>.so</code> or <code>.mso</code>, so that they can easily be expanded later using <code>soelim</code> prior to your submission to Rosettacode.

Revision as of 16:07, 1 December 2017

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. 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 the 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 run.

Since the output is on paper, the left-right margins will generally be set, 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 it and how to obtain it 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.