{
    "mode": "man",
    "parameter": "roff",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/roff/7/json",
    "generated": "2026-10-07T19:12:46Z",
    "sections": {
        "Name": {
            "content": "roff - concepts and history of roff typesetting\n",
            "subsections": []
        },
        "Description": {
            "content": "The  term  roff  denotes  a  family of document formatting systems known by names like troff,\nnroff, and ditroff.  A roff system consists of an interpreter for an extensible text  format‐\nting  language  and  a set of programs for preparing output for various devices and file for‐\nmats.  Unix-like operating systems often distribute a roff system.  The manual pages on  Unix\nsystems  (“man  pages”)  and  bestselling  books  on  software  engineering,  including Brian\nKernighan and Dennis Ritchie's The C Programming Language and W. Richard  Stevens's  Advanced\nProgramming  in the Unix Environment have been written using roff systems.  GNU roff—groff—is\narguably the most widespread roff implementation.\n\nBelow we present typographical concepts that form the background of all roff implementations,\nnarrate the development history of some roff systems, detail the command pipeline managed  by\ngroff(1),  survey the formatting language, suggest tips for editing roff input, and recommend\nfurther reading materials.\n",
            "subsections": []
        },
        "Concepts": {
            "content": "roff input files contain text interspersed with instructions to control the formatter.   Even\nin  the  absence  of such instructions, a roff formatter still processes its input in several\nways, by filling, hyphenating, breaking, and adjusting it, and supplementing it  with  inter-\nsentence space.  These processes are basic to typesetting, and can be controlled at the input\ndocument's discretion.\n\nWhen  a  device-independent roff formatter starts up, it obtains information about the device\nfor which it is preparing output from the latter's description file (see grofffont(5)).   An\nessential property is the length of the output line, such as “6.5 inches”.\n\nThe  formatter  interprets  plain  text  files employing the Unix line-ending convention.  It\nreads input a character at a time, collecting words as it goes, and fits as  many  words  to‐\ngether on an output line as it can—this is known as filling.  To a roff system, a word is any\nsequence  of  one or more characters that aren't spaces or newlines.  The exceptions separate\nwords.\n\nA roff formatter attempts to detect boundaries between sentences, and supplies additional in‐\nter-sentence space between them.  It flags certain characters (normally “!”, “?”, and “.”) as\npotentially ending a sentence.  When the formatter encounters one  of  these  end-of-sentence\ncharacters  at the end of an input line, or one of them is followed by two (unescaped) spaces\non the same input line, it appends an inter-word space followed by an inter-sentence space in\nthe output.  The dummy character escape sequence \\& can  be  used  after  an  end-of-sentence\ncharacter  to defeat end-of-sentence detection on a per-instance basis.  Normally, the occur‐\nrence of a visible non-end-of-sentence character (as opposed to a space or  tab)  immediately\nafter an end-of-sentence character cancels detection of the end of a sentence.  However, sev‐\neral  characters are treated transparently after the occurrence of an end-of-sentence charac‐\nter.  That is, a roff does not cancel end-of-sentence detection when it processes them.  This\nis because such characters are often used as footnote markers or to close quotations and par‐\nentheticals.  The default set is \", ', ), ], *, \\[dg], \\[dd], \\[rq],  and  \\[cq].   The  last\nfour  are  examples of special characters, escape sequences whose purpose is to obtain glyphs\nthat are not easily typed at the keyboard, or which have special  meaning  to  the  formatter\n(like \\).\n\nWhen an output line is nearly full, it is uncommon for the next word collected from the input\nto  exactly  fill  it—typically, there is room left over only for part of the next word.  The\nprocess of splitting a word so that it appears partially on one line (with a hyphen to  indi‐\ncate  to  the reader that the word has been broken) with its remainder on the next is hyphen‐\nation.  Hyphenation points can be manually specified; groff also uses a hyphenation algorithm\nand language-specific pattern files to decide which words can be hyphenated and  where.   Hy‐\nphenation  does  not always occur even when the hyphenation rules for a word allow it; it can\nbe disabled, and when not disabled there are several parameters that can prevent it  in  cer‐\ntain circumstances.\n\nOnce  an output line is full, the next word (or remainder of a hyphenated one) is placed on a\ndifferent output line; this is called a break.  In this document and in roff discussions gen‐\nerally, a “break” if not further qualified always refers to  the  termination  of  an  output\nline.   When the formatter is filling text, it introduces breaks automatically to keep output\nlines from exceeding the configured line length.  After an automatic break, a roff  formatter\nadjusts  the  line if applicable (see below), and then resumes collecting and filling text on\nthe next output line.\n\nSometimes, a line cannot be broken automatically.  This usually does not happen with  natural\nlanguage  text  unless the output line length has been manipulated to be extremely short, but\nit can with specialized text like program source code.  groff provides a means of telling the\nformatter where the line may be broken without hyphens.  This is done with  the  non-printing\nbreak point escape sequence \\:.\n\nThere  are  several  ways to cause a break at a predictable location.  A blank input line not\nonly causes a break, but by default it also outputs a one-line vertical space (effectively  a\nblank  output  line).   Macro  packages may discourage or disable this “blank line method” of\nparagraphing in favor of their own macros.  A line that begins with one or more spaces causes\na break.  The spaces are output at the beginning of the next line without being adjusted (see\nbelow).  Again, macro packages may provide other methods of  producing  indented  paragraphs.\nTrailing spaces on text lines (see below) are discarded.  The end of input causes a break.\n\nAfter the formatter performs an automatic break, it may then adjust the line, widening inter-\nword  spaces  until  the  text reaches the right margin.  Extra spaces between words are pre‐\nserved.  Leading and trailing spaces are handled as noted above.  Text can be aligned to  the\nleft or right margin only, or centered, using requests.\n\nA  roff formatter translates horizontal tab characters, also called simply “tabs”, in the in‐\nput into movements to the next tab stop.  These tab stops are by default located  every  half\ninch  measured  from the current position on the input line.  With them, simple tables can be\nmade.  However, this method can be deceptive, as the appearance (and width) of the text in an\neditor and the results from the formatter can vary greatly,  particularly  when  proportional\ntypefaces  are used.  A tab character does not cause a break and therefore does not interrupt\nfilling.  The formatter provides facilities for sophisticated table  composition;  there  are\nmany details to track when using the “tab” and “field” low-level features, so most users turn\nto the tbl(1) preprocessor to lay out tables.\n",
            "subsections": [
                {
                    "name": "Requests and macros",
                    "content": "A  request is an instruction to the formatter that occurs after a control character, which is\nrecognized at the beginning of an input line.  The regular control character is  a  dot  “.”.\nIts  counterpart,  the  no-break  control character, a neutral apostrophe “'”, suppresses the\nbreak implied by some requests.  These characters were chosen  because  it  is  uncommon  for\nlines  of text in natural languages to begin with them.  If you require a formatted period or\napostrophe (closing single quotation mark) where the formatter is expecting a control charac‐\nter, prefix the dot or neutral apostrophe with the dummy character escape sequence, “\\&”.\n\nAn input line beginning with a control character is called a control line.  Every line of in‐\nput that is not a control line is a text line.\n\nRequests often take arguments, words (separated from the  request  name  and  each  other  by\nspaces)  that  specify  details of the action the formatter is expected to perform.  If a re‐\nquest is meaningless without arguments, it is typically ignored.  Of key importance  are  the\nrequests  that  define macros.  Macros are invoked like requests, enabling the request reper‐\ntoire to be extended or overridden.\n\nA macro can be thought of as an abbreviation you can define for a collection of  control  and\ntext lines.  When the macro is called by giving its name after a control character, it is re‐\nplaced  with  what  it stands for.  The process of textual replacement is known as interpola‐\ntion.  Interpolations are handled as soon as they are recognized, and once performed, a  roff\nformatter scans the replacement for further requests, macro calls, and escape sequences.\n\nIn roff systems, the “de” request defines a macro.\n"
                },
                {
                    "name": "Page geometry",
                    "content": "roff  systems  format  text under certain assumptions about the size of the output medium, or\npage.  For the formatter to correctly break a line it is  filling,  it  must  know  the  line\nlength,  which  it  derives from the page width.  For it to decide whether to write an output\nline to the current page or wait until the next one, it must know the  page  length.   A  de‐\nvice's  resolution converts practical units like inches or centimeters to basic units, a con‐\nvenient length measure for the output device or file format.  The formatter and output driver\nuse basic units to reckon page measurements.  The device description file defines its resolu‐\ntion and page dimensions (see grofffont(5)).\n\nA page is a two-dimensional structure upon which a roff system imposes a rectangular  coordi‐\nnate  system  with its upper left corner as the origin.  Coordinate values are in basic units\nand increase down and to the right.  Useful ones are therefore always positive and within nu‐\nmeric ranges corresponding to the page boundaries.\n\nWhile the formatter (and, later, output driver) is processing a page, it keeps track  of  its\ndrawing  position,  which is the location at which the next glyph will be written, from which\nthe next motion will be measured, or where a geometric object will commence  rendering.   No‐\ntionally,  glyphs  are drawn from the text baseline upward and to the right.  (groff does not\nyet support right-to-left scripts.)  The text baseline is a  (usually  invisible)  line  upon\nwhich  the  glyphs  of a typeface are aligned.  A glyph therefore “starts” at its bottom-left\ncorner.  If drawn at the origin, a typical letter glyph would lie partially or wholly off the\npage, depending on whether, like “g”, it features a descender below the baseline.\n\nSuch a situation is nearly always undesirable.  It is furthermore conventional not  to  write\nor  draw  at the extreme edges of the page.  Therefore the initial drawing position of a roff\nformatter is not at the origin, but below and to the right of it.  This rightward shift  from\nthe  left  edge is known as the page offset.  (groff's terminal output devices have page off‐\nsets of zero.)  The downward shift leaves room for a text output line.\n\nText is arranged on a one-dimensional lattice of text baselines from the top to the bottom of\nthe page.  Vertical spacing is the distance between  adjacent  text  baselines.   Typographic\ntradition sets this quantity to 120% of the type size.  The initial vertical drawing position\nis one unit of vertical spacing below the page top.  Typographers term this unit a vee.\n\nVertical  spacing  has an impact on page-breaking decisions.  Generally, when a break occurs,\nthe formatter moves the drawing position to the next text  baseline  automatically.   If  the\nformatter  were already writing to the last line that would fit on the page, advancing by one\nvee would place the next text baseline off the page.  Rather than let that happen, roff  for‐\nmatters  instruct  the  output  driver  to eject the page, start a new one, and again set the\ndrawing position to one vee below the page top; this is a page break.\n\nWhen the last line of input text corresponds to the last output line that fits on  the  page,\nthe break caused by the end of input will also break the page, producing a useless blank one.\nMacro  packages  keep users from having to confront this difficulty by setting “traps”; more‐\nover, all but the simplest page layouts tend to have headers and footers, or  at  least  bear\nvertical margins larger than one vee.\n"
                },
                {
                    "name": "Other language elements",
                    "content": "Escape sequences start with the escape character, a backslash \\, and are followed by at least\none additional character.  They can appear anywhere in the input.\n\nWith  requests,  the  escape  and control characters can be changed; further, escape sequence\nrecognition can be turned off and back on.\n\nStrings store character sequences.  In groff, they can be parameterized as macros can.\n\nRegisters store numerical values, including measurements.  The latter are generally in  basic\nunits;  scaling  units  can  be appended to numeric expressions to clarify their meaning when\nstored or interpolated.  Some read-only predefined registers interpolate text.\n\nFonts are identified either by a name or by a  mounting  position  (a  non-negative  number).\nFour styles are available on all devices.  R is “roman”: normal, upright text.  B is bold, an\nupright  typeface  with  a heavier weight.  I is italic, a face that is oblique on typesetter\noutput devices and usually underlined instead on terminal devices.  BI is  bold-italic,  com‐\nbining  both  of the foregoing style variations.  Typesetting devices group these four styles\ninto families of text fonts; they also typically offer one or more special fonts that provide\nunstyled glyphs; see groffchar(7).\n\ngroff supports named colors for glyph rendering and drawing of geometric objects.  Stroke and\nfill colors are distinct; the stroke color is used for glyphs.\n\nGlyphs are visual representation forms of characters.   In  groff,  the  distinction  between\nthose  two  elements  is  not always obvious (and a full discussion is beyond our scope).  In\nbrief, “A” is a character when we consider it in the abstract: to make it a  glyph,  we  must\nselect  a  typeface with which to render it, and determine its type size and color.  The for‐\nmatting process turns input characters into output glyphs.  A few characters commonly seen on\nkeyboards are treated specially by the roff language and may not look correct  in  output  if\nused  unthinkingly; they are the (double) quotation mark (\"), the neutral apostrophe ('), the\nminus sign (-), the backslash (\\), the caret or circumflex accent (^), the grave accent  (`),\nand  the  tilde (~).  All of these and more can be produced with special character escape se‐\nquences; see groffchar(7).\n\ngroff offers streams, identifiers for writable files, but for security reasons  this  feature\nis disabled by default.\n\nA  further  few language elements arise as page layouts become more sophisticated and demand‐\ning.  Environments collect formatting parameters like line length and typeface.  A  diversion\nstores  formatted output for later use.  A trap is a condition on the input or output, tested\nautomatically by the formatter, that is associated with a macro, calling it when that  condi‐\ntion is fulfilled.\n\nFootnote  support  often exercises all three of the foregoing features.  A simple implementa‐\ntion might work as follows.  A pair of macros is defined: one starts a footnote and the other\nends it.  The author calls the first macro where a footnote marker is desired.  The macro es‐\ntablishes a diversion so that the footnote text is collected at the place in  the  body  text\nwhere  its  corresponding marker appears.  An environment is created for the footnote so that\nit is set at a smaller typeface.  The footnote text is formatted in the diversion using  that\nenvironment,  but  it does not yet appear in the output.  The document author calls the foot‐\nnote end macro, which returns to the previous environment and ends the diversion.  Later, af‐\nter much more body text in the document, a trap, set a small distance above the page  bottom,\nis  sprung.   The  macro called by the trap draws a line across the page and emits the stored\ndiversion.  Thus, the footnote is rendered.\n"
                }
            ]
        },
        "History": {
            "content": "Computer-driven document formatting dates back to the 1960s.  The roff system  is  intimately\nconnected  with Unix, but its origins lie with the earlier operating systems CTSS, GECOS, and\nMultics.\n",
            "subsections": [
                {
                    "name": "The predecessor—RUNOFF",
                    "content": "roff's ancestor RUNOFF was written in the MAD language by Jerry Saltzer to prepare his  Ph.D.\nthesis on the Compatible Time Sharing System (CTSS), a project of the Massachusetts Institute\nof  Technology  (MIT).   This program is referred to in full capitals, both to distinguish it\nfrom its many descendants, and because bits were expensive in those days; five-  and  six-bit\ncharacter  encodings were still in widespread usage, and mixed-case alphabetics in file names\nseen as a luxury.  RUNOFF introduced a syntax of inlining formatting directives amid document\ntext, by beginning a line with a period (an unlikely occurrence in  human-readable  material)\nfollowed  by a “control word”.  Control words with obvious meaning like “.line length n” were\nsupported as well as an abbreviation system; the latter came to overwhelm the former in popu‐\nlar usage and later derivatives of the program.  A sample of control words from a RUNOFF man‐\nual of December 1966 was documented as follows (with  the  parameter  notation  slightly  al‐\ntered).  The abbreviations will be familiar to roff veterans.\n\nAbbreviation   Control word\n.ad   .adjust\n.bp   .begin page\n.br   .break\n.ce   .center\n.in   .indent n\n.ll   .line length n\n.nf   .nofill\n.pl   .paper length n\n.sp   .space [n]\n\nIn  1965, MIT's Project MAC teamed with Bell Telephone Laboratories and General Electric (GE)\nto inaugurate the Multics project.  After a few years, Bell Labs discontinued its  participa‐\ntion  in  Multics,  famously  prompting the development of Unix.  Meanwhile, Saltzer's RUNOFF\nproved influential, seeing many ports and derivations elsewhere.\n\nIn 1969, Doug McIlroy wrote one such reimplementation, adding extensions, in  the  BCPL  lan‐\nguage  for  a  GE 645 running GECOS at the Bell Labs location in Murray Hill, New Jersey.  In\nits manual, the control commands were termed “requests”, their two-letter names were  canoni‐\ncal,  and the control character was configurable with a .cc request.  Other familiar requests\nemerged at this time; no-adjust (.na), need (.ne), page offset (.po), tab configuration (.ta,\nthough it worked differently), temporary indent (.ti), character translation (.tr), and auto‐\nmatic underlining (.ul; on RUNOFF you had to backspace and underscore in the input yourself).\n.fi to enable filling of output lines got the name it retains to this day.  McIlroy's program\nalso featured a heuristic system for automatically placing hyphenation points,  designed  and\nimplemented  by Molly Wagner.  It furthermore introduced numeric variables, termed registers.\nBy 1971, this program had been ported to Multics and was known as roff, a  name  McIlroy  at‐\ntributes to Bob Morris, to distinguish it from CTSS RUNOFF.\n"
                },
                {
                    "name": "Unix and roff",
                    "content": "McIlroy's  roff  was  one of the first Unix programs.  In Ritchie's term, it was “transliter‐\nated” from BCPL to DEC PDP-7 assembly language for the fledgling Unix operating system.   Au‐\ntomatic  hyphenation was managed with .hc and .hy requests, line spacing control was general‐\nized with the .ls request, and what later roffs would  call  diversions  were  available  via\n“footnote”  requests.  This roff indirectly funded operating systems research at Murray Hill;\nAT&T prepared patent applications to the U.S. government with it.  This  arrangement  enabled\nthe  group to acquire a PDP-11; roff promptly proved equal to the task of formatting the man‐\nual for what would become known as “First Edition Unix”, dated November 1971.\n\nOutput from all of the foregoing programs was limited to line printers  and  paper  terminals\nsuch  as  the IBM 2471 (based on the Selectric line of typewriters) and the Teletype Corpora‐\ntion Model 37.  Proportionally spaced type was unavailable.\n"
                },
                {
                    "name": "New _roff_ and Typesetter roff",
                    "content": "The first years of Unix were spent in rapid evolution.  The practicalities of preparing stan‐\ndardized documents like patent applications (and Unix manual pages), combined with  McIlroy's\nenthusiasm  for macro languages, perhaps created an irresistible pressure to make roff exten‐\nsible.  Joe Ossanna's nroff, literally a “new roff”, was the outlet for  this  pressure.   By\nthe time of Unix Version 3 (February 1973)—and still in PDP-11 assembly language—it sported a\nswath  of  features now considered essential to roff systems: definition of macros (.de), di‐\nversion of text thither (.di), and removal thereof (.rm); trap planting (.wh; “when”) and re‐\nlocation (.ch; “change”); conditional processing (.if); and environments (.ev).   Incremental\nimprovements  included  assignment  of  the  next  page number (.pn); no-space mode (.ns) and\nrestoration of vertical spacing (.rs); the saving (.sv) and output (.os) of  vertical  space;\nspecification  of  replacement  characters for tabs (.tc) and leaders (.lc); configuration of\nthe no-break control character (.c2); shorthand to disable  automatic  hyphenation  (.nh);  a\ncondensation  of what were formerly six different requests for configuration of page “titles”\n(headers and footers) into one (.tl) with a length controlled separately from the line length\n(.lt); automatic line numbering (.nm); interactive input (.rd),  which  necessitated  buffer-\nflushing  (.fl),  and was made convenient with early program cessation (.ex); source file in‐\nclusion in its modern form (.so; though RUNOFF had an “.append” control word  for  a  similar\npurpose) and early advance to the next file argument (.nx); ignorable content (.ig); and pro‐\ngrammable abort (.ab).\n\nThird  Edition Unix also brought the pipe(2) system call, the explosive growth of a componen‐\ntized system based around it, and a “filter model” that remains perceptible  today.   Equally\nimportantly, the Bell Labs site in Murray Hill acquired a Graphic Systems C/A/T phototypeset‐\nter,  and  with  it came the necessity of expanding the capabilities of a roff system to cope\nwith a variety of proportionally spaced typefaces at multiple sizes.  Ossanna wrote a  paral‐\nlel  implementation of nroff for the C/A/T, dubbing it troff (for “typesetter roff”).  Unfor‐\ntunately, surviving documentation does not illustrate what requests were implemented at  this\ntime for C/A/T support; the troff(1) man page in Fourth Edition Unix (November 1973) does not\nfeature  a  request  list, unlike nroff(1).  Apart from typesetter-driven features, Unix Ver‐\nsion 4 roffs added string definitions (.ds); made the escape  character  configurable  (.ec);\nand  enabled  the user to write diagnostics to the standard error stream (.tm).  Around 1974,\nempowered with multiple type sizes, italics, and a symbol font specially commissioned by Bell\nLabs from Graphic Systems, Kernighan and Lorinda Cherry implemented eqn for typesetting math‐\nematics.  In the same year, for Fifth Edition Unix, Ossanna combined  and  reimplemented  the\ntwo  roffs  in  C,  using  that language's preprocessor to generate both from a single source\ntree.\n\nOssanna documented the syntax of the input language to the nroff and troff  programs  in  the\n“Troff  User's  Manual”,  first  published in 1976, with further revisions as late as 1992 by\nKernighan.  (The original version was entitled “Nroff/Troff User's Manual”,  which  may  par‐\ntially explain why roff practitioners have tended to refer to it by its AT&T document identi‐\nfier,  “CSTR  #54”.)   Its final revision serves as the de facto specification of AT&T troff,\nand all subsequent implementors of roff systems have done so in its shadow.\n\nA small and simple set of roff macros was first used for the manual pages of Unix  Version  4\nand  persisted for two further releases, but the first macro package to be formally described\nand installed was ms by Michael Lesk in Version 6.  He also wrote a manual, “Typing Documents\non the Unix System”, describing ms and basic nroff/troff usage, updating it  as  the  package\naccrued  features.  Sixth Edition additionally saw the debut of the tbl preprocessor for for‐\nmatting tables, also by Lesk.\n\nFor Unix Version 7 (January 1979), McIlroy designed,  implemented,  and  documented  the  man\nmacro  package,  introducing  most  of the macros described in groffman(7) today, and edited\nvolume 1 of the Version 7 manual using it.  Documents composed using ms featured in volume 2,\nedited by Kernighan.\n\nMeanwhile, troff proved popular even at Unix sites that lacked a C/A/T device.  Tom Ferrin of\nthe University of California at San Francisco combined it with Allen Hershey's popular vector\nfonts to produce vtroff, which translated troff's output to the command language used by Ver‐\nsatec and Benson-Varian plotters.\n\nOssanna had passed away unexpectedly in 1977, and after the release of Version  7,  with  the\nC/A/T typesetter becoming supplanted by alternative devices such as the Mergenthaler Linotron\n202, Kernighan undertook a revision and rewrite of troff to generalize its design.  To imple‐\nment this revised architecture, he developed the font and device description file formats and\nthe  page description language that remain in use today.  He described these novelties in the\narticle “A Typesetter-independent TROFF”, last revised in 1982, and like the troff manual it‐\nself, it is widely known by a shorthand, “CSTR #97”.\n\nKernighan's innovations prepared troff well for the introduction of the Adobe PostScript lan‐\nguage in 1982 and a vibrant market in laser printers with built-in interpreters for  it.   An\noutput driver for PostScript, dpost, was swiftly developed.  However, AT&T's software licens‐\ning  practices  kept Ossanna's troff, with its tight coupling to the C/A/T's capabilities, in\nparallel distribution with device-independent troff throughout the  1980s.   Today,  however,\nall actively maintained troffs follow Kernighan's device-independent design.\n\ngroff—a free roff from GNU\nThe  most  important free roff project historically has been groff, the GNU implementation of\ntroff, developed by James Clark starting in 1989 and distributed under copyleft licenses, en‐\nsuring to all the availability of source code and the freedom to modify and redistribute  it,\nproperties  unprecedented  in  roff systems to that point.  groff rapidly attracted contribu‐\ntors, and has served as a replacement for almost all applications of AT&T  troff  (exceptions\ninclude  mv,  a  macro  package  for preparation of viewgraphs and slides, and the ideal pre‐\nprocessor, which produces diagrams from mathematical constraints).  Beyond that, it has added\nnumerous features; see groffdiff(7).  Since its inception and for  at  least  the  following\nthree decades, it has been used by practically all GNU/Linux and BSD operating systems.\n\ngroff  continues to be developed, is available for almost all operating systems in common use\n(along with several obscure ones), and is free.  These factors make groff the de  facto  roff\nstandard today.\n"
                },
                {
                    "name": "Other free _roff_s",
                    "content": "In  2007, Caldera/SCO and Sun Microsystems, having acquired rights to AT&T Documenter's Work‐\nbench (DWB) troff (a descendant of the Bell Labs code), released it under a free but  GPL-in‐\ncompatible  license.   This implementation  was  made  portable  to modern POSIX systems, and\nadopted and enhanced first by Gunnar Ritter and then Carsten Kunze to  produce  Heirloom Doc‐\ntools troff.\n\nIn  July  2013,  Ali Gholami Rudi announced neatroff, a permissively licensed new implementa‐\ntion.\n\nAnother descendant of DWB troff is part of Plan 9 from User Space.  Since  2021,  this  troff\nhas been available under permissive terms.\n"
                }
            ]
        },
        "Using roff": {
            "content": "When  you  read  a man page, often a roff is the program rendering it.  Some roff implementa‐\ntions provide wrapper programs that make it easy to use the roff system from the shell's com‐\nmand line.  These can be specific to a  macro  package,  like  mmroff(1),  or  more  general.\ngroff(1) provides command-line options sparing the user from constructing the long, order-de‐\npendent  pipelines  familiar  to AT&T troff users.  Further, a heuristic program, grog(1), is\navailable to infer from a document's contents which groff arguments should be used to process\nit.\n",
            "subsections": [
                {
                    "name": "The _roff_ pipeline",
                    "content": "A typical roff document is prepared by running one or more processors in series, followed  by\na a formatter program and then an output driver (or “device postprocessor”).  Commonly, these\nprograms  are structured into a pipeline; that is, each is run in sequence such that the out‐\nput of one is taken as the input to the next, without passing through secondary storage.  (On\nnon-Unix systems, pipelines may have to be simulated with temporary files.)\n\n$ preproc1 < input-file | preproc2 | ... | troff [option] ... \\\n| output-driver\n\nOnce all preprocessors have run, they deliver pure roff  language  input  to  the  formatter,\nwhich in turn generates a document in a page description language that is then interpreted by\na postprocessor for viewing, printing, or further processing.\n\nEach  program  interprets  input  in  a  language that is independent of the others; some are\npurely descriptive, as with tbl(1) and roff output, and some permit the definition of macros,\nas with eqn(1) and roff input.  Most roff input files employ the macros of a document format‐\nting package, intermixed with instructions for one or more preprocessors, and  seasoned  with\nescape  sequences  and  requests  from  the roff language.  Some documents are simpler still,\nsince their formatting packages discourage direct use of  roff  requests;  man  pages  are  a\nprominent  example.   Many features of the roff language are seldom needed by users; only au‐\nthors of macro packages require a substantial command of them.\n"
                },
                {
                    "name": "Preprocessors",
                    "content": "A roff preprocessor is a program that, directly or ultimately, generates output in  the  roff\nlanguage.  Typically, each preprocessor defines a language of its own that transforms its in‐\nput  into  that for roff or another preprocessor.  As an example of the latter, chem produces\npic input.  Preprocessors must consequently be run in an appropriate order; groff(1)  handles\nthis automatically for all preprocessors supplied by the GNU roff system.\n\nPortions  of  the  document written in preprocessor languages are usually bracketed by tokens\nthat look like roff macro calls.  roff preprocessor programs transform only  the  regions  of\nthe document intended for them.  When a preprocessor language is used by a document, its cor‐\nresponding  program  must  process it before the input is seen by the formatter, or incorrect\nrendering is almost guaranteed.\n\nGNU roff provides several preprocessors, including eqn, grn, pic,  tbl,  refer,  and  soelim.\nSee groff(1) for a complete list.  Other preprocessors for roff systems are known.\n\ndformat   depicts data structures;\ngrap      constructs statistical charts; and\nideal     draws diagrams using a constraint-based language.\n"
                },
                {
                    "name": "Formatter programs",
                    "content": "A roff formatter transforms roff language input into a single file in a page description lan‐\nguage,  described  in  groffout(5), intended for processing by a selected device.  This page\ndescription language is specialized in its parameters, but not its syntax, for  the  selected\ndevice;  the  format is device-independent, but not device-agnostic.  The parameters the for‐\nmatter uses to arrange the document are stored in device  and  font  description  files;  see\ngrofffont(5).\n\nAT&T Unix had two formatters—nroff for terminals, and troff for typesetters.  Often, the name\ntroff  is used loosely to refer to both.  When generalizing thus, groff documentation prefers\nthe term “roff”.  In GNU roff, the formatter program is always troff(1).\n"
                },
                {
                    "name": "Devices and output drivers",
                    "content": "To a roff system, a device is a hardware interface like a printer, a text or graphical termi‐\nnal, or a standardized file format that unrelated software can interpret.  An  output  driver\nis a program that parses the output of troff and produces instructions specific to the device\nor file format it supports.  An output driver might support multiple devices, particularly if\nthey are similar.\n\nThe names of the devices and their driver programs are not standardized.  Technological fash‐\nions  evolve;  the devices used for document preparation when AT&T troff was first written in\nthe 1970s are no longer used in production environments.  Device capabilities have tended  to\nincrease, improving resolution and font repertoire, and adding color output and hyperlinking.\nFurther,  to  reduce  file  size  and processing time, AT&T troff's page description language\nplaced low limits on the magnitudes of some quantities it could  represent.   Its  PostScript\noutput  driver,  dpost(1),  had  a  resolution  of  720 units per inch; groff's grops(1) uses\n72,000.\n\nroff programming\nDocuments using roff are normal text files interleaved with roff  formatting  elements.   The\nroff  language is powerful enough to support arbitrary computation and it supplies facilities\nthat encourage extension.  The primary such facility is macro definition; with this  feature,\nmacro packages have been developed that are tailored for particular applications.\n"
                },
                {
                    "name": "Macro packages",
                    "content": "Macro  packages can have a much smaller vocabulary than roff itself; this trait combined with\ntheir domain-specific nature can make them easy to acquire and master.  The macro definitions\nof a package are typically kept in a file called name.tmac (historically,  tmac.name).   Find\ndetails on the naming and placement of macro packages in grofftmac(5).\n\nA  macro  package  anticipated  for use in a document can be declared to the formatter by the\ncommand-line option -m; see troff(1).  It can alternatively be specified  within  a  document\nusing the mso request of the groff language; see groff(7).\n\nWell-known macro packages include man for traditional man pages and mdoc for BSD-style manual\npages.   Macro  packages for typesetting books, articles, and letters include ms (from “manu‐\nscript macros”), me (named by a system administrator from the first name of its creator, Eric\nAllman), mm (from “memorandum macros”), and mom, a punningly named  package  exercising  many\ngroff extensions.  See grofftmac(5) for more.\n"
                },
                {
                    "name": "The _roff_ formatting language",
                    "content": "The  roff  language  provides requests, escape sequences, macro definition facilities, string\nvariables, registers for storage of numbers or dimensions, and  control  of  execution  flow.\nThe  theoretically minded will observe that a roff is not a mere markup language, but Turing-\ncomplete.  It has storage (registers), it can perform tests (as  in  conditional  expressions\nlike “(\\n[i] >= 1)”), its “if” and related requests alter the flow of control, and macro def‐\ninition permits unbounded recursion.\n\nRequests  and  escape sequences are instructions, predefined parts of the language, that per‐\nform formatting operations, interpolate stored material, or otherwise change the state of the\nparser.  The user can define their own request-like elements by composing together text,  re‐\nquests,  and escape sequences ad libitum.  A document writer will not (usually) note any dif‐\nference in usage for requests or macros; both are found on control lines.  However, there  is\na  distinction;  requests  take either a fixed number of arguments (sometimes zero), silently\nignoring any excess, or consume the rest of the input line, whereas macros can take  a  vari‐\nable number of arguments.  Since arguments are separated by spaces, macros require a means of\nembedding  a space in an argument; in other words, of quoting it.  This then demands a mecha‐\nnism of embedding the quoting character itself, in case it is needed literally in a macro ar‐\ngument.  AT&T troff had complex rules involving the placement and repetition  of  the  double\nquote  to  achieve  both aims.  groff cuts this knot by supporting a special character escape\nsequence for the neutral double quote, “\\[dq]”, which never performs quoting in the  typeset‐\nting language, but is simply a glyph, ‘\"’.\n\nEscape  sequences  start with a backslash, “\\”.  They can appear almost anywhere, even in the\nmidst of text on a line, and implement various features, including the insertion  of  special\ncharacters  with  “\\(xx” or “\\[xxx]”, break suppression at input line endings with “\\c”, font\nchanges with “\\f”, type size changes with “\\s”, in-line comments with “\\\"”, and many others.\n\nStrings store text.  They are populated with the ds request and interpolated using the \\* es‐\ncape sequence.\n\nRegisters store numbers and measurements.  A register can be set with the request nr and  its\nvalue can be retrieved by the escape sequence \\n.\n"
                }
            ]
        },
        "File naming conventions": {
            "content": "The  structure or content of a file name, beyond its location in the file system, is not sig‐\nnificant to  roff  tools.   roff  documents  employing  “full-service”  macro  packages  (see\ngrofftmac(5)) tend to be named with a suffix identifying the package; we thus see file names\nending  in .man, .ms, .me, .mm, and .mom, for instance.  When installed, man pages tend to be\nnamed with the manual's section number as the suffix.  For example, the file  name  for  this\ndocument is roff.7.  Practice for “raw” roff documents is less consistent; they are sometimes\nseen with a .t suffix.\n",
            "subsections": []
        },
        "Input conventions": {
            "content": "Since troff fills text automatically, it is common practice in the roff language to avoid vi‐\nsual  composition of text in input files: the esthetic appeal of the formatted output is what\nmatters.  Therefore, roff input should be arranged such that it is easy for authors and main‐\ntainers to compose and develop the document, understand the syntax of  roff  requests,  macro\ncalls,  and  preprocessor languages used, and predict the behavior of the formatter.  Several\ntraditions have accrued in service of these goals.\n\n• Follow sentence endings in the input with newlines to ease their recognition.  It  is  fre‐\nquently  convenient  to  end text lines after colons and semicolons as well, as these typi‐\ncally precede independent clauses.  Consider doing so after commas;  they  often  occur  in\nlists that become easy to scan when itemized by line, or constitute supplements to the sen‐\ntence  that are added, deleted, or updated to clarify it.  Parenthetical and quoted phrases\nare also good candidates for placement on text lines by themselves.\n\n• Set your text editor's line length to 72 characters or fewer; see  the  subsections  below.\nThis  limit,  combined with the previous item of advice, makes it less common that an input\nline will wrap in your text editor, and thus will help you perceive excessively  long  con‐\nstructions  in  your text.  Recall that natural languages originate in speech, not writing,\nand that punctuation is correlated with pauses for breathing and changes in prosody.\n\n• Use \\& after “!”, “?”, and “.” if they are followed by space, tab,  or  newline  characters\nand don't end a sentence.\n\n• In  filled text lines, use \\& before “.” and “'” if they are preceded by space, so that re‐\nflowing the input doesn't turn them into control lines.\n\n• Do not use spaces to perform indentation or align columns of a table.  Leading  spaces  are\nreliable when text is not being filled.\n\n• Comment your document.  It is never too soon to apply comments to record information of use\nto future document maintainers (including your future self).  The \\\" escape sequence causes\ntroff to ignore the remainder of the input line.\n\n• Use  the  empty  request—a  control character followed immediately by a newline—to visually\nmanage separation of material in input files.  Many of the groff  project's  own  documents\nuse  an  empty request between sentences, after macro definitions, and where a break is ex‐\npected, and two empty requests between paragraphs or other requests  or  macro  calls  that\nwill  introduce  vertical  space into the document.  You can combine the empty request with\nthe comment escape sequence to include whole-line comments in your document, and even “com‐\nment out” sections of it.\n\nAn example sufficiently long to illustrate most of the above suggestions in practice follows.\nAn arrow → indicates a tab character.\n\n.\\\"   nroff thisfile.roff | less\n.\\\"   groff -T ps thisfile.roff > thisfile.ps\n→The theory of relativity is intimately connected with\nthe theory of space and time.\n.\nI shall therefore begin with a brief investigation of\nthe origin of our ideas of space and time,\nalthough in doing so I know that I introduce a\ncontroversial subject.  \\\" remainder of paragraph elided\n.\n.\n\n→The experiences of an individual appear to us arranged\nin a series of events;\nin this series the single events which we remember\nappear to be ordered according to the criterion of\n\\[lq]earlier\\[rq] and \\[lq]later\\[rq], \\\" punct swapped\nwhich cannot be analysed further.\n.\nThere exists,\ntherefore,\nfor the individual,\nan I-time,\nor subjective time.\n.\nThis itself is not measurable.\n.\nI can,\nindeed,\nassociate numbers with the events,\nin such a way that the greater number is associated with\nthe later event than with an earlier one;\nbut the nature of this association may be quite\narbitrary.\n.\nThis association I can define by means of a clock by\ncomparing the order of events furnished by the clock\nwith the order of a given series of events.\n.\nWe understand by a clock something which provides a\nseries of events which can be counted,\nand which has other properties of which we shall speak\nlater.\n.\\\" Albert Einstein, The Meaning of Relativity, 1922\n",
            "subsections": [
                {
                    "name": "Editing with Emacs",
                    "content": "Official GNU doctrine holds that the best program for editing a roff document is  Emacs;  see\nemacs(1).   It  provides an nroff major mode that is suitable for all kinds of roff dialects.\nThis mode can be activated by the following methods.\n\nWhen editing a file within Emacs the mode can be changed by typing “M-x nroff-mode”, where M-\nx means to hold down the meta key (often labelled “Alt”) while pressing and releasing the “x”\nkey.\n\nIt is also possible to have the mode automatically selected when a roff file is  loaded  into\nthe editor.\n\n• The  most  general method is to include file-local variables at the end of the file; we can\nalso configure the fill column this way.\n\n.\\\" Local Variables:\n.\\\" fill-column: 72\n.\\\" mode: nroff\n.\\\" End:\n\n• Certain file name extensions, such as those commonly used by man pages, trigger  the  auto‐\nmatic activation of the nroff mode.\n\n• Technically, having the sequence\n\n.\\\" -*- nroff -*-\n\nin  the  first  line  of  a  file will cause Emacs to enter the nroff major mode when it is\nloaded into the buffer.  Unfortunately, some implementations of the man(1) program are con‐\nfused by this practice, so we discourage it.\n"
                },
                {
                    "name": "Editing with Vim",
                    "content": "Other editors provide support for roff-style files too, such as vim(1), an extension  of  the\nvi(1)  program.   Vim's highlighting can be made to recognize roff files by setting the file‐\ntype option in a Vim modeline.  For this feature to work, your copy of vim must be built with\nsupport for, and configured to enable, several features; consult  the  editor's  online  help\ntopics  “auto-setting”,  “filetype”, and “syntax”.  Then put the following at the end of your\nroff files, after any Emacs configuration:\n\n.\\\" vim: set filetype=groff textwidth=72:\n\nReplace “groff” in the above with “nroff” if you want highlighting that  does  not  recognize\nmany  of  the GNU extensions to roff, such as request, register, and string names longer than\ntwo characters.\n"
                }
            ]
        },
        "Authors": {
            "content": "This document was written by Bernd Warken and G. Branden Robinson.\n\nSee also\nMuch roff documentation is available.  The Bell Labs  papers  describing  AT&T  troff  remain\navailable, and groff is documented comprehensively.\n",
            "subsections": [
                {
                    "name": "Internet sites",
                    "content": "Unix Text Processing,  by Dale Dougherty and Tim O'Reilly, 1987, Hayden Books.  This well-re‐\ngarded text brings the reader from a state of no knowledge of Unix or text editing (if neces‐\nsary) to sophisticated computer-aided typesetting.  It has been placed under a free  software\nlicense by its authors and updated by a team of groff contributors and enthusiasts.\n\n“History of Unix Manpages”,  an  online article maintained by the mdocml project, provides an\noverview of roff development from Saltzer's RUNOFF to 2008, with links to original documenta‐\ntion and recollections of the authors and their contemporaries.\n\ntroff.org, Ralph Corderoy's troff site, provides an overview and pointers to much  historical\nroff information.\n\nMulticians,  a site by Multics enthusiasts, contains a lot of information on the MIT projects\nCTSS and Multics, including RUNOFF; it is especially useful for its  glossary  and  the  many\nlinks to historical documents.\n\nThe Unix Archive, curated by the Unix Heritage Society, provides the source code and some bi‐\nnaries of historical Unices (including the source code of some versions of troff and its doc‐\numentation) contributed by their copyright holders.\n\nJerry Saltzer's home page  stores  some  documents  using the original RUNOFF formatting lan‐\nguage.\n\ngroff, GNU roff's web site, provides convenient access to groff's source code repository, bug\ntracker, and mailing lists (including archives and the subscription interface).\n"
                },
                {
                    "name": "Historical _roff_ documentation",
                    "content": "Many AT&T troff documents are available online, and can be found  at  Ralph  Corderoy's  site\n(see above) or via Internet search.\n\nOf  foremost  significance  are two mentioned in section “History” above, describing the lan‐\nguage and its device-independent implementation, respectively.\n\n“Troff User's Manual” by Joseph F. Ossanna, 1976 (revised by Brian W. Kernighan, 1992),  AT&T\nBell Laboratories Computing Science Technical Report No. 54.\n\n“A  Typesetter-independent TROFF” by Brian W. Kernighan, 1982, AT&T Bell Laboratories Comput‐\ning Science Technical Report No. 97.\n\nYou can obtain many relevant Bell Labs papers  in  PDF  from  Bernd Warken's “roff classical”\nGitHub repository.\n"
                },
                {
                    "name": "Manual pages",
                    "content": "As  a  system  of multiple components, a roff system potentially has many man pages, each de‐\nscribing an aspect of it.  Unfortunately, there is no  consistent  naming  scheme  for  these\npages among the different roff implementations.\n\nFor GNU roff, the groff(1) man page enumerates all man pages distributed with the system, and\nindividual  pages  frequently refer to external resources as well as manuals distributed with\ngroff on a variety of topics.\n\nWith other roffs, you are on your own, but troff(1) might be a good starting point.\n\ngroff 1.23.0                                31 March 2024                                    roff(7)"
                }
            ]
        }
    },
    "flags": [],
    "examples": [],
    "see_also": []
}