mandoc_char − mandoc special characters
The rendering depends on the mandoc(1) output mode; it can be inspected by calling man(1) on the mandoc_char manual page with different −T arguments. In ASCII output, the rendering of some characters may be hard to interpret for the reader. Many are rendered as descriptive strings like "<integral>", "<degree>", or "<Gamma>", which may look ugly, and many are replaced by similar ASCII characters. In particular, accented characters are usually shown without the accent. For that reason, try to avoid using any of the special characters documented here except those discussed in the DESCRIPTION, unless they are essential for explaining the subject matter at hand, for example when documenting complicated mathematical functions.
In particular, in English manual pages, do not use special-character escape sequences to represent national language characters in author names; instead, provide ASCII transcriptions of the names.
In typography there are different types of dashes of various width: the hyphen (-), the en-dash (–), the em-dash (—), and the mathematical minus sign (−).
Hyphens are used for adjectives; to separate the two parts of a compound word; or to separate a word across two successive lines of text. The hyphen does not need to be escaped:
The en-dash is used to separate the two elements of a range, or can be used the same way as an em-dash. It should be written as ’\(en’:
Go away \(en or else!
The em-dash can be used to show an interruption or can be used the same way as colons, semi-colons, or parentheses. It should be written as ’\(em’:
\(em apples, oranges, and bananas.
This is not that \(em rather, this is that.
In roff(7) documents, the minus sign is normally written as ’\-’. In manual pages, some style guides recommend to also use ’\-’ if an ASCII 0x2d “hyphen-minus” output glyph that can be copied and pasted is desired in output modes supporting it, for example in −T utf8 and −T html. But currently, no practically relevant manual page formatter actually requires that subtlety, so in manual pages just write plain ’-’ to represent hyphen, minus, and hyphen-minus.
If a word on a text input line contains a hyphen, a formatter may decide to insert an output line break after the hyphen if that helps filling the current output line, but the whole word would overflow the line. If it is important that the word is not broken across lines in this way, a zero-width space (’\&’) can be inserted before or after the hyphen. While mandoc(1) never breaks the output line after hyphens adjacent to a zero-width space, after any of the other dash- or hyphen-like characters represented by escape sequences, or after hyphens inside words in macro arguments, other software may not respect these rules and may break the line even in such cases.
Some roff(7) implementations contains dictionaries allowing to break the line at syllable boundaries even inside words that contain no hyphens. Such automatic hyphenation is not supported by mandoc(1), which only breaks the line at whitespace, and inside words only after existing hyphens.
To separate words in normal text, for indenting and alignment in literal context, and when none of the following special cases apply, just use the normal space character (’ ’).
When filling text, output lines may be broken between words, i.e. at space characters. To prevent a line break between two particular words, use the unpaddable non-breaking space escape sequence (’\ ’) instead of the normal space character. For example, the input string “number\ 1” will be kept together as “number 1” on the same output line.
On request and macro lines, the normal space character serves as an argument delimiter. To include whitespace into arguments, quoting is usually the best choice; see the MACRO SYNTAX section in roff(7). In some cases, using the non-breaking space escape sequence (’\ ’) may be preferable.
To escape macro names and to protect whitespace at the end of input lines, the zero-width space (’\&’) is often useful. For example, in mdoc(7), a normal space character can be displayed in single quotes in either of the following ways:
.Sq \ \&
On request and macro lines, the double-quote character (’"’) is handled specially to allow quoting. One way to prevent this special handling is by using the ’\(dq’ escape sequence.
Note that on text lines, literal double-quote characters can be used verbatim. All other quote-like characters can be used verbatim as well, even on request and macro lines.
In output modes supporting such special output characters, for example −T pdf, and sometimes less consistently in −T utf8, some roff(7) formatters convert the following ASCII input characters to the following Unicode special output characters:
In prose, this automatic substitution is often desirable; but when these characters have to be displayed as plain ASCII characters, for example in source code samples, they require escaping to render as follows:
The period (’.’) is handled specially at the beginning of an input line, where it introduces a roff(7) request or a macro, and when appearing alone as a macro argument in mdoc(7). In such situations, prepend a zero-width space (’\&.’) to make it behave like normal text.
Do not use the ’\.’ escape sequence. It does not prevent special handling of the period.
To include a literal backslash (’\’) into the output, use the (’\e’) escape sequence.
Note that doubling it (’\\’) is not the right way to output a backslash. Because mandoc(1) does not implement full roff(7) functionality, it may work with mandoc(1), but it may have weird effects on complete roff(7) implementations.
Special characters are encoded as ’\X’ (for a one-character escape), ’\(XX’ (two-character), and ’\[N]’ (N-character). For details, see the Special Characters subsection of the roff(7) manual.
Predefined strings are inherited from the macro packages of historical troff implementations. They are not recommended for use, as they differ across implementations. Manuals using these predefined strings are almost certainly not portable.
Their syntax is similar to special characters, using ’\*X’ (for a one-character escape), ’\*(XX’ (two-character), and ’\*[N]’ (N-character). For details, see the Predefined Strings subsection of the roff(7) manual.
The escape sequences
\[uXXXX] and \C'uXXXX'
are interpreted as Unicode codepoints. The codepoint must be in the range above U+0080 and less than U+10FFFF. For compatibility, the hexadecimal digits ’A’ to ’F’ must be given as uppercase characters, and points must be zero-padded to four characters; if greater than four characters, no zero padding is allowed. Unicode surrogates are not allowed.
For backward compatibility with existing manuals, mandoc(1) also supports the
escape sequence, inserting the character number from the current character set into the output. Of course, this is inherently non-portable and is already marked as deprecated in the Heirloom roff manual. For example, do not use \N'34', use \(dq, or even the plain ’"’ character where possible.
This section documents compatibility between mandoc and other troff implementations, at this time limited to GNU troff ("groff").
The \N'' escape sequence is limited to printable characters; in groff, it accepts arbitrary character numbers.
In −Tascii, the \(ss, \(nm, \(nb, \(nc, \(ib, \(ip, \(pp, \[sum], \[product], \[coproduct], \(gr, \(-h, and \(a. special characters render differently between mandoc and groff.
In −Thtml, the \(~=, \(nb, and \(nc special characters render differently between mandoc and groff.
The −Tps and −Tpdf modes format like −Tascii instead of rendering glyphs as in groff.
The \[radicalex], \[sqrtex], and \(ru special characters have been omitted from mandoc either because they are poorly documented or they have no known representation.
The mandoc_char manual page was written by Kristaps Dzonsons <kristaps [AT] bsd.lv>.
The predefined string ’\*(Ba’ mimics the behaviour of the ’|’ character in mdoc(7); thus, if you wish to render a vertical bar with no side effects, use the ’\(ba’ escape.