Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

NetBSD 6.1.5 - man page for mandoc_roff (netbsd section 7)

ROFF(7) 		       BSD Miscellaneous Information Manual			  ROFF(7)

     roff -- roff language reference for mandoc

     The roff language is a general purpose text formatting language.  Since traditional imple-
     mentations of the mdoc(7) and man(7) manual formatting languages are based on it, many real-
     world manuals use small numbers of roff requests intermixed with their mdoc(7) or man(7)
     code.  To properly format such manuals, the mandoc(1) utility supports a tiny subset of roff
     requests.	Only these requests supported by mandoc(1) are documented in the present manual,
     together with the basic language syntax shared by roff, mdoc(7), and man(7).  For complete
     roff manuals, consult the SEE ALSO section.

     Input lines beginning with the control character '.' are parsed for requests and macros.
     Such lines are called ``request lines'' or ``macro lines'', respectively.	Requests change
     the processing state and manipulate the formatting; some macros also define the document
     structure and produce formatted output.  The single quote ("'") is accepted as an alterna-
     tive control character, treated by mandoc(1) just like '.'

     Lines not beginning with control characters are called ``text lines''.  They provide free-
     form text to be printed; the formatting of the text depends on the respective processing

     roff documents may contain only graphable 7-bit ASCII characters, the space character, and,
     in certain circumstances, the tab character.  The back-space character '\' indicates the
     start of an escape sequence for Comments, Special Characters, Predefined Strings, and user-
     defined strings defined using the ds request.

     Text following an escaped double-quote '\"', whether in a request, macro, or text line, is
     ignored to the end of the line.  A request line beginning with a control character and com-
     ment escape '.\"' is also ignored.  Furthermore, request lines with only a control character
     and optional trailing whitespace are stripped from input.

	   .\" This is a comment line.
	   .\" The next line is ignored:
	   .Sh EXAMPLES \" This is a comment, too.
	   example text \" And so is this.

   Special Characters
     Special characters are used to encode special glyphs and are rendered differently across
     output media.  They may occur in request, macro, and text lines.  Sequences begin with the
     escape character '\' followed by either an open-parenthesis '(' for two-character sequences;
     an open-bracket '[' for n-character sequences (terminated at a close-bracket ']'); or a sin-
     gle one character sequence.

	   \(em    Two-letter em dash escape.
	   \e	   One-letter backslash escape.

     See mandoc_char(7) for a complete list.

   Text Decoration
     Terms may be text-decorated using the '\f' escape followed by an indicator: B (bold), I
     (italic), R (regular), or P (revert to previous mode).  A numerical representation 3, 2, or
     1 (bold, italic, and regular, respectively) may be used instead.  The indicator or numerical
     representative may be preceded by C (constant-width), which is ignored.

		   Write in bold, then switch to regular font mode.
		   Write in italic, then return to previous font mode.

     Text decoration is not recommended for mdoc(7), which encourages semantic annotation.

   Predefined Strings
     Predefined strings, like Special Characters, mark special output glyphs.  Predefined strings
     are escaped with the slash-asterisk, '\*': single-character '\*X', two-character '\*(XX',
     and N-character '\*[N]'.

	   \*(Am   Two-letter ampersand predefined string.
	   \*q	   One-letter double-quote predefined string.

     Predefined strings are not recommended for use, as they differ across implementations.
     Those supported by mandoc(1) are listed in mandoc_char(7).  Manuals using these predefined
     strings are almost certainly not portable.

     Whitespace consists of the space character.  In text lines, whitespace is preserved within a
     line.  In request and macro lines, whitespace delimits arguments and is discarded.

     Unescaped trailing spaces are stripped from text line input unless in a literal context.  In
     general, trailing whitespace on any input line is discouraged for reasons of portability.
     In the rare case that a blank character is needed at the end of an input line, it may be
     forced by '\ \&'.

     Literal space characters can be produced in the output using escape sequences.  In macro
     lines, they can also be included in arguments using quotation; see MACRO SYNTAX for details.

     Blank text lines, which may include whitespace, are only permitted within literal contexts.
     If the first character of a text line is a space, that line is printed with a leading new-

   Scaling Widths
     Many requests and macros support scaled widths for their arguments.  The syntax for a scaled
     width is '[+-]?[0-9]*.[0-9]*[:unit:]', where a decimal must be preceded or followed by at
     least one digit.  Negative numbers, while accepted, are truncated to zero.

     The following scaling units are accepted:

	   c	   centimetre
	   i	   inch
	   P	   pica (~1/6 inch)
	   p	   point (~1/72 inch)
	   f	   synonym for 'u'
	   v	   default vertical span
	   m	   width of rendered 'm' (em) character
	   n	   width of rendered 'n' (en) character
	   u	   default horizontal span
	   M	   mini-em (~1/100 em)

     Using anything other than 'm', 'n', 'u', or 'v' is necessarily non-portable across output
     media.  See COMPATIBILITY.

     If a scaling unit is not provided, the numerical value is interpreted under the default
     rules of 'v' for vertical spaces and 'u' for horizontal ones.

	   .Bl -tag -width 2i
	     two-inch tagged list indentation in mdoc(7)
	   .HP 2i
	     two-inch tagged list indentation in man(7)
	   .sp 2v
	     two vertical spaces

   Sentence Spacing
     Each sentence should terminate at the end of an input line.  By doing this, a formatter will
     be able to apply the proper amount of spacing after the end of sentence (unescaped) period,
     exclamation mark, or question mark followed by zero or more non-sentence closing delimiters
     (')', ']', ''', '"').

     The proper spacing is also intelligently preserved if a sentence ends at the boundary of a
     macro line.

	   Do not end sentences mid-line like this.  Instead,
	   end a sentence like this.
	   A macro would end like this:
	   .Xr mandoc 1 .

     A request or macro line consists of:

     1.   the control character '.' or ''' at the beginning of the line,
     2.   optionally an arbitrary amount of whitespace,
     3.   the name of the request or the macro, which is one word of arbitrary length, terminated
	  by whitespace,
     4.   and zero or more arguments delimited by whitespace.

     Thus, the following request lines are all equivalent:

	   .ig end
	   .ig	  end
	   .   ig end

     Macros are provided by the mdoc(7) and man(7) languages and can be defined by the de
     request.  When called, they follow the same syntax as requests, except that macro arguments
     may optionally be quoted by enclosing them in double quote characters ('"').  Quoted text,
     even if it contains whitespace or would cause a macro invocation when unquoted, is always
     considered literal text.  Inside quoted text, pairs of double quote characters ('""')
     resolve to single double quote characters.

     To be recognised as the beginning of a quoted argument, the opening quote character must be
     preceded by a space character.  A quoted argument extends to the next double quote character
     that is not part of a pair, or to the end of the input line, whichever comes earlier.  Leav-
     ing out the terminating double quote character at the end of the line is discouraged.  For
     clarity, if more arguments follow on the same input line, it is recommended to follow the
     terminating double quote character by a space character; in case the next character after
     the terminating double quote character is anything else, it is regarded as the beginning of
     the next, unquoted argument.

     Both in quoted and unquoted arguments, pairs of backslashes ('\\') resolve to single back-
     slashes.  In unquoted arguments, space characters can alternatively be included by preceding
     them with a backslash ('\ '), but quoting is usually better for clarity.

	   .Fn strlen "const char *s"
		   Group arguments "const char *s" into one function argument.	If unspecified,
		   "const", "char", and "*s" would be considered separate arguments.
	   .Op "Fl a"
		   Consider "Fl a" as literal text instead of a flag macro.

     The mandoc(1) roff parser recognises the following requests.  Note that the roff language
     defines many more requests not implemented in mandoc(1).

     Set line adjustment mode.	This line-scoped request is intended to have one argument to
     select normal, left, right, or centre adjustment for subsequent text.  Currently, it is
     ignored including its arguments, and the number of arguments is not checked.

     Append to a macro definition.  The syntax of this request is the same as that of de.  It is
     currently ignored by mandoc(1), as are its children.

     Append to a macro definition, specifying the macro name indirectly.  The syntax of this
     request is the same as that of dei.  It is currently ignored by mandoc(1), as are its chil-

     Append to a macro definition, switching roff compatibility mode off during macro execution.
     The syntax of this request is the same as that of de1.  It is currently ignored by
     mandoc(1), as are its children.

     Define a roff macro.  Its syntax can be either

	   .de name
	   macro definition


	   .de name end
	   macro definition

     Both forms define or redefine the macro name to represent the macro definition, which may
     consist of one or more input lines, including the newline characters terminating each line,
     optionally containing calls to roff requests, roff macros or high-level macros like man(7)
     or mdoc(7) macros, whichever applies to the document in question.

     Specifying a custom end macro works in the same way as for ig; namely, the call to '.end'
     first ends the macro definition, and after that, it is also evaluated as a roff request or
     roff macro, but not as a high-level macro.

     The macro can be invoked later using the syntax

	   .name [argument [argument ...]]

     Regarding argument parsing, see MACRO SYNTAX above.

     The line invoking the macro will be replaced in the input stream by the macro definition,
     replacing all occurrences of \\$N, where N is a digit, by the Nth argument.  For example,

	   .de ZN
	   .ZN XtFree .



     in the input stream, and thus in the output: XtFree.

     Since macros and user-defined strings share a common string table, defining a macro name
     clobbers the user-defined string name, and the macro definition can also be printed using
     the '\*' string interpolation syntax described below ds, but this is rarely useful because
     every macro definition contains at least one explicit newline character.

     In order to prevent endless recursion, both groff and mandoc(1) limit the stack depth for
     expanding macros and strings to a large, but finite number.  Do not rely on the exact value
     of this limit.

     Define a roff macro, specifying the macro name indirectly.  The syntax of this request is
     the same as that of de.  It is currently ignored by mandoc(1), as are its children.

     Define a roff macro that will be executed with roff compatibility mode switched off during
     macro execution.  This is a GNU extension not available in traditional roff implementations
     and not even in older versions of groff.  Since mandoc(1) does not implement roff compati-
     bility mode at all, it handles this request as an alias for de.

     Define a user-defined string.  Its syntax is as follows:

	   .ds name ["]string

     The name and string arguments are space-separated.  If the string begins with a double-quote
     character, that character will not be part of the string.	All remaining characters on the
     input line form the string, including whitespace and double-quote characters, even trailing

     The string can be interpolated into subsequent text by using \*[name] for a name of arbi-
     trary length, or \*(NN or \*N if the length of name is two or one characters, respectively.
     Interpolation can be prevented by escaping the leading backslash; that is, an asterisk pre-
     ceded by an even number of backslashes does not trigger string interpolation.

     Since user-defined strings and macros share a common string table, defining a string name
     clobbers the macro name, and the name used for defining a string can also be invoked as a
     macro, in which case the following input line will be appended to the string, forming a new
     input line passed to the roff parser.  For example,

	   .ds badidea .S

     invokes the SH macro when used in a man(7) document.  Such abuse is of course strongly dis-

     The "else" half of an if/else conditional.  Pops a result off the stack of conditional eval-
     uations pushed by ie and uses it as its conditional.  If no stack entries are present (e.g.,
     due to no prior ie calls) then false is assumed.  The syntax of this request is similar to
     if except that the conditional is missing.

     End an equation block.  See EQ.

     Begin an equation block.  See eqn(7) for a description of the equation language.

     Set automatic hyphenation mode.  This line-scoped request is currently ignored.

     The "if" half of an if/else conditional.  The result of the conditional is pushed into a
     stack used by subsequent invocations of el, which may be separated by any intervening input
     (or not exist at all).  Its syntax is equivalent to if.

     Begins a conditional.  Right now, the conditional evaluates to true if and only if it starts
     with the letter n, indicating processing in nroff style as opposed to troff style.  If a
     conditional is false, its children are not processed, but are syntactically interpreted to
     preserve the integrity of the input document.  Thus,

	   .if t .ig

     will discard the '.ig', which may lead to interesting results, but

	   .if t .if t \{\

     will continue to syntactically interpret to the block close of the final conditional.  Sub-
     conditionals, in this case, obviously inherit the truth value of the parent.  This request
     has the following syntax:

	   .if COND \{\

	   .if COND \{ BODY
	   BODY... \}

	   .if COND \{ BODY

	   .if COND \

     COND is a conditional statement.  roff allows for complicated conditionals; mandoc is much
     simpler.  At this time, mandoc supports only 'n', evaluating to true; and 't', 'e', and 'o',
     evaluating to false.  All other invocations are read up to the next end of line or space and
     evaluate as false.

     If the BODY section is begun by an escaped brace '\{', scope continues until a closing-brace
     escape sequence '.\}'.  If the BODY is not enclosed in braces, scope continues until the end
     of the line.  If the COND is followed by a BODY on the same line, whether after a brace or
     not, then requests and macros must begin with a control character.  It is generally more
     intuitive, in this case, to write

	   .if COND \{\

     than having the request or macro follow as

	   .if COND \{ .foo

     The scope of a conditional is always parsed, but only executed if the conditional evaluates
     to true.

     Note that the '\}' is converted into a zero-width escape sequence if not passed as a stand-
     alone macro '.\}'.  For example,

	   .Fl a \} b

     will result in '\}' being considered an argument of the 'Fl' macro.

     Ignore input.  Its syntax can be either

	   ignored text


	   .ig end
	   ignored text

     In the first case, input is ignored until a '..' request is encountered on its own line.  In
     the second case, input is ignored until the specified '.end' macro is encountered.  Do not
     use the escape character '\' anywhere in the definition of end; it would cause very strange

     When the end macro is a roff request or a roff macro, like in

	   .ig if

     the subsequent invocation of if will first terminate the ignored text, then be invoked as
     usual.  Otherwise, it only terminates the ignored text, and arguments following it or the
     '..' request are discarded.

     Declare the need for the specified minimum vertical space before the next trap or the bottom
     of the page.  This line-scoped request is currently ignored.

     Turn off automatic hyphenation mode.  This line-scoped request is currently ignored.

     Remove a request, macro or string.  This request is intended to have one argument, the name
     of the request, macro or string to be undefined.  Currently, it is ignored including its
     arguments, and the number of arguments is not checked.

     Define a register.  A register is an arbitrary string value that defines some sort of state,
     which influences parsing and/or formatting.  Its syntax is as follows:

	   .nr name value

     The value may, at the moment, only be an integer.	So far, only the following register name
     is recognised:

     nS      If set to a positive integer value, certain mdoc(7) macros will behave in the same
	     way as in the SYNOPSIS section.  If set to 0, these macros will behave in the same
	     way as outside the SYNOPSIS section, even when called within the SYNOPSIS section
	     itself.  Note that starting a new mdoc(7) section with the Sh macro will reset this

     Turn on no-space mode.  This line-scoped request is intended to take no arguments.  Cur-
     rently, it is ignored including its arguments, and the number of arguments is not checked.

     Change point size.  This line-scoped request is intended to take one numerical argument.
     Currently, it is ignored including its arguments, and the number of arguments is not

     Include a source file.  Its syntax is as follows:

	   .so file

     The file will be read and its contents processed as input in place of the '.so' request
     line.  To avoid inadvertent inclusion of unrelated files, mandoc(1) only accepts relative
     paths not containing the strings "../" and "/..".

     This request requires man(1) to change to the right directory before calling mandoc(1), per
     convention to the root of the manual tree.  Typical usage looks like:

	   .so man3/Xcursor.3

     As the whole concept is rather fragile, the use of so is discouraged.  Use ln(1) instead.

     Set tab stops.  This line-scoped request can take an arbitrary number of arguments.  Cur-
     rently, it is ignored including its arguments.

     Output character translation.  Its syntax is as follows:

	   .tr [ab]+

     Pairs of ab characters are replaced (a for b).  Replacement (or origin) characters may also
     be character escapes; thus,

	   tr \(xx\(yy

     replaces all invocations of \(xx with \(yy.

     Re-start a table layout, retaining the options of the prior table invocation.  See TS.

     End a table context.  See TS.

     Begin a table, which formats input in aligned rows and columns.  See tbl(7) for a descrip-
     tion of the tbl language.

     This section documents compatibility between mandoc and other other roff implementations, at
     this time limited to GNU troff ("groff").	The term "historic groff" refers to groff version

     -	 In mandoc, the EQ, TE, TS, and T&, macros are considered regular macros.  In all other
	 roff implementations, these are special macros that must be specified without spacing
	 between the control character (which must be a period) and the macro name.
     -	 The nS register is only compatible with OpenBSD's groff-1.15.
     -	 Historic groff did not accept white-space before a custom end macro for the ig request.
     -	 The if and family would print funny white-spaces with historic groff when using the
	 next-line syntax.

     mandoc(1), eqn(7), man(7), mandoc_char(7), mdoc(7), tbl(7)

     Joseph F. Ossanna and Brian W. Kernighan, Troff User's Manual, AT&T Bell Laboratories,
     Computing Science Technical Report, 54, http://www.kohala.com/start/troff/cstr54.ps, 1976
     and 1992.

     Joseph F. Ossanna, Brian W. Kernighan, and Gunnar Ritter, Heirloom Documentation Tools
     Nroff/Troff User's Manual, http://heirloom.sourceforge.net/doctools/troff.pdf, September 17,

     The RUNOFF typesetting system, whose input forms the basis for roff, was written in MAD and
     FAP for the CTSS operating system by Jerome E.  Saltzer in 1964.  Doug McIlroy rewrote it in
     BCPL in 1969, renaming it roff.  Dennis M. Ritchie rewrote McIlroy's roff in PDP-11 assembly
     for Version 1 AT&T UNIX, Joseph F. Ossanna improved roff and renamed it nroff for Version 2
     AT&T UNIX, then ported nroff to C as troff, which Brian W. Kernighan released with Version 7
     AT&T UNIX.  In 1989, James Clarke re-implemented troff in C++, naming it groff.

     This roff reference was written by Kristaps Dzonsons, kristaps@bsd.lv; and Ingo Schwarze,

BSD					December 11, 2011				      BSD

All times are GMT -4. The time now is 03:09 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password

Not a Forum Member?
Forgot Password?