Category:N/t/roff: Difference between revisions

no edit summary
(Add information)
No edit summary
Line 18:
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 runexecution.
 
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 itthat and how to obtain itthem, 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.
 
== History ==
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 <code>.while</code>, aid in writing algorithms.
 
== Implementations ==
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.
Anonymous user