Manpages

Name

groff_char - GNU roff special character and glyph repertoire

Description

The GNU roff typesetting system has a large glyph repertoire suitable for production of varied literary, professional, technical, and mathematical documents. groff works with characters; an output device renders glyphs. groff’s input character set is restricted to that defined by the standards ISO Latin-1 (ISO 8859-1) and CCSID “code page” 1047 (an EBCDIC arrangement of Latin-1). For ease of document maintenance in UTF-8 environments, it is advisable to use only the Unicode basic Latin code points, a subset of all of the foregoing historically referred to as US-ASCII, which has only 94 visible, printable code points. In groff, these are termed ordinary characters. Often, many more are desired in output.

AT&T troff in the 1970s faced a similar problem: the available typesetter’s glyph repertoire differed from that of the computers that controlled it. troff’s solution was a form of escape sequence known as a special character to access several dozen additional glyphs available in the fonts prepared for mounting in the phototypesetter. These glyphs were mapped onto a two-character name space for a degree of mnemonic convenience; for example, the escape sequence \(aa encoded an acute accent and \(sc a section sign.

groff has lifted historical roff limitations on special character name lengths, but recognizes and retains compatibility with the historical names. groff expands the lexicon of glyphs available by name and permits users to define their own special character escape sequences with the char request. Special character names are groff identifiers; see section “Identifiers” in groff(7). Our discussion uses the terms “glyph name” and “special character name” interchangeably; we assume no character translations or redefinitions.

This document lists all of the glyph names predefined by groff’s font description files and presents the systematic notation by which it enables access to arbitrary Unicode code points and construction of composite glyphs. Glyphs listed may be unavailable, or may vary in appearance, depending on the output device and font chosen when the page was formatted. This page was rendered for device html using font R.

A few escape sequences that are not groff special characters also produce glyphs; these exist for syntactical or historical reasons. \', \`, \-, and \_ are translated on input to the special character escape sequences \[aa], \[ga], \[-], and \[ul], respectively. Others include \\, \. (backslash-dot), and \e; see groff(7). A small number of special characters represent glyphs that are not encoded in Unicode; examples include the baseline rule \[ru] and the Bell System logo \[bs].

In groff, you can test output device support for any character (ordinary or special) with the conditional expression operator “c”.

.ie c \[bs] \{Welcome to the \[bs] Bell System;
did you get the Wehrmacht helmet or the Death Star?\}
.el No Bell System logo.

For brevity in the remainder of this document, we shall refer to systems conforming to the ISO 646:1991 IRV, ISO 8859, or ISO 10646 (“Unicode”) character encoding standards as “ISO” systems, and those employing IBM code page 1047 as “EBCDIC” systems. That said, EBCDIC systems that support groff are known to also support UTF-8.

While groff accepts eight-bit encoded input, not all such code points are valid as input. On ISO platforms, character codes 0, 11, 13–31, and 128–159 are invalid. (This is all C0 and C1 controls except for SOH through LF [Control+A to Control+J], and FF [Control+L].) On EBCDIC platforms, 0, 8–9, 11, 13–20, 23–31, and 48–63 are invalid. Some of these code points are used by groff for internal purposes, which is one reason it does not support UTF-8 natively.

Fundamental character set
The ordinary characters catalogued above, plus the space, tab, newline, and leader (Control+A), form the fundamental character set for groff input; anything in the language, even over one million code points in Unicode, can be expressed using it. On ISO systems, code points in the range 33–126 comprise a common set of printable glyphs in all of the aforementioned ISO character encoding standards. It is this character set and (with some noteworthy exceptions) the corresponding glyph repertoire for which AT&T troff was implemented. On EBCDIC systems, printable characters are in the range 66–201 and 203–254; those without counterparts in the ISO range 33–126 are discussed in the next subsection.

All of the following characters map to glyphs as you would expect.

The remaining ordinary characters surprise computing professionals and others intimately familiar with the ISO character encodings. The developers of AT&T troff chose mappings for them that would be useful for typesetting technical literature in a broad range of scientific disciplines: Bell Labs used the system for preparation of AT&T’s patent filings with the U.S. government. Further, the prevailing character encoding standard in the 1970s, USAS X3.4-1968 (“ASCII”), deliberately supported semantic ambiguity at some code points, and outright substitution at several others, to suit the localization demands of various national standards bodies.

The table below presents the seven exceptional code points with their typical keycap engravings, their glyph mappings and semantics in roff systems, and the escape sequences producing the Unicode basic Latin character they replace. The first, the neutral double quote, is a partial exception because it does represent itself, but since the roff language also uses it to quote macro arguments, groff supports a special character escape sequence as an alternative form so that the glyph can be easily included in macro arguments without requiring the user to master the quoting rules that AT&T troff required in that context. (Some requests, like ds, also treat " non-literally.) Furthermore, not all of the special character escape sequences are portable to AT&T troff and all of its descendants; these groff extensions are presented using its special character form \[], whereas portable special character escape sequences are shown in the traditional \( form. \- and \e are portable to all known troffs. \e means “the glyph of the current escape character”; it therefore can produce unexpected output if the ec request is used. On devices with a limited glyph repertoire, glyphs in the “keycap” and “appearance” columns on the same row of the table may look identical; except for the neutral double quote, this will not be the case on more-capable devices. Review your document using as many different output devices as possible.

The hyphen-minus is a particularly unfortunate case of overloading. Its awkward name in ISO 8859 and later standards reflects the many distinguishable purposes to which it had already been put by the 1980s, including a hyphen, a minus sign, and (alone or in repetition) dashes of varying widths. For best results in roff systems, use the “-” character in input outside an escape sequence only to mean a hyphen, as in the phrase “long-term”. For a minus sign in running text or a Unix command-line option dash, use \- (or \[-] in groff if you find it helps the clarity of the source document). (Another minus sign, for use in mathematical equations, is available as \[mi]). AT&T troff supported em-dashes as \(em, as does groff.

The special character escape sequence for the apostrophe as a neutral single quote is typically needed only in technical content; typing words like “can’t” and “Anne’s” in a natural way will render correctly, because in ordinary prose an apostrophe is typeset either as a closing single quotation mark or as a neutral single quote, depending on the capabilities of the output device. By contrast, special character escape sequences should be used for quotation marks unless portability to limited or historical troff implementations is necessary; on those systems, the input convention is to pair the grave accent with the apostrophe for single quotes, and to double both characters for double quotes. AT&T troff defined no special characters for quotation marks or the apostrophe. Repeated single quotes (’’thus’’) will be visually distinguishable from double quotes (“thus”) on terminal devices, and perhaps on others (depending on the font selected).

If you frequently require quotation marks in your document, see if the macro package you’re using supplies strings or macros to facilitate quotation, or define them yourself (except in man pages).

Using Unicode basic Latin characters to compose boxes and lines is ill-advised. roff systems have special characters for drawing horizontal and vertical lines; see subsection “Rules and lines” below. Preprocessors like tbl(1) and pic(1) draw boxes and will produce the best possible output for the device, falling back to basic Latin glyphs only when necessary.

Eight-bit encodings and Latin-1 supplement
ISO 646 is a seven-bit code encoding 128 code points; eight-bit codes are twice the size. ISO 8859-1 and code page 1047 allocated the additional space to what Unicode calls “C1 controls” (control characters) and the “Latin-1 supplement”. The C1 controls are neither printable nor usable as groff input.

Two Latin-1 supplement characters are handled specially on input. troff never produces them as output.

The remaining characters in the Latin-1 supplement represent themselves. Although they can be specified directly with the keyboard on systems configured to use Latin-1 as the character encoding, it is more portable, both to other roff systems and to UTF-8 environments, to use their special character escape sequences, shown below. The glyph descriptions we use are non-standard in some cases, for brevity.

Special character escape forms
Glyphs that lack a character code in the basic Latin repertoire to directly represent them are entered by one of several special character escape forms. Such glyphs can be simple or composite, and accessed either by name or numerically by code point. Code points and combining properties are determined by character encoding standards, whereas glyph names as used here originated in AT&T troff special character escape sequences. Predefined glyph names use only characters in the basic Latin repertoire.

\C'glyph-name'

is a special character escape sequence for glyph-name, which can be of arbitrary length. The delimiter, shown here as a neutral apostrophe, can be any character not occurring in glyph-name. This syntax form was introduced in later versions of AT&T device-independent troff. The foregoing acute accent example can be expressed as \C'aa'.

\[glyph-name]

is a special character escape sequence for glyph-name, which can be of arbitrary length but must not contain a closing square bracket “]”. (No glyph names predefined by groff employ “]”.) The foregoing acute accent example can be expressed in groff as \[aa].

\C'c' and \[c] are not synonyms for the ordinary character “c”, but request the special character named “\c”. For example, “\[a]” is not “a”, but rather a special character with the internal glyph name (used in font description files and diagnostic messages) \a, which is typically undefined. The only such glyph name groff predefines is the minus sign, which can therefore be accessed as \C'-' or \[-].
\[base-char composite-1 composite-2 ... composite-n]

is a composite glyph. Glyphs like a lowercase “e” with an acute accent, as in the word “café”, can be expressed as \[e aa]. See subsection “Accents” below for a table of combining glyph names.

Unicode encodes far more characters than groff has glyph names for; special character escape forms based on numerical code points enable access to any of them. Frequently used glyphs or glyph combinations can be stored in strings, and new glyph names can be created ad hoc with the char request; see groff(7).
\[unnnn[n[n]]]

is a Unicode numeric special character escape sequence. Any Unicode code point can be accessed with four to six hexadecimal digits, with hexadecimal letters accepted in uppercase form only. Thus, \[u02DA] accesses the (spacing) ring accent, producing “˚”.

Unicode code points can be composed as well; when they are, GNU troff requires NFD (Normalization Form D), where all Unicode glyphs are maximally decomposed. (Exception: precomposed characters in the Latin-1 supplement described above are also accepted. Do not count on this exception remaining in a future GNU troff that accepts UTF-8 input directly.) Thus, GNU troff accepts “caf\['e]”, “caf\[e aa]”, and “caf\[u0065_0301]”, as ways to input “café”. (Due to its legacy 8-bit encoding compatibility, at present it also accepts “caf\[u00E9]” on ISO Latin-1 systems.)
\[ubase-char[_combining-component]...]

constructs a composite glyph from Unicode numeric special character escape sequences. The code points of the base glyph and the combining components are each expressed in hexadecimal, with an underscore (_) separating each component. Thus, \[u006E_0303] produces “ñ”.

\[charnnn]

expresses an eight-bit code point where nnn is the code point of the character, a decimal number between 0 and 255 without leading zeroes. This legacy numeric special character escape sequence is used to map characters onto glyphs via the trin request in macro files loaded by grotty(1).

Glyph tables

In this section, groff’s glyph name repertoire is presented in tabular form. The meanings of the columns are as follows.

A plus sign “+” indicates that the glyph name appears in the AT&T troff user’s manual, CSTR #54 (1992 revision). When using the AT&T special character syntax \(xx, widespread portability can be expected from such names.

Entries marked with “***” denote glyphs used for mathematical purposes. On typesetting devices, such glyphs are typically drawn from a special font (see groff_font(5)). Often, such glyphs lack bold or italic style forms or have metrics that look incongruous in ordinary prose. A few which are not uncommon in running text have “text variants”, which should work better in that context. Conversely, a handful of glyphs that are normally drawn from a text font may be required in mathematical equations. Both sets of exceptions are noted in the tables where they appear (“Logical symbols” and “Mathematical symbols”).

Basic Latin
Apart from basic Latin characters with special mappings, described in subsection “Fundamental character set” above, a few others in that range have special character glyph names. These were defined for ease of input on non-U.S. keyboards lacking keycaps for them, or for symmetry with other special character glyph names serving a similar purpose.

The vertical bar is overloaded; the \[ba] and \[or] escape sequences may render differently. See subsection “Mathematical symbols” below for special variants of the plus, minus, and equals signs normally drawn from this range.

Supplementary Latin letters
Historically, \[ss] could be considered a ligature of “sz”. An uppercase form is available as \[u1E9E], but in the German language it is of specialized use; ß does not normally uppercase-transform to it, but rather to “SS”. “Lowercase f with hook” is also used as a function symbol; see subsection “Mathematical symbols” below.

Ligatures and digraphs

Accents
Normally, the formatting of a special character advances the drawing position as an ordinary character does. groff’s composite request designates a special character as combining. The composite.tmac macro file, loaded automatically by the default troffrc, maps the following special characters to the combining characters shown below. The non-combining code point in parentheses is used when the special character occurs in isolation (compare “caf\[e aa]” and “caf\[aa]e”).

Accented characters
All of these glyphs can be composed using combining glyph names as described in subsection “Special character escape forms” above; the names below are short aliases for convenience.

Quotation marks
The neutral double quote, often useful when documenting programming languages, is also available as a special character for convenient embedding in macro arguments; see subsection “Fundamental character set” above.

Punctuation
The Unicode name for U+00B7 is “middle dot”, which is unfortunately confusable with the groff mnemonic for the visually similar but semantically distinct multiplication dot; see subsection “Mathematical symbols” below.

Brackets
On typesetting devices, the bracket extensions are font-invariant glyphs; that is, they are rendered the same way regardless of font (with a drawing escape sequence). On terminals, they are not font-invariant; groff maps them rather arbitrarily to U+23AA (“curly bracket extension”). In AT&T troff, only one glyph was available to vertically extend brackets, braces, and parentheses: \(bv.

Not all devices supply bracket pieces that can be piled up with \b due to the restrictions of the escape’s piling algorithm. A general solution to build brackets out of pieces is the following macro:

.\" Make a pile centered vertically 0.5em above the baseline.
.\" The first argument is placed at the top.
.\" The pile is returned in string 'pile'.
.eo
.de pile-make
. nr pile-wd 0
. nr pile-ht 0
. ds pile-args
.
. nr pile-# \n[.$]
. while \n[pile-#] \{\
. nr pile-wd (\n[pile-wd] >? \w'\$[\n[pile-#]]')
. nr pile-ht +(\n[rst] - \n[rsb])
. as pile-args \v'\n[rsb]u'\"
. as pile-args \Z'\$[\n[pile-#]]'\"
. as pile-args \v'-\n[rst]u'\"
. nr pile-# -1
. \}
.
. ds pile \v'(-0.5m + (\n[pile-ht]u / 2u))'\"
. as pile \*[pile-args]\"
. as pile \v'((\n[pile-ht]u / 2u) + 0.5m)'\"
. as pile \h'\n[pile-wd]u'\"
..
.ec

Another complication is the fact that some glyphs which represent bracket pieces in AT&T troff can be used for other mathematical symbols as well, for example \(lf and \(rf, which provide the floor operator. Some output devices, such as dvi, don’t unify such glyphs. For this reason, the glyphs \[lf], \[rf], \[lc], and \[rc] are not unified with similar-looking bracket pieces. In groff, only glyphs with long names are guaranteed to pile up correctly for all devices—provided those glyphs are available.

Arrows

Rules and lines
On typesetting devices, the font-invariant glyphs (see subsection “Brackets” above) \[br], \[ul], and \[rn] form corners when adjacent; they can be used to build boxes. On terminal devices, they are mapped as shown in the table. The Unicode-derived names of these three glyphs are approximations.

The input character _ always accesses the underscore glyph in a font; \[ul], by contrast, may be font-invariant on typesetting devices.

The baseline rule \[ru] is a font-invariant glyph, namely a rule of one-half em.

In AT&T troff, \[rn] also served as a one en extension of the square root symbol. groff favors \[radicalex] for this purpose; see subsection “Mathematical symbols” below.

Text markers

Legal symbols
The Bell System logo is not supported in groff.

Currency symbols

Units

Logical symbols
The variants of the not sign may differ in appearance or spacing depending on the device and font selected. Unicode does not encode a discrete “bitwise or” sign: on typesetting devices, it is drawn shorter than the bar, about the same height as a capital letter. Terminal devices unify \[ba] and \[or].

Mathematical symbols
\[Fn] also appears in subsection “Supplementary Latin letters” above. Observe the two varieties of the plus-minus, multiplication, and division signs; \[+-], \[mu], and \[di] are normally drawn from the special font, but have text font variants. Also be aware of three glyphs available in special font variants that are normally drawn from text fonts: the plus, minus, and equals signs. These variants may differ in appearance or spacing depending on the device and font selected.

In AT&T troff, \(rn (“root en extender”) served as the horizontal extension of the radical (square root) sign, \(sr, and was drawn at the maximum height of the typeface’s bounding box; this enabled the special character to double as an overline (see subsection “Rules and lines” above). A contemporary font’s radical sign might not ascend to such an extreme. In groff, you can instead use \[radicalex] to continue the radical sign \[sr]; these special characters are intended for use with text fonts. \[sqrt] and \[sqrtex] are their counterparts with mathematical spacing.

Greek glyphs
These glyphs are intended for technical use, not for typesetting Greek language text; normally, the uppercase letters have upright shape, and the lowercase ones are slanted.

Playing card symbols

History

A consideration of the typefaces originally available to AT&T nroff and troff illuminates many conventions that one might regard as idiosyncratic fifty years afterward. (See section “History” of roff(7) for more context.) The face used by the Teletype Model 37 terminals of the Murray Hill Unix Room was based on ASCII, but assigned multiple meanings to several code points, as suggested by that standard. Decimal 34 (") served as a dieresis accent and neutral double quotation mark; decimal 39 (') as an acute accent, apostrophe, and closing (right) single quotation mark; decimal 45 (-) as a hyphen and a minus sign; decimal 94 (^) as a circumflex accent and caret; decimal 96 (`) as a grave accent and opening (left) single quotation mark; and decimal 126 (~) as a tilde accent and (with a half-line motion) swung dash. The Model 37 bore an optional extended character set offering upright Greek letters and several mathematical symbols; these were documented as early as the kbd(VII) man page of the (First Edition) Unix Programmer’s Manual.

At the time Graphic Systems delivered the C/A/T phototypesetter to AT&T, the ASCII character set was not considered a standard basis for a glyph repertoire by traditional typographers. In the stock Times roman, italic, and bold styles available, several ASCII characters were not present at all, nor was most of the Teletype’s extended character set. AT&T commissioned a “special” font to ensure no loss of repertoire.

A representation of the coverage of the C/A/T’s text fonts follows. The glyph resembling an underscore is a baseline rule, and that resembling a vertical line is a box rule. In italics, the box rule was not slanted. We also observe that the hyphen and minus sign were already “de-unified” by the fonts provided; a decision whither to map an input “-” therefore had to be taken.

The special font supplied the missing ASCII and Teletype extended glyphs, among several others. The plus, minus, and equals signs appeared in the special font despite availability in text fonts “to insulate the appearance of equations from the choice of standard [read: text] fonts”—a priority since troff was turned to the task of mathematical typesetting as soon as it was developed.

We note that AT&T took the opportunity to de-unify the apostrophe/right single quotation mark from the acute accent (a choice ISO later duplicated in its 8859 series of standards). A slash intended to be mirror-symmetric with the backslash was also included, as was the Bell System logo; we do not attempt to depict the latter.

 
One ASCII character as rendered by the Model 37 was apparently abandoned. That device printed decimal 124 (|) as a broken vertical line, like Unicode U+00A6 (¦). No equivalent was available on the C/A/T; the box rule \[br], brace vertical extension \[bv], and “or” operator \[or] were used as contextually appropriate.

Devices supported by AT&T device-independent troff exhibited some differences in glyph detail. For example, on the Autologic APS-5 phototypesetter, the square \(sq became filled in the Times bold face.

Files

The files below are loaded automatically by the default troffrc.
/usr/share/groff/1.23.0/tmac/composite.tmac

assigns alternate mappings for identifiers after the first in a composite special character escape sequence. See subsection “Accents” above.

/usr/share/groff/1.23.0/tmac/fallbacks.tmac

defines fallback mappings for Unicode code points such as the increment sign (U+2206) and upper- and lowercase Roman numerals.

Authors

This document was written by jjc [AT] jclark.com">James Clark, with additions by wl [AT] gnu.org">Werner Lemberg and groff-bernd.warken-72 [AT] web.de">Bernd Warken, revised to use tbl(1) by esr [AT] thyrsus.com">Eric S. Raymond, and largely rewritten by g.branden.robinson [AT] gmail.com">G. Branden Robinson.

See also

Groff: The GNU Implementation of troff, by Trent A. Fisher and Werner Lemberg, is the primary groff manual. Section “Using Symbols” may be of particular note. You can browse it interactively with “info '(groff) Using Symbols'”.

“An extension to the troff character set for Europe”, E.G. Keizer, K.J. Simonsen, J. Akkerhuis; EUUG Newsletter, Volume 9, No. 2, Summer 1989
http://www.unicode.org">The Unicode Standard
https://www.aivosto.com/articles/charsets-7bit.html">“7-bit Character Sets” by Tuomas Salste documents the inherent ambiguity and configurable code points of the ASCII encoding standard.

“Nroff/Troff User’s Manual” by Joseph F. Ossanna, 1976, AT&T Bell Laboratories Computing Science Technical Report No. 54, features two tables that throw light on the glyph repertoire available to “typesetter roff” when it was first written. Be careful of re-typeset versions of this document that can be found on the Internet. Some do not accurately represent the original document: several glyphs are obviously missing. More subtly, lowercase Greek letters are rendered upright, not slanted as they appeared in the C/A/T’s special font and as expected by troff users.

groff_rfc1345(7) describes an alternative set of special character glyph names, which extends and in some cases overrides the definitions listed above.

groff(1), troff(1), groff(7)