| www.delorie.com/gnu/docs/groff/groff_fot.html | search |
![]() Buy GNU books! | |
| [Top] | [Contents] | [Index] | [ ? ] |
What You See Is What You Get
The same is true for the other main macro
packages that come with groff: `man', `mdoc',
`ms', `mm', and `mandoc'. This won't work in general;
for example, to load `trace.tmac', either `-mtrace' or
`-m trace' must be used.
This section is derived from Writing Papers with nroff using -me by Eric P. Allman.
If you need finer granularity of the
vertical space, use the pvs request (see section 5.19.1 Changing Type Sizes).
Actually, only the title is required.
For an explanation what special characters are see 7.1 Special Characters.:
*Q is the left quote and *U is the right quote.
Improved accent marks are available in the `ms' macros.
To use the accent marks, place them after the character being accented.
The following accent marks are available
after invoking the AM macro:
The following are standalone characters
available after invoking the AM macro:
This section lists the (minor) differences between the
groff -ms macros and AT&T
troff -ms macros.
4.3.7.1 troffmacros not appearing ingroff4.3.7.2 groffmacros not appearing in AT&Ttroff
troff macros not appearing in groff
Macros missing from groff -ms
are cover page macros specific to Bell Labs.
The macros known to be missing are:
.TM
.IM
.MR
.MF
.EG
.TR
.OK
.CS
.MH
groff macros not appearing in AT&T troff
The groff -ms macros have a few minor extensions
compared to the AT&T troff -ms macros.
troff -ms
was to indent; the groff default prints displays
flush left with the body text.
constant width (Courier) font.
The following additional number registers
appear in groff -ms:
GW register that was documented but apparently
not implemented in AT&T troff.
Several new string registers are available as well. You can change these to handle (for example) the local language. See section 4.3.6.5 Strings and Special Characters, for details.
See the `meintro.me' and `meref.me' documents in groff's `doc' directory.
See the groff_mm(7) man page (type man groff_mm at
the command line).
gtroff Reference
This chapter covers all of the facilities of gtroff.
Users of macro packages may skip it if not interested in details.
gtroff input files contain text with control commands
interspersed throughout. But, even without control codes, gtroff
still does several things with the input text:
5.1.1 Filling and Adjusting 5.1.2 Hyphenation 5.1.3 Sentences 5.1.4 Tab Stops 5.1.5 Implicit Line Breaks
When gtroff reads text, it collects words from the input and fits
as many of them together on one output line as it can. This is known as
filling.
Once gtroff has a filled line, it tries to adjust
it. This means it widens the spacing between words until the text
reaches the right margin (in the default adjustment mode). Extra spaces
between words are preserved, but spaces at the end of lines are ignored.
Spaces at the front of a line cause a break (breaks are
explained in 5.1.5 Implicit Line Breaks).
See section 5.8 Manipulating Filling and Adjusting.
Since the odds are not great for finding a set of words, for every
output line, which fit nicely on a line without inserting excessive
amounts of space between words, gtroff hyphenates words so
that it can justify lines without inserting too much space between
words. It uses an internal hyphenation algorithm (a simplified version
of the algorithm used within TeX) to indicate which words can be
hyphenated and how to do so. When a word is hyphenated, the first part
of the word is added to the current filled line being output (with
an attached hyphen), and the other portion is added to the next
line to be filled.
See section 5.9 Manipulating Hyphenation.
Although it is often debated, some typesetting rules say there should be different amounts of space after various punctuation marks. For example, the Chicago typsetting manual says that a period at the end of a sentence should have twice as much space following it as would a comma or a period as part of an abbreviation.
gtroff does this by flagging certain characters (normally
`!', `?', and `.') as end-of-sentence characters.
When gtroff encounters one of these characters at the end of a
line, it appends a normal space followed by a sentence space in
the formatted output. (This justifies one of the conventions mentioned
in 5.2 Input Conventions.)
In addition, the following characters and symbols are treated
transparently while handling end-of-sentence characters: `"',
`'', `)', `]', `*', \[dg], and \[rq].
See the cflags request in 5.18.4 Using Symbols, for more details.
To prevent the insertion of extra space after an end-of-sentence
character (at the end of a line), append \&.
gtroff translates tabulator characters, also called
tabs (normally code point ASCII 0x09 or
EBCDIC 0x05), in the input into movements to the next
tabulator stop. These tab stops are initially located every half inch
across the page. Using this, simple tables can be made easily.
However, it can often be deceptive as the appearance (and width) of the
text on a terminal and the results from gtroff can vary greatly.
Also, a possible sticking point is that lines beginning with tab characters are still filled, again producing unexpected results. For example, the following input
| 1 | 2 | 3 | |
| 4 | 5 |
produces
| 1 | 2 | 3 | 4 | 5 |
See section 5.11 Tabs and Fields.
An important concept in gtroff is the break. When a break
occurs, gtroff outputs the partially filled line
(unjustified), and resumes collecting and filling text on the next output
line.
There are several ways to cause a break in gtroff. A blank
line not only causes a break, but it also outputs a one-line vertical
space (effectively a blank line). Note that this behaviour can be
modified with the blank line macro request blm.
See section 5.25.4 Blank Line Traps.
A line that begins with a space causes a break and the space is output at the beginning of the next line. Note that this space isn't adjusted, even in fill mode.
The end of file also causes a break -- otherwise the last line of the document may vanish!
Certain requests also cause breaks, implicitly or explicitly. This is discussed in 5.8 Manipulating Filling and Adjusting.
Since gtroff does filling automatically, it is traditional in
groff not to try and type things in as nicely formatted
paragraphs. These are some conventions commonly used when typing
gtroff text:
gtroff (like many other programs) requires numeric parameters to
specify various measurements. Most numeric parameters@footnotegroff_82.html{those
that specify vertical or horizontal motion or a type size may have a
measurement unit attached. These units are specified as a single
character which immediately follows the number or expression. Each of
these units are understood, by gtroff, to be a multiple of its
basic unit. So, whenever a different measurement unit is
specified gtroff converts this into its basic units. This
basic unit, represented by a `u', is a device dependent measurement
which is quite small, ranging from 1/75th to 1/72000th of an
inch. The values may be given as fractional numbers; however,
fractional basic units are always rounded to integers.
Some of the measurement units are completely independent of any of the
current settings (e.g. type size) of gtroff.
i
c
p
P
s
z
f
The other measurements understood by gtroff depend on
settings currently in effect in gtroff. These are very useful
for specifying measurements which should look proper with any size of
text.
m
n
groff, this is half of an em.
v
M
5.3.1 Default Units
Many requests take a default unit. While this can be helpful at times, it can cause strange errors in some expressions. For example, the line length request expects em units. Here are several attempts to get a line length of 3.5 inches and their results:
3.5i => 3.5i 7/2 => 0i 7/2i => 0i (7 / 2)u => 0i 7i/2 => 0.1i 7i/2u => 3.5i |
Everything is converted to basic units first. In the above example it is assumed that 1i equals 240u, and 1m equals 10p (thus 1m equals 33u). The value 7i/2 is first handled as 7i/2m, then converted to 1680u/66u which is 25u, and this is approximately 0.1i. As can be seen, a scaling indicator after a closing parenthesis is simply ignored.
Thus, the safest way to specify measurements is to always attach a scaling indicator. If you want to multiply or divide by a certain scalar value, use `u' as the unit for that value.
gtroff has most arithmetic operators common to other languages:
gtroff only provides integer arithmetic. The internal type used
for computing results is `int', which is usually a 32bit
signed integer.
if and while requests). See
below for the use of unary operators in motion requests.
Example:
.nr x 5 .nr y 3 .nr z (\n[x] >? \n[y]) |
The register z now contains 5.
(c;e). Evaluate e using c
as the default scaling indicator. If c is missing, ignore scaling
indicators in the evaluation of e.
Parentheses may be used as in any other language. However, in
gtroff they are necessary to ensure order of evaluation.
gtroff has no operator precedence; expressions are evaluated left
to right. This means that gtroff evaluates `3+5*4' as if it were
parenthesized like `(3+5)*4', not as `3+(5*4)', as might be
expected.
For many requests which cause a motion on the page, the unary operators `+' and `-' work differently if leading an expression. They then indicate a motion relative to the current position (down or up, respectively).
Similarly, a leading `|' operator indicates an absolute position. For vertical movements, it specifies the distance from the top of the page; for horizontal movements, it gives the distance from the beginning of the input line.
`+' and `-' are also treated differently by the following
requests and escapes: bp, in, ll, lt,
nm, nr, pl, pn, po, ps,
pvs, rt, ti, \H, \R, and \s.
Here, leading plus and minus signs indicate increments and decrements.
See section 5.7.1 Setting Registers, for some examples.
Due to the way arguments are parsed, spaces are not allowed in expressions, unless the entire expression is surrounded by parentheses.
See section 5.6.1.1 Request Arguments, and 5.21 Conditionals and Loops.
Like any other language, gtroff has rules for properly formed
identifiers. In gtroff, an identifier can be made up of
almost any printable character, with the exception of the following
characters:
0x08 or EBCDIC
0x16) and character code 0x01.
groff runs on a machine based on ASCII, causing a
warning message of type `input' (see 5.34 Debugging, for more
details): 0x00, 0x0B, 0x0D-0x1F,
0x80-0x9F.
And here are the invalid input characters if groff runs on an
EBCDIC host: 0x00, 0x08, 0x09,
0x0B, 0x0D-0x14, 0x17-0x1F,
0x30-0x3F.
Currently, some of these reserved codepoints are used internally, thus
making it non-trivial to extend gtroff to cover Unicode or other
character sets and encodings which use characters of these ranges.
Note that invalid characters are removed before parsing; an
identifier foo, followed by an invalid character, followed by
bar is treated as foobar.
For example, any of the following is valid.
br PP (l end-list @_ |
Note that identifiers longer than two characters with a closing bracket (`]') in its name can't be accessed with escape sequences which expect an identifier as a parameter. For example, `\[foo]]' accesses the glyph `foo', followed by `]', whereas `\C'foo]'' really asks for glyph `foo]'.
To avoid problems with the refer preprocessor, macro names
should not start with `[' or `]'. Due to backwards
compatibility, everything after `.[' and `.]' is handled as
a special argument to refer. For example, `.[foo' makes
refer to start a reference, using `foo' as a parameter.
gtroff. It
expands to the character 1 or 0 according to whether its
argument (usually delimited by quotes) is or is not acceptable as the
name of a string, macro, diversion, number register, environment, or
font. It returns 0 if no argument is given. This is useful for
looking up user input in some sort of associative table.
\A'end-list'
=> 1
|
See section 5.6.3 Escapes, for details on parameter delimiting characters.
Identifiers in gtroff can be any length, but, in some contexts,
gtroff needs to be told where identifiers end and text begins
(and in different ways depending on their length):
gtroff only). Must be bracketed with `['
and `]' in some situations. Any length identifier can be put
in brackets.
Unlike many other programming languages, undefined identifiers are
silently ignored or expanded to nothing.
When gtroff finds an undefined identifier, it emits a
warning, doing the following:
gtroff defines it as empty.
gtroff
defines it with a value of 0.
See section 5.34.1 Warnings., 5.7.2 Interpolating Registers, and 5.20 Strings.
Note that macros, strings, and diversions share the same name space.
.de xxx
. nop foo
..
.
.di xxx
bar
.br
.di
.
.xxx
=> bar
|
As can be seen in the previous example, gtroff reuses the
identifier `xxx', changing it from a macro to a diversion.
No warning is emitted! The contents of the first macro definition is
lost.
See section 5.7.2 Interpolating Registers, and 5.20 Strings.
Most documents need more functionality beyond filling, adjusting and
implicit line breaking. In order to gain further functionality,
gtroff allows commands to be embedded into the text, in two ways.
The first is a request which takes up an entire line, and does some large-scale operation (e.g. break lines, start new pages).
The other is an escape which can be usually embedded anywhere in the text; most requests can accept it even as an argument. Escapes generally do more minor operations like sub- and superscripts, print a symbol, etc.
5.6.1 Requests 5.6.2 Macros 5.6.3 Escapes
A request line begins with a control character, which is either a single quote (`'', the no-break control character) or a period (`.', the normal control character). These can be changed; see 5.12 Character Translations, for details. After this there may be optional tabs or spaces followed by an identifier which is the name of the request. This may be followed by any number of space-separated arguments (no tabs here).
Since a control character followed by whitespace only is ignored, it is common practice to use this feature for structuring the source code of documents or macro packages.
.de foo . tm This is foo. .. . . .de bar . tm This is bar. .. |
Another possibility is to use the blank line macro request blm
by assigning an empty macro to it.
.de do-nothing .. .blm do-nothing \" activate blank line macro .de foo . tm This is foo. .. .de bar . tm This is bar. .. .blm \" deactivate blank line macro |
See section 5.25.4 Blank Line Traps.
To begin a line with a control character without it being interpreted,
precede it with \&. This represents a zero width space, which
means it does not affect the output.
In most cases the period is used as a control character. Several requests cause a break implicitly; using the single quote control character prevents this.
5.6.1.1 Request Arguments
Arguments to requests (and macros) are processed much like the shell:
The line is split into arguments according to
spaces.@footnotegroff_88.html{Plan 9's troff implementation also allows
tabs for argument separation -- gtroff intentionally doesn't
support this. An argument which is intended to contain spaces can
either be enclosed in double quotes, or have the spaces escaped
with backslashes.
Here are a few examples:
.uh The Mouse Problem .uh "The Mouse Problem" .uh The\ Mouse\ Problem |
The first line is the uh macro being called with 3 arguments,
`The', `Mouse', and `Problem'. The latter two have the
same effect of calling the uh macro with one argument, `The
Mouse Problem.@footnotegroff_88.html{The last solution, i.e., using escaped spaces,
is "classical" in the sense that it can be found in most troff
documents. Nevertheless, it is not optimal in all situations, since
`\ ' inserts a fixed-width, non-breaking space character which
can't stretch. gtroff provides a different command \~ to
insert a stretchable, non-breaking space.
A double quote which isn't preceded by a space doesn't start a macro argument. If not closing a string, it is printed literally.
For example,
.xxx a" "b c" "de"fg" |
has the arguments `a"', `b c', `de', and `fg"'. Don't rely on this obscure behaviour!
There are two possibilities to get a double quote reliably.
groff):
.de xx
. tm xx: `\\$1' `\\$2' `\\$3'
.
. yy "\\$1" "\\$2" "\\$3"
..
.de yy
. tm yy: `\\$1' `\\$2' `\\$3'
..
.xx A "test with ""quotes""" .
=> xx: `A' `test with "quotes"' `.'
=> yy: `A' `test with ' `quotes""'
|
If not in compatibility mode, you get the expected result
xx: `A' `test with "quotes"' `.' yy: `A' `test with "quotes"' `.' |
since gtroff preserves the input level.
\(dq. This works with and without
compatibility mode enabled since gtroff doesn't convert \(dq
back to a double quote input character.
Not that this method won't work with UNIX troff in general
since the glyph `dq' isn't defined normally.
Double quotes in the ds request are handled differently.
See section 5.20 Strings, for more details.
gtroff has a macro facility for defining a series of lines
which can be invoked by name. They are called in the same manner as
requests -- arguments also may be passed in the same manner.
See section 5.22 Writing Macros, and 5.6.1.1 Request Arguments.
Escapes may occur anywhere in the input to gtroff. They usually
begin with a backslash and are followed by a single character which
indicates the function to be performed. The escape character can be
changed; see 5.12 Character Translations.
Escape sequences which require an identifier as a parameter accept three possible syntax forms.
Examples:
\fB \n(XX \*[TeX] |
Other escapes may require several arguments and/or some special format. In such cases the argument is traditionally enclosed in single quotes (and quotes are always used in this manual for the definitions of escape sequences). The enclosed text is then processed according to what that escape expects. Example:
\l'1.5i\(bu' |
Note that the quote character can be replaced with any other character
which does not occur in the argument (even a newline or a space
character) in the following escapes: \o, \b, and
\X. This makes e.g.
A caf \o e\' in Paris => A café in Paris |
possible, but it is better not to use this feature to avoid confusion.
The following escapes sequences (which are handled similarly to
characters since they don't take a parameter) are also allowed as
delimiters: \%, `\ ', \|, \^, \{,
\}, \', \`, \-, \_, \!,
\?, \@, \), \/, \,, \&,
\:, \~, \0, \a, \c, \d,
\e, \E, \p, \r, \t, and \u.
Again, don't use these if possible.
No newline characters as delimiters are allowed in the following
escapes: \A, \B, \Z, \C, and \w.
Finally, the escapes \D, \h, \H, \l,
\L, \N, \R, \s, \S, \v,
and \x can't use the following characters as delimiters:
0-9.
\%, \:, \{, \},
\', \`, \-, \_, \!, \@,
\/, \c, \e, and \p.
To have a backslash (actually, the current escape character) appear in the
output several escapes are defined: \\, \e or \E.
These are very similar, and only differ with respect to being used in
macros or diversions. See section 5.12 Character Translations, for an exact
description of those escapes.
See section 5.35 Implementation Differences, 5.22.1 Copy-in Mode, and 5.26 Diversions, 5.5 Identifiers, for more information.
5.6.3.1 Comments
Probably one of the most@footnotegroff_91.html{Unfortunately, this is a lie. But
hopefully future gtroff hackers will believe it :-)
common forms of escapes is the comment.
This may sound simple, but it can be tricky to keep the comments from interfering with the appearance of the final output.
If the escape is to the right of some text or a request, that portion
of the line is ignored, but the space leading up to it is noticed by
gtroff. This only affects the ds and as
request and its variants.
One possibly irritating idiosyncracy is that tabs must not be used to line up comments. Tabs are not treated as whitespace between the request and macro arguments.
A comment on a line by itself is treated as a blank line, because after eliminating the comment, that is all that remains:
Test \" comment Test |
produces
Test Test |
To avoid this, it is common to start the line with .\" which
causes the line to be treated as an undefined request and thus ignored
completely.
Another commenting scheme seen sometimes is three consecutive single
quotes ("') at the beginning of a line. This works, but
gtroff gives a warning about an undefined macro (namely
"), which is harmless, but irritating.
gtroff has a new comment mechanism using the
\# escape. This escape works the same as \" except that
the newline is also ignored:
Test \# comment Test |
produces
Test Test |
as expected.
gtroff encounters the macro named
.yy on a line by itself (or .. if yy is not
specified). This is useful for commenting out large blocks of text:
text text text... .ig This is part of a large block of text that has been temporarily(?) commented out. We can restore it simply by removing the .ig request and the ".." at the end of the block. .. More text text text... |
produces
text text text... More text text text... |
Note that the commented-out block of text does not cause a break.
The input is read in copy-mode; auto-incremented registers are affected (see section 5.7.3 Auto-increment).
Numeric variables in gtroff are called registers. There
are a number of built-in registers, supplying anything from the date to
details of formatting parameters.
See section 5.5 Identifiers, for details on register identifiers.
5.7.1 Setting Registers 5.7.2 Interpolating Registers 5.7.3 Auto-increment 5.7.4 Assigning Formats 5.7.5 Built-in Registers
Define or set registers using the nr request or the
\R escape.
gtroff creates it.
The argument to \R usually has to be enclosed in quotes.
See section 5.6.3 Escapes, for details on parameter delimiting characters.
The \R escape doesn't produce an input token in gtroff;
with other words, it vanishes completely after gtroff has
processed it.
For example, the following two lines are equivalent:
.nr a (((17 + (3 * 4))) % 4)
\R'a (((17 + (3 * 4))) % 4)'
=> 1
|
Both nr and \R have two additional special forms to
increment or decrement a register.
.nr a 1
.nr a +1
\na
=> 2
|
To assign the negated value of a register to another register, some care must be taken to get the desired result:
.nr a 7
.nr b 3
.nr a -\nb
\na
=> 4
.nr a (-\nb)
\na
=> -3
|
The surrounding parentheses prevent the interpretation of the minus sign as a decrementing operator. An alternative is to start the assignment with a `0':
.nr a 7
.nr b -3
.nr a \nb
\na
=> 4
.nr a 0\nb
\na
=> -3
|
Numeric registers can be accessed via the \n escape.
gtroff is parsing the input line.
Nested assignments (also called indirect assignments) are possible.
.nr a 5
.nr as \na+\na
\n(as
=> 10
|
.nr a1 5
.nr ab 6
.ds str b
.ds num 1
\n[a\n[num]]
=> 5
\n[a\*[str]]
=> 6
|
Number registers can also be auto-incremented and auto-decremented.
The increment or decrement value can be specified with a third
argument to the nr request or \R escape.
\R
escape doesn't support this notation.
To activate auto-incrementing, the escape \n has a special
syntax form.
nr request (or the
\R escape). If no auto-increment value has been specified,
these syntax forms are identical to \n.
For example,
.nr a 0 1 .nr xx 0 5 .nr foo 0 -2 \n+a, \n+a, \n+a, \n+a, \n+a .br \n-(xx, \n-(xx, \n-(xx, \n-(xx, \n-(xx .br \n+[foo], \n+[foo], \n+[foo], \n+[foo], \n+[foo] |
produces
1, 2, 3, 4, 5 -5, -10, -15, -20, -25 -2, -4, -6, -8, -10 |
To change the increment value without changing the value of a register (a in the example), the following can be used:
.nr a \na 10 |
When a register is used in the text of an input file (as opposed to
part of an expression), it is textually replaced (or interpolated)
with a representation of that number. This output format can be
changed to a variety of formats (numbers, Roman numerals, etc.). This
is done using the af request.
1
0...0
In fact, any digit instead of zero will do; gtroff only counts
how many digits are specified. As a consequence, af's default
format `1' could be specified as `0' also (and exactly this is
returned by the \g escape, see below).
I
i
A
a
Omitting the number register format causes a warning of type `missing'. See section 5.34 Debugging, for more details. Specifying a nonexistent format causes an error.
The following example produces `10, X, j, 010':
.nr a 10 .af a 1 \" the default format \na, .af a I \na, .af a a \na, .af a 001 \na |
The largest number representable for the `i' and `I' formats
is 39999 (or -39999); UNIX troff uses `z'
and `w' to represent 10000 and 5000 in Roman numerals, and so does
gtroff. Currently, the correct glyphs of Roman numeral five
thousand and Roman numeral ten thousand (Unicode code points
U+2182 and U+2181, respectively) are not available.
If ident doesn't exist, it is created.
Changing the output format of a read-only register causes an error. It
is necessary to first copy the register's value to a writeable register,
then apply the af request to this other register.
The following lists some built-in registers which are not described elsewhere in this manual. Any register which begins with a `.' is read-only. A complete listing of all built-in registers can be found in appendix E. Register Index.
.F
.H
.V
seconds
gtroff.
minutes
gtroff.
hours
gtroff.
dw
dy
mo
year
yr
troff had a year 2000 bug: It
incorrectly claimed that yr contains the last two digits of the
year. That claim has never been true of either AT&T
troff or GNU troff. Old troff input that looks
like this:
'\" The following line stopped working after 1999 This document was formatted in 19\n(yr. |
can be corrected as follows:
This document was formatted in \n[year]. |
or, to be portable to older troff versions, as follows:
.nr y4 1900+\n(yr This document was formatted in \n(y4. |
.c
c.
gtroff extension) is writable also,
affecting both `.c' and `c.'.
ln
nm
request to activate line numbering.
See section 5.32 Miscellaneous, for more information about line numbering.
.x
.x contains `1'.
.y
.y contains `03'.
.Y
groff.
$$
gtroff.
.g
troff.
.A
.P
.T
gtroff is called with the `-T' command line option, the
number register .T is set to 1, and zero otherwise.
See section 2.1 Options.
Additionally, gtroff predefines a single read-write string
register .T which contains the current output device (for
example, `latin1' or `ps').
Various ways of causing breaks were given in 5.1.5 Implicit Line Breaks. The br request likewise causes a break. Several
other requests also cause breaks, but implicitly. These are
bp, ce, cf, fi, fl, in,
nf, rj, sp, ti, and trf.
If the no-break control character is used, gtroff suppresses
the break:
a
'br
b
=> a b
|
Initially, gtroff fills and adjusts text to both margins.
Filling can be disabled via the nf request and re-enabled with
the fi request.
.u is set to 1.
The fill mode status is associated with the current environment (see section 5.27 Environments).
See 5.15 Line Control, for interaction with the \c escape.
.u is set to 0.
The fill mode status is associated with the current environment (see section 5.27 Environments).
See 5.15 Line Control, for interaction with the \c escape.
Activation and deactivation of adjusting is done implicitly with
calls to the fi or nf requests.
mode can have one of the following values:
l
r
c
ce request which
only centers text without filling.
b
n
gtroff.
With no argument, gtroff adjusts lines in the same way it did
before adjusting was deactivated (with a call to na, for
example).
text .ad r text .ad c text .na text .ad \" back to centering text |
The current adjustment mode is available in the read-only number
register .j; it can be stored and subsequently used to set
adjustment.
The adjustment mode status is associated with the current environment (see section 5.27 Environments).
ad uses the previous adjustment
setting.
The adjustment mode status is associated with the current environment (see section 5.27 Environments).
In most cases this produces very ugly results since gtroff
doesn't have a sophisticated paragraph building algorithm (as TeX
have, for example); instead, gtroff fills and adjusts a paragraph
line by line:
This is an uninteresting sentence. This is an uninteresting sentence.\p This is an uninteresting sentence. |
is formatted as
This is an uninteresting sentence. This is an uninteresting sentence. This is an uninteresting sentence. |
If two arguments are given to the ss request, the second
argument sets the sentence space size. If the second argument is not
given, sentence space size is set to word_space_size. The
sentence space size is used in two circumstances: If the end of a
sentence occurs at the end of a line in fill mode, then both an
inter-word space and a sentence space are added; if two spaces follow
the end of a sentence in the middle of a line, then the second space
is a sentence space. If a second argument is never given to the
ss request, the behaviour of UNIX troff is the
same as that exhibited by GNU troff. In GNU troff, as
in UNIX troff, a sentence should always be followed
by either a newline or two spaces.
The read-only number registers .ss and .sss hold the
values of the parameters set by the first and second arguments of the
ss request.
The word space and sentence space values are associated with the current environment (see section 5.27 Environments).
Contrary to AT&T troff, this request is not
ignored if a TTY output device is used; the given values are then
rounded down to a multiple of 12 (see section 5.35 Implementation Differences).
The request is ignored if there is no parameter.
ce does not fill the
text it affects. This request causes a break. The number of lines
still to be centered is associated with the current environment
(see section 5.27 Environments).
The following example demonstrates the differences. Here the input:
.ll 4i .ce 1000 This is a small text fragment which shows the differences between the `.ce' and the `.ad c' request. .ce 0 .ad c This is a small text fragment which shows the differences between the `.ce' and the `.ad c' request. |
And here the result:
This is a small text fragment which
shows the differences
between the `.ce' and the `.ad c' request.
This is a small text fragment which
shows the differences between the `.ce'
and the `.ad c' request.
|
With no arguments, ce centers the next line of text. nnn
specifies the number of lines to be centered. If the argument is zero
or negative, centering is disabled.
The basic length for centering text is the line length (as set with the
ll request) minus the indentation (as set with the in
request). Temporary indentation is ignored.
As can be seen in the previous example, it is a common idiom to turn on centering for a large number of lines, and to turn off centering after text to be centered. This is useful for any request which takes a number of lines as an argument.
The .ce read-only number register contains the number of lines
remaining to be centered, as set by the ce request.
ce request. The .rj read-only number register is
the number of lines to be right-justified as set by the rj
request. This request causes a break. The number of lines still to be
right-justified is associated with the current environment
(see section 5.27 Environments).
As discussed in 5.1.2 Hyphenation, gtroff hyphenates words.
There are a number of ways to influence hyphenation.
1
gtroff.
2
4
8
Values in the previous table are additive. For example, the value
12 causes gtroff to neither hyphenate the last two nor the first
two characters of a word.
The current hyphenation restrictions can be found in the read-only number register `.hy'.
The hyphenation mode is associated with the current environment (see section 5.27 Environments).
hy is not
remembered.
The hyphenation mode is associated with the current environment (see section 5.27 Environments).
\% are counted;
explicit hyphens are not.
The current setting of hlm is available in the .hlm
read-only number register. Also the number of immediately preceding
consecutive hyphenated lines are available in the read-only number
register `.hlc'.
.hw in-sa-lub-rious |
Besides the space character, any character whose hyphenation code value
is zero can be used to separate the arguments of hw (see the
documentation for the hcode request below for more information).
In addition, this request can be used more than once.
Hyphenation exceptions specified with the hw request are
associated with the current hyphenation language; it causes an error
if there is no current hyphenation language.
This request is ignored if there is no parameter.
In old versions of troff there was a limited amount of space to
store such information; fortunately, with gtroff, this is no
longer a restriction.
gtroff how to hyphenate words on the fly, use the
\% escape, also known as the hyphenation character.
Preceding a word with this character prevents it from being
hyphenated; putting it inside a word indicates to gtroff that
the word may be hyphenated at that point. Note that this mechanism
only affects that one occurrence of the word; to change the
hyphenation of a word for the entire document, use the hw
request.
The \: escape inserts a zero-width break point
(that is, the word breaks but without adding a hyphen).
... check the /var/log/\:httpd/\:access_log file ... |
Note that \X and \Y start a word, that is, the \%
escape in (say) ` \X'...'\%foobar' and
` \Y'...'\%foobar' no longer prevents hyphenation but inserts
a hyphenation point at the beginning of `foobar'; most likely
this isn't what you want to do.
\% escape, and thus, no longer appears in
the output. Without an argument, hc resets the hyphenation
character to be \% (the default) only.
The hyphenation character is associated with the current environment (see section 5.27 Environments).
It should have the same format as (simple) TeX patterns files. More specifically, the following scanning rules are implemented.
\$.
^^xx (x is 0-9 or a-f) and ^^x (character
code of x in the range 0-127) are recognized; other use of ^
causes an error.
hpf checks for the expression \patterns{...}
(possibly with whitespace before and after the braces).
Everything between the braces is taken as hyphenation patterns.
Consequently, { and } are not allowed in patterns.
\hyphenation{...} gives a list of hyphenation
exceptions.
\endinput is recognized also.
\patterns is missing,
the whole file is treated as a list of hyphenation patterns
(only recognizing the % character as the start of a comment).
If no hpf request is specified (either in the document or in a
macro package), gtroff won't hyphenate at all.
The hpfa request appends a file of patterns to the current list.
The hpfcode request defines mapping values for character codes in
hyphenation patterns. hpf or hpfa then apply the mapping
(after reading the patterns) before replacing or appending them to
the current list of patterns. Its arguments are pairs of character codes
-- integers from 0 to 255. The request maps character code a
to code b, code c to code d, and so on. You
can use character codes which would be invalid otherwise.
The set of hyphenation patterns is associated with the current language
set by the hla request. The hpf request is usually
invoked by the `troffrc' or `troffrc-end' file; by default,
`troffrc' loads hyphenation patterns for American English (in file
`hyphen.us').
A second call to hpf (for the same language) will replace the
hyphenation patterns with the new ones.
Invoking hpf causes an error if there is no current hyphenation
language.
This request is ignored if it has no parameter.
A negative argument resets the hyphenation margin to zero, emitting a warning of type `range'.
The current hyphenation margin is available in the .hym read-only
number register.
A negative argument resets the hyphenation space to zero, emitting a warning of type `range'.
The current hyphenation space is available in the .hys read-only
number register.
\(hy (this is the start-up value of gtroff also).
The soft hyphen character is the glyph that is inserted when a word is
hyphenated at a line break. If the soft hyphen character does not
exist in the font of the character immediately preceding a potential
break point, then the line is not broken at that point. Neither
definitions (specified with the char request) nor translations
(specified with the tr request) are considered when finding the
soft hyphen character.
hw request and
hyphenation patterns specified with the hpf and hpfa
requests are both associated with the current hyphenation language.
The hla request is usually invoked by the `troffrc' or the
`troffrc-end' files; `troffrc' sets the default language to
`us'.
The current hyphenation language is available as a string in the read-only number register `.hla'.
.ds curr_language \n[.hla]
\*[curr_language]
=> us
|
gtroff to move up the page
the specified distance. If the argument is preceded by a `|'
then gtroff moves that distance from the top of the page. This
request causes a line break. The default scaling indicator is `v'.
gtroff uses the previous value before the
last ls call.
.ls 2 \" This causes double-spaced output .ls 3 \" This causes triple-spaced output .ls \" Again double-spaced |
The line spacing is associated with the current environment (see section 5.27 Environments).
The read-only number register .L contains the current line
spacing setting.
See section 5.19.1 Changing Type Sizes, for the requests vs and pvs
as alternatives to ls.
\x
escape does this. The escape is given a numerical argument, usually
enclosed in quotes (like `\x'3p''); the default scaling indicator
is `v'. If this number is positive extra vertical space is
inserted below the current line. A negative number adds space above.
If this escape is used multiple times on the same line, the maximum of
the values is used.
See section 5.6.3 Escapes, for details on parameter delimiting characters.
The .a read-only number register contains the most recent
(nonnegative) extra vertical line space.
Using \x can be necessary in combination with the \b
escape, as the following example shows.
This is a test with the \[rs]b escape. .br This is a test with the \[rs]b escape. .br This is a test with \b'xyz'\x'-1m'\x'1m'. .br This is a test with the \[rs]b escape. .br This is a test with the \[rs]b escape. |
produces
This is a test with the \b escape.
This is a test with the \b escape.
x
This is a test with y.
z
This is a test with the \b escape.
This is a test with the \b escape.
|
sp or via blank lines) is disabled. The bp request to
advance to the next page is also disabled, except if it is accompanied
by a page number (see 5.17 Page Control, for more information). This
mode ends when actual text is output or the rs request is
encountered which ends no-space mode. The read-only number register
.ns is set to 1 as long as no-space mode is active.
This request is useful for macros that conditionally insert vertical space before the text starts (for example, a paragraph macro could insert some space except when it is the first paragraph after a section header).
A tab character (ASCII char 9, EBCDIC char@w{ 5) causes a horizontal movement to the next tab stop (much like it did on a typewriter).
\t is the same as a real tab character.
Tab stops can be specified absolutely, i.e., as the distance from the left margin. For example, the following sets 6 tab stops every one inch.
.ta 1i 2i 3i 4i 5i 6i |
Tab stops can also be specified using a leading `+' which means that the specified tab stop is set relative to the previous tab stop. For example, the following is equivalent to the previous example.
.ta 1i +1i +1i +1i +1i +1i |
gtroff supports an extended syntax to specify repeat values after
the `T' mark (these values are always taken as relative) -- this is
the usual way to specify tabs set at equal intervals. The following is,
yet again, the same as the previous examples. It does even more since
it defines an infinite number of tab stops separated by one inch.
.ta T 1i |
Now we are ready to interpret the full syntax given at the beginning: Set tabs at positions n1, n2, ..., nn and then set tabs at nn+r1, nn+r2, ..., nn+rn and then at nn+rn+r1, nn+rn+r2, ..., nn+rn+rn, and so on.
Example: `4c +6c T 3c 5c 2c' is equivalent to @samp{4c 10c 13c 18c 20c 23c 28c 30c ....
The material in each tab column (i.e., the column between two tab stops) may be justified to the right or left or centered in the column. This is specified by appending `R', `L', or `C' to the tab specifier. The default justification is `L'. Example:
.ta 1i 2iC 3iR |
Some notes:
ta request is `m'.
.ds foo a\tb\tc .ta T 5i \*[foo] |
creates a single line which is a bit longer than 10 inches (a string is used to show exactly where the tab characters are). Now consider the following:
.ds bar a\tb b\tc .ta T 5i \*[bar] |
gtroff first converts the tab stops of the line into unbreakable
horizontal movements, then splits the line after the second `b'
(assuming a sufficiently short line length). Usually, this isn't what
the user wants.
.ds Z foo\tbar\tfoo .ds ZZ foo\tbar\tfoobar .ds ZZZ foo\tbar\tfoo\tbar .ta 2i 4iR \*[Z] .br \*[ZZ] .br \*[ZZZ] .br |
which produces the following output:
foo bar foo foo bar foobar foo bar foobar |
The first line right-justifies the second `foo' relative to the tab stop. The second line right-justifies `foobar'. The third line finally right-justifies only `foo' because of the additional tab character which marks the end of the string belonging to the last defined tab stop.
ta without an argument removes all tab stops.
gtroff is `T 0.5i' in troff mode
and `T 0.8i' in nroff mode (the latter is done with an
explicit call to the ta request in the file `tty.tmac'.
The read-only number register .tabs contains a string
representation of the current tab settings suitable for use as an
argument to the ta request.
.ds tab-string \n[.tabs]
\*[tab-string]
=> T120u
|
The troff version of the Plan 9 operating system uses
register .S for the same purpose.
gtroff fills the space to the next tab stop with
whitespace. This can be changed with the tc request. With no
argument gtroff reverts to using whitespace, which is the
default. The value of this tab repetition character is
associated with the current environment
(see section 5.27 Environments).@footnotegroff_101.html{Tab repetition character is a
misnomer since it is an output glyph.
gtroff computes tab distances
relative to the (current) output line instead of the input line.
For example, the following code:
.ds x a\t\c .ds y b\t\c .ds z c .ta 1i 3i \*x \*y \*z |
in normal mode, results in the output
a b c |
in line-tabs mode, the same code outputs
a b c |
Line-tabs mode is associated with the current environment.
The read-only register .linetabs is set to 1 if in line-tabs
mode, and 0 in normal mode.
5.11.1 Leaders 5.11.2 Fields
Sometimes it may may be desirable to use the tc request to fill a
particular tab stop with a given glyph (for example dots in a table
of contents), but also normal tab stops on the rest of the line. For
this gtroff provides an alternate tab mechanism, called
leaders which does just that.
A leader character (character code 1) behaves similarly to a tab character: It moves to the next tab stop. The only difference is that for this movement, the fill glyph defaults to a period character and not to space.
\a is the same as a real leader
character.
gtroff's start-up value is a dot
(`.'). The value of the leader repetition character is
associated with the current environment (see section 5.27 Environments).
For a table of contents, to name an example, tab stops may be defined so that the section number is one tab stop, the title is the second with the remaining space being filled with a line of dots, and then the page number slightly separated from the dots.
.ds entry 1.1\tFoo\a\t12 .lc . .ta 1i 5i +.25i \*[entry] |
This produces
1.1 Foo.......................................... 12 |
Fields are a more general way of laying out tabular data. A field
is defined as the data between a pair of delimiting characters.
It contains substrings which are separated by padding characters.
The width of a field is the distance on the input line from the
position where the field starts to the next tab stop. A padding
character inserts stretchable space similar to TeX's \hss
command (thus it can even be negative) to make the sum of all substring
lengths plus the stretchable space equal to the field width. If more
than one padding character is inserted, the available space is evenly
distributed among them.
Example:
.fc # ^ .ta T 3i #foo^bar^smurf# .br #foo^^bar^smurf# |
and here the result:
foo bar smurf foo bar smurf |
The control character (`.') and the no-break control character
(`'') can be changed with the cc and c2 requests,
respectively.
This request can be very helpful in writing macros since it is not necessary then to double the escape character. Here an example:
.\" This is a simplified version of the
.\" .BR request from the man macro package
.eo
.de BR
. ds result \&
. while (\n[.$] >= 2) \{\
. as result \fB\$1\fR\$2
. shift 2
. \}
. if \n[.$] .as result \fB\$1
\*[result]
. ft R
..
.ec
|
eo request.
Note that changing the escape character globally will likely break
macro packages since gtroff has no mechanism to `intern' macros,
i.e., to convert a macro definition into an internal form which is
independent of its representation (TeX has this mechanism).
If a macro is called, it is executed literally.
ecs request saves the current escape character
in an internal register.
Use this request in combination with the ec request to
temporarily change the escape character.
The ecr request restores the escape character
saved with ecs.
Without a previous call to ecs, this request
sets the escape character to \.
\\ is a `delayed' backslash; more precisely, it is the default
escape character followed by a backslash, which no longer has special
meaning due to the leading escape character. It is not an escape
sequence in the usual sense! In any unknown escape sequence
\X the escape character is ignored and X is printed.
But if X is equal to the current escape character, no warning is
emitted.
As a consequence, only at top-level or in a diversion a backslash glyph is printed; in copy-in mode, it expands to a single backslash which then combines with the following character to an escape sequence.
The \E escape differs from \e by printing an escape
character that is not interpreted in copy mode.
Use this to define strings with escapes that work
when used in copy mode (for example, as a macro argument).
The following example defines strings to begin and end
a superscript:
.ds { \v'-.3m'\s'\Es[.s]*60/100'
.ds } \s0\v'.3m'
|
Another example to demonstrate the differences between the various escape sequences, using a strange escape character, `-'.
.ec -
.de xxx
--A'123'
..
.xxx
=> -A'foo'
|
The result is surprising for most users, expecting `1' since `foo' is a valid identifier. What has happened? As mentioned above, the leading escape character makes the following character ordinary. Written with the default escape character the sequence `--' becomes `\-' -- this is the minus sign.
If the escape character followed by itself is a valid escape sequence,
only \E yields the expected result:
.ec -
.de xxx
-EA'123'
..
.xxx
=> 1
|
\\, the sequence \. isn't a real escape sequence.
As before, a warning message is suppressed if the escape character is
followed by a dot, and the dot itself is printed.
.de foo
. nop foo
.
. de bar
. nop bar
\\..
.
..
.foo
.bar
=> foo bar
|
The first backslash is consumed while the macro is read, and the second
is swallowed while exexuting macro foo.
A translation is a mapping of an input character to an output
glyph. The mapping occurs at output time, i.e., the input character
gets assigned the metric information of the mapped output character
right before input tokens are converted to nodes (see section 5.33 gtroff Internals, for more on this process).
The trin request is identical to tr,
but when you unformat a diversion with asciify
it ignores the translation.
See section 5.26 Diversions, for details about the asciify request.
Some notes:
\(xx, \[xxx],
\C'xxx', \', \`, \-, \_),
glyphs defined with the char request, and numbered glyphs
(\N'xxx') can be translated also.
\e escape can be translated also.
\% and \~ escapes (but
\% and \~ can't be mapped onto another glyph).
\a), tab (and
\t).
shc request.
.tr a\&
foo bar
=> foo br
|
It is even possible to map the space character to nothing:
.tr aa \&
foo bar
=> foobar
|
As shown in the example, the space character can't be the first
character/glyph pair as an argument of tr. Additionally, it is
not possible to map the space character to any other glyph; requests
like `.tr aa x' undo `.tr aa \&' instead.
If justification is active, lines are justified in spite of the `empty' space character (but there is no minimal distance, i.e. the space character, between words).
tr.
tr does not check whether the
entities in its argument do exist.
See section 5.33 gtroff Internals.
troff no longer has a hard-coded dependency on Latin-1;
all charXXX entities have been removed from the font
description files. This has a notable consequence which shows up in
warnings like can't find character with input code XXX
if the tr request isn't handled properly.
Consider the following translation:
.tr éÉ |
This maps input character é onto glyph É, which is
identical to glyph char201. But this glyph intentionally
doesn't exist! Instead, \[char201] is treated as an input
character entity and is by default mapped onto \['E], and
gtroff doesn't handle translations of translations.
The right way to write the above translation is
.tr é\['E] |
With other words, the first argument of tr should be an input
character or entity, and the second one a glyph entity.
tr request is ignored.
trnt is the same as the tr request except that the
translations do not apply to text that is transparently throughput
into a diversion with \!. See section 5.26 Diversions, for more
information.
For example,
.tr ab .di x \!.tm a .di .x |
prints `b' to the standard error stream; if trnt is used
instead of tr it prints `a'.
Originally, nroff and troff were two separate programs,
the former for TTY output, the latter for everything else. With GNU
troff, both programs are merged into one executable, sending
its output to a device driver (grotty for TTY devices,
grops for POSTSCRIPT, etc.) which interprets the
intermediate output of gtroff. For UNIX troff
it makes sense to talk about Nroff mode and Troff mode
since the differences are hardcoded. For GNU troff, this
distinction is not appropriate because gtroff simply takes the
information given in the font files for a particular device without
handling requests specially if a TTY output device is used.
Usually, a macro package can be used with all output devices.
Nevertheless, it is sometimes necessary to make a distinction between
TTY and non-TTY devices: gtroff provides two built-in
conditions `n' and `t' for the if, ie, and
while requests to decide whether gtroff shall behave
like nroff or like troff.
if, ie, and while
conditional requests. This is the default if gtroff
(not groff) is started with the `-R' switch to
avoid loading of the start-up files `troffrc' and
`troffrc-end'. Without `-R', gtroff stays in troff
mode if the output device is not a TTY (e.g. `ps').
if, ie, and while
conditional requests. This is the default if gtroff uses a TTY
output device; the code for switching to nroff mode is in the file
`tty.tmac' which is loaded by the start-up file troffrc.
See section 5.21 Conditionals and Loops, for more details on built-in conditions.
The following drawing shows the dimensions which gtroff uses for
placing a line of output onto the page. They are labeled with the
request which manipulates each dimension.
-->| in |<--
|<-----------ll------------>|
+----+----+----------------------+----+
| : : : |
+----+----+----------------------+----+
-->| po |<--
|<--------paper width---------------->|
|
These dimensions are:
po
in
ll
A simple demonstration:
.ll 3i This is text without indentation. The line length has been set to 3\~inch. .in +.5i .ll -.5i Now the left and right margins are both increased. .in .ll Calling .in and .ll without parameters restore the previous values. |
Result:
This is text without indenta-
tion. The line length has
been set to 3 inch.
Now the left and
right margins are
both increased.
Calling .in and .ll without
parameters restore the previ-
ous values.
|
The current page offset can be found in the read-only number register `.o'.
If po is called without an argument, the page offset is reset to
the previous value before the last call to po.
.po 3i
\n[.o]
=> 720
.po -1i
\n[.o]
=> 480
.po
\n[.o]
=> 720
|
If in is called without an argument, the indentation is reset to
the previous value before the last call to in. The default
scaling indicator is `m'.
The indentation is associated with the current environment (see section 5.27 Environments).
If a negative indentation value is specified (which is not allowed),
gtroff emits a warning of type `range' and sets the
indentation to zero.
The effect of in is delayed until a partially collected line (if
it exists) is output. A temporary indent value is reset to zero also.
The current indentation (as set by in) can be found in the
read-only number register `.i'.
in request.
This request causes a break; its value is associated with the current
environment (see section 5.27 Environments). The default scaling indicator
is `m'. A call of ti without an argument is ignored.
If the total indentation value is negative (which is not allowed),
gtroff emits a warning of type `range' and sets the
temporary indentation to zero. `Total indentation' is either
offset if specified as an absolute value, or the temporary plus
normal indentation, if offset is given as a relative value.
The effect of ti is delayed until a partially collected line (if
it exists) is output.
The read-only number register .in is the indentation that applies
to the current output line.
The difference between .i and .in is that the latter takes
into account whether a partially collected line still uses the old
indentation value or a temporary indentation value is active.
ll is delayed until a partially
collected line (if it exists) is output. The default scaling
indicator is `m'.
If ll is called without an argument, the line length is reset to
the previous value before the last call to ll. If a negative
line length is specified (which is not allowed), gtroff emits a
warning of type `range' and sets the line length to zero.
The line length is associated with the current environment (see section 5.27 Environments).
The current line length (as set by ll) can be found in the
read-only number register `.l'. The read-only number register
.ll is the line length that applies to the current output line.
Similar to .i and .in, the difference between .l
and .ll is that the latter takes into account whether a partially
collected line still uses the old line length value.
It is important to understand how gtroff handles input and output
lines.
Many escapes use positioning relative to the input line. For example, this
This is a \h'|1.2i'test. This is a \h'|1.2i'test. |
produces
This is a test. This is a test. |
The main usage of this feature is to define macros which act exactly at the place where called.
.\" A simple macro to underline a word .de underline . nop \\$1\l'|0\[ul]' .. |
In the above example, `|0' specifies a negative distance from the
current position (at the end of the just emitted argument \$1) back
to the beginning of the input line. Thus, the `\l' escape draws a
line from right to left.
gtroff makes a difference between input and output line
continuation; the latter is also called interrupting a line.
\RET (this is a backslash at the end
of a line immediately followed by a newline) works on the input level,
suppressing the effects of the following newline in the input.
This is a \
.test
=> This is a .test
|
The `|' operator is also affected.
\c works on the output level. Anything after this escape on the
same line is ignored, except \R which works as usual. Anything
before \c on the same line will be appended to the current partial
output line. The next non-command line after an interrupted line counts
as a new input line.
The visual results depend on whether no-fill mode is active.
nf request), the next input
text line after \c will be handled as a continuation of the same
input text line.
.nf
This is a \c
test.
=> This is a test.
|
fi request), a word interrupted
with \c will be continued with the text on the next input text line,
without an intervening space.
This is a te\c
st.
=> This is a test.
|
Note that an intervening control line which causes a break is stronger
than \c, flushing out the current partial line in the usual way.
The .int register contains a positive value
if the last output line was interrupted with \c; this is
associated with the current environment (see section 5.27 Environments).
gtroff provides some very primitive operations for controlling
page layout.
The current setting can be found in the read-only number register `.p'.
Note that this only specifies the size of the page, not the top and
bottom margins. Those are not set by gtroff directly.
See section 5.25 Traps, for further information on how to do this.
Negative pl values are possible also, but not very useful: No
trap is sprung, and each line is output on a single page (thus
suppressing all vertical spacing).
If no argument or an invalid argument is given, pl sets the page
length to 11i.
gtroff provides several operations which help in setting up top
and bottom titles (or headers and footers).
pc request (see below).
Without argument, tl is ignored.
Some notes:
tl prints the title line immediately, ignoring a partially filled
line (which stays untouched).
tl accepts the same parameter delimiting characters as the
\A escape; see 5.6.3 Escapes.
lt request.
Initially, the title line length is set to 6.5i. If a negative
line length is specified (which is not allowed), gtroff emits a
warning of type `range' and sets the title line length to zero.
The default scaling indicator is `m'. If lt is called
without an argument, the title length is reset to the previous value
before the last call to lt.
The current setting of this is available in the .lt read-only
number register; it is associated with the current environment
(see section 5.27 Environments).
The read-only number register .pn contains the number of the next
page: either the value set by a pn request, or the number of the
current page plus 1.
tl request) to a
different character. With no argument, this mechanism is disabled.
Note that this doesn't affect the number register %.
See section 5.25 Traps.
bp and pn is that pn does not
cause a break or actually eject a page.
.de newpage \" define macro 'bp \" begin page 'sp .5i \" vertical space .tl 'left top'center top'right top' \" title 'sp .3i \" vertical space .. \" end macro |
bp has no effect if not called within the top-level diversion
(see section 5.26 Diversions).
ne
request ensures that there is a certain distance, specified by the
first argument, before the next page is triggered (see 5.25 Traps,
for further information). The default scaling indicator for ne
is `v'; the default value of space is 1v if no
argument is given.
For example, to make sure that no fewer than 2 lines get orphaned, do the following before each paragraph:
.ne 2 text text text |
ne will then automatically cause a page break if there is space
for one line only.
sv is similar to the ne request; it reserves the
specified amount of vertical space. If the desired amount of space
exists before the next trap (or the bottom page boundary if no trap is
set), the space is output immediately (ignoring a partially filled line
which stays untouched). If there is not enough space, it is stored for
later output via the os request. The default value is 1v
if no argument is given; the default scaling indicator is `v'.
Both sv and os ignore no-space mode. While the sv
request allows negative values for space, os will ignore
them.
nl is set to negative value. gtroff itself does this at
the very beginning of a document before anything has been printed, but
the main usage is to plant a header trap on a page if this page has
already started.
Consider the following:
.de xxx . sp . tl ''Header'' . sp .. . First page. .bp .wh 0 xxx .nr nl (-1) Second page. |
Result:
First page.
...
Header
Second page.
...
|
Without resetting nl to a negative value, the just planted trap
would be active beginning with the next page, not the current
one.
See section 5.26 Diversions, for a comparison with the .h and .d
registers.
gtroff can switch fonts at any point in the text.
The basic set of fonts is `R', `I', `B', and `BI'. These are Times Roman, Italic, Bold, and Bold Italic. For non-TTY devices, there is also at least one symbol font which contains various special symbols (Greek, mathematics).
5.18.1 Changing Fonts 5.18.2 Font Families 5.18.3 Font Positions 5.18.4 Using Symbols 5.18.5 Special Fonts 5.18.6 Artificial Fonts 5.18.7 Ligatures and Kerning
ft request and the \f escape change the current font
to font (one-character name f, two-character name
fn).
If font is a style name (as set with the sty request or
with the styles command in the `DESC' file), use it within
the current font family (as set with the fam request, \F
escape, or with the family command in the `DESC' file).
With no argument or using `P' as an argument, .ft switches
to the previous font. Use \f[] to do this with the escape. The
old syntax forms \fP or \f[P] are also supported.
Fonts are generally specified as upper-case strings, which are usually 1 to 4 characters representing an abbreviation or acronym of the font name. This is no limitation, just a convention.
The example below produces two identical lines.
eggs, bacon, .ft B spam .ft and sausage. eggs, bacon, \fBspam\fP and sausage. |
Note that \f doesn't produce an input token in gtroff.
As a consequence, it can be used in requests like mc (which
expects a single character as an argument) to change the font on
the fly:
.mc \f[I]x\f[] |
See section 5.18.3 Font Positions, for an alternative syntax.
\f escape sequence, or in the
ft, ul, bd, cs, tkf,
special, fspecial, fp, or sty requests,
font g is used. If g is missing or equal to f
the translation is undone.
Due to the variety of fonts available, gtroff has added the
concept of font families and font styles. The fonts are
specified as the concatenation of the font family and style. Specifying
a font without the family part causes gtroff to use that style of
the current family.
Currently, fonts for the devices `-Tps', `-Tdvi', and
`-Tlbp' are set up to this mechanism.
By default, gtroff uses the Times family with the four styles
`R', `I', `B', and `BI'.
This way, it is possible to use the basic four fonts and to select a different font family on the command line (see section 2.1 Options).
\F[] to do this with the
escape. Note that \FP doesn't work; it selects font family
`P' instead.
The value at start-up is `T'. The current font family is available in the read-only number register `.fam' (this is a string-valued register); it is associated with the current environment.
spam, .fam H \" helvetica family spam, \" used font is family H + style R = HR .ft B \" family H + style B = font HB spam, .fam T \" times family spam, \" used font is family T + style B = TB .ft AR \" font AR (not a style) baked beans, .ft R \" family T + style R = font TR and spam. |
Note that \F doesn't produce an input token in gtroff.
As a consequence, it can be used in requests like mc (which
expects a single character as an argument) to change the font family on
the fly:
.mc \F[P]x\F[] |
The `.fn' register contains the current real font name
of the current font.
This is a string-valued register.
If the current font is a style, the value of \n[.fn]
is the proper concatenation of family and style name.
cs, bd,
tkf, uf, or fspecial are applied to a style,
they will instead be applied to the member of the current family
corresponding to that style.
n must be a non-negative integer value.
The default family can be set with the `-f' option
(see section 2.1 Options). The styles command in the `DESC'
file controls which font positions (if any) are initially associated
with styles rather than fonts. For example, the default setting for
POSTSCRIPT fonts
styles R I B BI |
is equivalent to
.sty 1 R .sty 2 I .sty 3 B .sty 4 BI |
fam and \F always check whether the current font position
is valid; this can give surprising results if the current font position is
associated with a style.
In the following example, we want to access the POSTSCRIPT font
FooBar from the font family Foo:
.sty \n[.fp] Bar
.fam Foo
=> warning: can't find font `FooR'
|
The default font position at start-up is 1; for the
POSTSCRIPT device, this is associated with style `R', so
gtroff tries to open FooR.
A solution to this problem is to use a dummy font like the following:
.fp 0 dummy TR \" set up dummy font at position 0 .sty \n[.fp] Bar \" register style `Bar' .ft 0 \" switch to font at position 0 .fam Foo \" activate family `Foo' .ft Bar \" switch to font `FooBar' |
See section 5.18.3 Font Positions.
For the sake of old phototypesetters and compatibility with old versions
of troff, gtroff has the concept of font positions,
on which various fonts are mounted.
gtroff starts it is using
font position 1 (which must exist; position 0 is unused
usually at start-up).
The current font in use, as a font position, is available in the read-only number register `.f'. This can be useful to remember the current font for later recall. It is associated with the current environment (see section 5.27 Environments).
.nr save-font \n[.f] .ft B ... text text text ... .ft \n[save-font] |
The number of the next free font position is available in the read-only number register `.fp'. This is useful when mounting a new font, like so:
.fp \n[.fp] NEATOFONT |
Fonts not listed in the `DESC' file are automatically mounted on
the next available font position when they are referenced. If a font
is to be mounted explicitly with the fp request on an unused
font position, it should be mounted on the first unused font position,
which can be found in the .fp register. Although gtroff
does not enforce this strictly, it is not allowed to mount a font at a
position whose number is much greater (approx. 1000 positions) than
that of any currently used position.
The fp request has an optional third argument. This argument
gives the external name of the font, which is used for finding the font
description file. The second argument gives the internal name of the
font which is used to refer to the font in gtroff after it has
been mounted. If there is no third argument then the internal name is
used as the external name. This feature makes it possible to use
fonts with long names in compatibility mode.
Both the ft request and the \f escape have alternative
syntax forms to access font positions.
If nnn is associated with a style (as set with the sty
request or with the styles command in the `DESC' file), use
it within the current font family (as set with the fam request,
the \F escape, or with the family command in the `DESC'
file).
this is font 1 .ft 2 this is font 2 .ft \" switch back to font 1 .ft 3 this is font 3 .ft this is font 1 again |
See section 5.18.1 Changing Fonts, for the standard syntax form.
A glyph is a graphical representation of a character. While a character is an abstract entity containing semantic information, a glyph is something which can be actually seen on screen or paper. It is possible that a character has multiple glyph representation forms (for example, the character `A' can be either written in a roman or an italic font, yielding two different glyphs); sometimes more than one character maps to a single glyph (this is a ligature -- the most common is `fi').
A symbol is simply a named glyph. Within gtroff, all
glyph names of a particular font are defined in its font file. If the
user requests a glyph not available in this font, gtroff looks
up an ordered list of special fonts. By default, the
POSTSCRIPT output device supports the two special fonts `SS'
(slanted symbols) and `S' (symbols) (the former is looked up
before the latter). Other output devices use different names for
special fonts. Fonts mounted with the fonts keyword in the
`DESC' file are globally available. To install additional
special fonts locally (i.e. for a particular font), use the
fspecial request.
In summary, gtroff tries the following to find a given symbol:
char request, use it.
This hides a symbol with the same name in the current font.
fchar request, use it.
fspecial request, in the order
of appearance in fspecial calls.
special request, in the order
of appearance in special calls (inclusively the special fonts
defined in the `DESC' file, which come first).
See section 8.2 Font Files, and 5.18.5 Special Fonts, for more details.
a is not the same as \[a]. By default,
groff defines only a single one-character symbol, \[-];
it is usually accessed as \-. On the other hand, gtroff
has the special feature that \[charXXX] is the same as the
input character with character code XXX. For example,
\[char97] is identical to the letter a if ASCII
encoding is active.
If name is undefined, a warning of type `char' is generated, and the escape is ignored. See section 5.34 Debugging, for information about warnings.
The list of available symbols is device dependent; see the groff_char(7) man page for a complete list for the given output device. For example, say
man -Tdvi groff_char > groff_char.dvi |
for a list using the default DVI fonts (not all versions of the
man program support the `-T' option). If you want to
use an additional macro package to change the used fonts, groff
must be called directly:
groff -Tdvi -mec -man groff_char.7 > groff_char.dvi |
\C is actually a
misnomer since it accesses an output glyph. Normally it is more
convenient to use \[xxx], but \C has the advantage
that it is compatible with newer versions of AT&T
troff and is available in compatibility mode.
n is not the input character code). The
number n can be any non-negative decimal integer. Most devices
only have glyphs with codes between 0 and 255; the Unicode
output device uses codes in the range 0--65535. If the current
font does not contain a glyph with that code, special fonts are
not searched. The \N escape sequence can be
conveniently used in conjunction with the char request:
.char \[phone] \f[ZD]\N'37' |
The code of each glyph is given in the fourth column in the font
description file after the charset command. It is possible to
include unnamed glyphs in the font description file by using a
name of `---'; the \N escape sequence is the only way to
use these.
Some escape sequences directly map onto special glyphs.
0x27 (EBCDIC character 0x7D). The same
as \[aa], the acute accent.
0x60
(EBCDIC character 0x79 usually). The same as
\[ga], the grave accent.
\[-], the minus sign in the current font.
gtroff, a glyph is a numbered box with
a given width, depth, and height, nothing else. All manipulations
with the cflags request work on the input level. These
properties can be modified with the cflags request. The
first argument is the sum of the desired flags and the remaining
arguments are the characters or symbols to have those properties.
It is possible to omit the spaces between the characters or symbols.
1
2
4
8
16
32
char is a misnomer since an output glyph is
defined. Every time glyph g needs to be printed,
string is processed in a temporary environment and the result is
wrapped up into a single object. Compatibility mode is turned off and
the escape character is set to `\' while string is being
processed. Any emboldening, constant spacing or track kerning is
applied to this object rather than to individual characters in
string.
A glyph defined by this request can be used just
like a normal glyph provided by the output device. In particular,
other characters can be translated to it with the tr or
trin requests; it can be made the leader character by the
lc request; repeated patterns can be drawn with the glyph
using the \l and \L escape sequences; words containing
the glyph can be hyphenated correctly if the hcode request
is used to give the glyph's symbol a hyphenation code.
There is a special anti-recursion feature: Use of g within
the glyph's definition is handled like normal characters and symbols
not defined with char.
Note that the tr and trin requests take precedence if
char accesses the same symbol.
.tr XY
X
=> Y
.char X Z
X
=> Y
.tr XX
X
=> Z
|
The fchar request defines a fallback glyph:
gtroff only checks for glyphs defined with fchar
if it cannot find the glyph in the current font.
gtroff carries out this test before checking special fonts.
char or fchar
request.
It is possible to omit the whitespace between arguments.
See section 7.1 Special Characters.
Special fonts are those that gtroff searches
when it cannot find the requested glyph in the current font.
The Symbol font is usually a special font.
gtroff provides the following two requests to add more special
fonts. See section 5.18.4 Using Symbols, for a detailed description of the glyph
searching mechanism in gtroff.
Usually, only non-TTY devices have special fonts.
special request to define special fonts. They are
appended to the list of global special fonts in the given order.
The first entries in this list are the fonts defined with the
fonts command in the `DESC' file which are marked as
special in the corresponding font description files.
Use the fspecial request to designate special fonts
only when font f font is active. They are appended to the
list of special fonts for f in the given order. Initially, this
list is empty.
There are a number of requests and escapes for artificially creating
fonts. These are largely vestiges of the days when output devices
did not have a wide variety of fonts, and when nroff and
troff were separate programs. Most of them are no longer
necessary in GNU troff. Nevertheless, they are supported.
Currently, only the `-Tps' device supports this feature.
Note that \H doesn't produce an input token in gtroff.
As a consequence, it can be used in requests like mc (which
expects a single character as an argument) to change the font on
the fly:
.mc \H'+5z'x\H'0' |
In compatibility mode, gtroff behaves differently: If an
increment or decrement is used, it is always taken relative to the
current point size and not relative to the previously selected font
height. Thus,
.cp 1 \H'+5'test \H'+5'test |
prints the word `test' twice with the same font height (five points larger than the current font size).
Currently, only the `-Tps' device supports this feature.
Note that \S doesn't produce an input token in gtroff.
As a consequence, it can be used in requests like mc (which
expects a single character as an argument) to change the font on
the fly:
.mc \S'20'x\S'0' |
This request is incorrectly documented in the original UNIX troff manual; the slant is always set to an absolute value.
ul request normally underlines subsequent lines if a TTY
output device is used. Otherwise, the lines are printed in italics
(only the term `underlined' is used in the following). The single
argument is the number of input lines to be underlined; with no
argument, the next line is underlined. If lines is zero or
negative, stop the effects of ul (if it was active). Requests
and empty lines do not count for computing the number of underlined
input lines, even if they produce some output like tl. Lines
inserted by macros (e.g. invoked by a trap) do count.
At the beginning of ul, the current font is stored and the
underline font is activated. Within the span of a ul request,
it is possible to change fonts, but after the last line affected by
ul the saved font is restored.
This number of lines still to be underlined is associated with the
current environment (see section 5.27 Environments). The underline font can be
changed with the uf request.
The ul request does not underline spaces.
cu request is similar to ul but underlines spaces as
well (if a TTY output device is used).
ul and cu. By
default, this is the font at position 2. font can be either
a non-negative font position or the name of a font.
Two syntax forms are available.
font can be either a non-negative font position or the name of a font.
offset is available in the .b read-only register if a
special font is active; in the bd request, its default unit is
`u'.
This affects special fonts only (either set up with the special
command in font files or with the fspecial request).
ps
request) when the font is effectively in use. Without second and
third argument, constant glyph space mode is deactivated.
Default scaling indicator for em-size is `z'; width is an integer.
Ligatures are groups of characters that are run together, i.e, producing a single glyph. For example, the letters `f' and `i' can form a ligature `fi' as in the word `file'. This produces a cleaner look (albeit subtle) to the printed output. Usually, ligatures are not available in fonts for TTY output devices.
Most POSTSCRIPT fonts support the fi and fl ligatures. The C/A/T
typesetter that was the target of AT&T troff also
supported `ff', `ffi', and `ffl' ligatures. Advanced typesetters or
`expert' fonts may include ligatures for `ft' and `ct', although GNU
troff does not support these (yet).
.lg (set to 1 or 2 if ligatures are enabled, 0 otherwise).
Setting the ligature mode to 2 enables the two-character ligatures (fi, fl, and ff) and disables the three-character ligatures (ffi and ffl).
Pairwise kerning is another subtle typesetting mechanism that modifies the distance between a glyph pair to improve readability. In most cases (but not always) the distance is decreased. For example, compare the combination of the letters `V' and `A'. With kerning, `VA' is printed. Without kerning it appears as `VA'. Typewriter-like fonts and fonts for terminals where all glyphs have the same width don't use kerning.
.kern is set to 1 if pairwise kerning is enabled,
0 otherwise.
If the font description file contains pairwise kerning information,
glyphs from that font are kerned. Kerning between two glyphs
can be inhibited by placing \& between them: `V\&A'.
See section 8.2.2 Font File Format.
Track kerning expands or reduces the space between glyphs. This can be handy, for example, if you need to squeeze a long word onto a single line or spread some text to fill a narrow column. It must be used with great care since it is usually considered bad typography if the reader notices the effect.
The default scaling indicator is `z' for s1 and s2, `p' for n1 and n2.
Note that the track kerning amount is added even to the rightmost glyph in a line; for large values it is thus recommended to increase the line length by the same amount to compensate it.
Sometimes, when typesetting letters of different fonts, more or less space at such boundaries are needed. There are two escapes to help with this.
f is immediately followed by a roman right
parenthesis, then in many fonts the top right portion of the f
overlaps the top left of the right parenthesis. Use this escape
sequence whenever an italic glyph is immediately followed by a
roman glyph without any intervening space. This small amount of
space is also called italic correction.
Test.
Test.
=> Test. Test.
Test.\&
Test.
=> Test. Test.
|
.Test
=> warning: `Test' not defined
\&.Test
=> .Test
|
VA
=> VA
V\&A
=> VA
|
tr
request (see section 5.12 Character Translations).
\& except that it behaves like a
character declared with the cflags request to be transparent
for the purposes of an end-of-sentence character.
Its main usage is in macro definitions to protect against arguments starting with a control character.
.de xxx
\)\\$1
..
.de yyy
\&\\$1
..
This is a test.\c
.xxx '
This is a test.
=>This is a test.' This is a test.
This is a test.\c
.yyy '
This is a test.
=>This is a test.' This is a test.
|
gtroff uses two dimensions with each line of text, type size
and vertical spacing. The type size is approximately the height
of the tallest glyph.@footnotegroff_118.html{This is usually the parenthesis.
Note that in most cases the real dimensions of the glyphs in a font
are not related to its type size! For example, the standard
POSTSCRIPT font families `Times Roman', `Helvetica', and
`Courier' can't be used together at 10pt; to get acceptable
output, the size of `Helvetica' has to be reduced by one point, and
the size of `Courier' must be increased by one point. Vertical
spacing is the amount of space gtroff allows for a line of
text; normally, this is about 20% larger than the current type
size. Ratios smaller than this can result in hard-to-read text;
larger than this, it spreads the text out more vertically (useful for
term papers). By default, gtroff uses 10 point type on
12 point spacing.
The difference between type size and vertical spacing is known, by typesetters, as leading (this is pronounced `ledding').
5.19.1 Changing Type Sizes 5.19.2 Fractional Type Sizes
ps request or the \s escape to change (increase,
decrease) the type size (in points). Specify size as either an
absolute point size, or as a relative change from the current size.
The size 0, or no argument, goes back to the previous size.
Default scaling indicator of size is `z'. If size
is zero or negative, it is set to 1u.
The read-only number register .s returns the point size in
points as a decimal fraction. This is a string. To get the point
size in scaled points, use the .ps register instead.
.s is associated with the current environment
(see section 5.27 Environments).
snap, snap, .ps +2 grin, grin, .ps +2 wink, wink, \s+2nudge, nudge,\s+8 say no more! .ps 10 |
The \s escape may be called in a variety of ways. Much like
other escapes there must be a way to determine where the argument ends
and the text begins. Any of the following forms are valid:
\sn
\s+n
\s-n
\s(nn
\s+(nn
\s-(nn
\s(+nn
\s(-nn
Note that \s doesn't produce an input token in gtroff.
As a consequence, it can be used in requests like mc (which
expects a single character as an argument) to change the font on
the fly:
.mc \s[20]x\s[0] |
See section 5.19.2 Fractional Type Sizes, for yet another syntactical form of
using the \s escape.
gtroff rounds to the nearest permissible size.
The `DESC' file specifies which sizes are permissible for the device.
Use the sizes request to change the permissible sizes
for the current output device.
Arguments are in scaled points;
the sizescale line in the
`DESC' file for the output device
provides the scaling factor.
For example, if the scaling factor is 1000,
then the value 12000 is 12 points.
Each argument can be a single point size (such as `12000'), or a range of sizes (such as `4000-72000'). You can optionally end the list with a zero.
If vs is called without an argument, the vertical spacing is
reset to the previous value before the last call to vs.
gtroff creates a warning of type `range' if space is
zero or negative; the vertical spacing is then set to the vertical
resolution (as given in the .V register).
The read-only number register .v contains the current vertical
spacing; it is associated with the current environment
(see section 5.27 Environments).
The effective vertical line spacing consists of four components.
vs request.
pvs request.
This is vertical space which will be added after a line has been
output.
\x request,
using a negative value. This is vertical space which will be added once
before the current line has been output.
\x request,
using a positive value. This is vertical space which will be added once
after the current line has been output.
It is usually better to use vs or pvs instead of ls
to produce double-spaced documents: vs and pvs have a finer
granularity for the inserted vertical space compared to ls;
furthermore, certain preprocessors assume single-spacing.
See section 5.10 Manipulating Spacing, for more details on the \x escape
and the ls request.
If pvs is called without an argument, the post-vertical spacing is
reset to the previous value before the last call to pvs.
gtroff creates a warning of type `range' if space is
zero or negative; the vertical spacing is then set to zero.
The read-only number register .pvs contains the current
post-vertical spacing; it is associated with the current environment
(see section 5.27 Environments).
A scaled point is equal to 1/sizescale points,
where sizescale is specified in the `DESC' file (1 by
default). There is a new scale indicator `z' which has the
effect of multiplying by sizescale. Requests and escape
sequences in gtroff interpret arguments that represent a point
size as being in units of scaled points, but they evaluate each such
argument using a default scale indicator of `z'. Arguments
treated in this way are the argument to the ps request, the
third argument to the cs request, the second and fourth
arguments to the tkf request, the argument to the \H
escape sequence, and those variants of the \s escape sequence
that take a numeric expression as their argument (see below).
For example, suppose sizescale is 1000; then a scaled point is equivalent to a millipoint; the request `.ps 10.25' is equivalent to `.ps 10.25z' and thus sets the point size to 10250 scaled points, which is equal to 10.25 points.
gtroff disallows the use of the `z' scale indicator in
instances where it would make no sense, such as a numeric
expression whose default scale indicator was neither `u' nor
`z'. Similarly it would make
no sense to use a scaling indicator other than `z' or `u' in a
numeric expression whose default scale indicator was `z', and so
gtroff disallows this as well.
There is also new scale indicator `s' which multiplies by the number of units in a scaled point. So, for example, `\n[.ps]s' is equal to `1m'. Be sure not to confuse the `s' and `z' scale indicators.
.ps is associated with the current environment
(see section 5.27 Environments).
.psr read-only number register. The last requested point size
in points as a decimal fraction can be found in .sr. This is a
string-valued read-only number register.
Note that the requested point sizes are device-independent, whereas
the values returned by the .ps and .s registers are not.
For example, if a point size of 11pt is requested, and a
sizes request (or a sizescale line in a `DESC' file)
specifies 10.95pt instead, this value is actually used.
Both registers are associated with the current environment (see section 5.27 Environments).
The \s escape has the following syntax for working with
fractional type sizes:
\s[n]
\s'n'
\s[+n]
\s[-n]
\s+[n]
\s-[n]
\s'+n'
\s'-n'
\s+'n'
\s-'n'
See section 8.2 Font Files.
gtroff has string variables, which are entirely for user
convenience (i.e. there are no built-in strings exept .T, but
even this is a read-write string variable).
ds overwrites the previous definition. Only the syntax form
using brackets can take arguments which are handled identically to
macro arguments; the single exception is that a closing bracket as an
argument must be enclosed in double quotes. See section 5.6.1.1 Request Arguments,
and 5.22.2 Parameters.
Example:
.ds foo a \\$1 test
.
This is \*[foo nice].
=> This is a nice test.
|
The \* escape interpolates (expands in-place) a
previously-defined string variable. To be more precise, the stored
string is pushed onto the input stack which is then parsed by
gtroff. Similar to number registers, it is possible to nest
strings, i.e. string variables can be called within string variables.
If the string named by the \* escape does not exist, it is
defined as empty, and a warning of type `mac' is emitted (see
5.34 Debugging, for more details).
Caution: Unlike other requests, the second argument to the
ds request takes up the entire line including trailing spaces.
This means that comments on a line with such a request can introduce
unwanted space into a string.
.ds UX \s-1UNIX\s0\u\s-3tm\s0\d \" UNIX trademark |
Instead the comment should be put on another line or have the comment escape adjacent with the end of the string.
.ds UX \s-1UNIX\s0\u\s-3tm\s0\d\" UNIX trademark |
To produce leading space the string can be started with a double quote. No trailing quote is needed; in fact, any trailing quote is included in your string.
.ds sign " Yours in a white wine sauce, |
Strings are not limited to a single line of text. A string can span several lines by escaping the newlines with a backslash. The resulting string is stored without the newlines.
.ds foo lots and lots \ of text are on these \ next several lines |
It is not possible to have real newlines in a string. To put a single double quote character into a string, use two consecutive double quote characters.
The ds1 request turns off compatibility mode
while interpreting a string. To be more precise, a @dfn{compatibility
save input token is inserted at the beginning of the string, and a
compatibility restore input token at the end.
.nr xxx 12345
.ds aa The value of xxx is \\n[xxx].
.ds1 bb The value of xxx ix \\n[xxx].
.
.cp 1
.
\*(aa
=> warning: number register `[' not defined
=> The value of xxx is 0xxx].
\*(bb
=> The value of xxx ix 12345.
|
Strings, macros, and diversions (and boxes) share the same name space. Internally, even the same mechanism is used to store them. This has some interesting consequences. For example, it is possible to call a macro with string syntax and vice versa.
.de xxx
a funny test.
..
This is \*[xxx]
=> This is a funny test.
.ds yyy a funny test
This is
.yyy
=> This is a funny test.
|
Diversions and boxes can be also called with string syntax.
Another consequence is that you can copy one-line diversions or boxes to a string.
.di xxx
a \fItest\fR
.br
.di
.ds yyy This is \*[xxx]\c
\*[yyy].
=> This is a test.
|
As the previous example shows, it is possible to store formatted
output in strings. The \c escape prevents the insertion of an
additional blank line in the output.
Copying diversions longer than a single output line produces unexpected results.
.di xxx
a funny
.br
test
.br
.di
.ds yyy This is \*[xxx]\c
\*[yyy].
=> test This is a funny.
|
Usually, it is not predictable whether a diversion contains one or
more output lines, so this mechanism should be avoided. With
UNIX troff, this was the only solution to strip off a
final newline from a diversion. Another disadvantage is that the
spaces in the copied string are already formatted, making them
unstretchable. This can cause ugly results.
A clean solution to this problem is available in GNU troff,
using the requests chop to remove the final newline of a
diversion, and unformat to make the horizontal spaces
stretchable again.
.box xxx
a funny
.br
test
.br
.box
.chop xxx
.unformat xxx
This is \*[xxx].
=> This is a funny test.
|
See section 5.33 gtroff Internals, for more information.
as request is similar to ds but appends string
to the string stored as name instead of redefining it. If
name doesn't exist yet, it is created.
.as sign " with shallots, onions and garlic, |
The as1 request is similar to as, but compatibility mode
is switched off while the appended string is interpreted. To be more
precise, a compatibility save input token is inserted at the
beginning of the appended string, and a compatibility restore
input token at the end.
Rudimentary string manipulation routines are given with the next two requests.
.ds xxx abcdefgh
.substring xxx 1 -4
\*[xxx]
=> bcde
|
str is read in copy mode.
.ds xxx abcd\h'3i'efgh
.length yyy \n[xxx]
\n[yyy]
=> 14
|
gtroff
treats subsequent invocations as if the object had never been defined.
gtroff generates a warning of
type `mac' and ignores the request.
gtroff Internals, for details on
nodes inserted additionally by gtroff.
See section 5.5 Identifiers, and 5.6.3.1 Comments.
5.21.1 Operators in Conditionals 5.21.2 if-else 5.21.3 while
In if and while requests, there are several more
operators available:
e
o
n
.nroff command has been issued).
t
.troff command has been issued).
v
troff versions only.
'xxx'yyy'
\D escape is used (see section 5.6.3 Escapes).
gtroff formats the strings before being compared:
.ie "|"\fR|\fP" \
true
.el \
false
=> true
|
The resulting motions, glyph sizes, and fonts have to
match,@footnotegroff_123.html{The created output nodes must be identical.
See section 5.33 gtroff Internals. and not the individual motion, size, and
font requests. In the previous example, `|' and `\fR|\fP'
both result in a roman `|' glyph with the same point size and
at the same location on the page, so the strings are equal. If
`.ft I' had been added before the `.ie', the result
would be "false" because (the first) `|' produces an italic
`|' rather than a roman one.
r xxx
d xxx
m xxx
c g
Margin character is a misnomer since it is an output glyph. The first argument is the glyph to be printed. The second argument is the distance away from the right margin. If missing, the previously set value is used; default is 10pt). For text lines that are too long (that is, longer than the text length plus dist), the margin character is directly appended to the lines.
With no arguments the margin character is turned off. If this occurs before a break, no margin character is printed.
For empty lines and lines produced by the tl request no margin
character is emitted.
The margin character is associated with the current environment (see section 5.27 Environments).
This is quite useful for indicating text that has changed, and, in fact,
there are programs available for doing this (they are called
nrchbar and changebar and can be found in any
`comp.sources.unix' archive.
.ll 3i .mc | This paragraph is highlighted with a margin character. .sp Note that vertical space isn't marked. .br \& .br But we can fake it with `\&'. |
Result:
This paragraph is highlighted |
with a margin character. |
Note that vertical space isn't |
marked. |
|
But we can fake it with `\&'. |
|
%%BoundingBox comment
and extracts the bounding box values into the number registers
llx, lly, urx, and ury.
If an error occurs (for example, psbb cannot find
the %%BoundingBox comment),
it sets the four number registers to zero.
gtroff Internals
gtroff processes input in three steps. One or more input
characters are converted to an input token.@footnotegroff_144.html{Except the
escapes \f, \F, \H, \m, \M, \R,
\s, and \S which are processed immediately if not in
copy-in mode. Then, one or more input tokens are converted to an
output node. Finally, output nodes are converted to the
intermediate output language understood by all output devices.
Actually, before step one happens, gtroff converts certain
escape sequences into reserved input characters (not accessible by
the user); such reserved characters are used for other internal
processing also -- this is the very reason why not all characters
are valid input. See section 5.5 Identifiers, for more on this topic.
For example, the input string `fi\[:u]' is converted into a
character token `f', a character token `i', and a special
token `:u' (representing u umlaut). Later on, the character
tokens `f' and `i' are merged to a single output node
representing the ligature glyph `fi' (provided the current font
has a glyph for this ligature); the same happens with `:u'. All
output glyph nodes are `processed' which means that they are invariably
associated with a given font, font size, advance width, etc. During
the formatting process, gtroff itself adds various nodes to
control the data flow.
Macros, diversions, and strings collect elements in two chained lists: a list of input tokens which have been passed unprocessed, and a list of output nodes. Consider the following the diversion.
.di xxx a \!b c .br .di |
It contains these elements.
| node list | token list | element number |
| line start node | -- | 1 |
glyph node a | -- | 2 |
| word space node | -- | 3 |
| -- | b | 4 |
| -- | \n | 5 |
glyph node c | -- | 6 |
| vertical size node | -- | 7 |
| vertical size node | -- | 8 |
| -- | \n | 9 |
Elements 1, 7, and 8 are inserted by gtroff; the latter two
(which are always present) specify the vertical extent of the last
line, possibly modified by \x. The br request finishes
the current partial line, inserting a newline input token which is
subsequently converted to a space when the diversion is reread. Note
that the word space node has a fixed width which isn't stretchable
anymore. To convert horizontal space nodes back to input tokens, use
the unformat request.
Macros only contain elements in the token list (and the node list is empty); diversions and strings can contain elements in both lists.
Note that the chop request simply reduces the number of elements in a
macro, string, or diversion by one. Exceptions are compatibility save
and compatibility ignore input tokens which are ignored. The
substring request also ignores those input tokens.
Some requests like tr or cflags work on glyph
identifiers only; this means that the associated glyph can be changed
without destroying this association. This can be very helpful for
substituting glyphs. In the following example, we assume that
glyph `foo' isn't available by default, so we provide a
substitution using the fchar request and map it to input
character `x'.
.fchar \[foo] foo .tr x \[foo] |
Now let us assume that we install an additional special font `bar' which has glyph `foo'.
.special bar .rchar \[foo] |
Since glyphs defined with fchar are searched before glyphs
in special fonts, we must call rchar to remove the definition
of the fallback glyph. Anyway, the translation is still active;
`x' now maps to the real glyph `foo'.
gtroff is not easy to debug, but there are some useful features
and strategies for debugging.
gtroff shall use for
error and warning messages. line is the input line number of the
next line.
Without argument, the request is ignored.
This is a debugging aid for documents which are split into many files,
then put together with soelim and other preprocessors. Usually,
it isn't invoked manually.
string is read in copy mode.
The tm request ignores leading spaces of string; tm1
handles its argument similar to the ds request: a leading double
quote in string is stripped to allow initial blanks.
The tmc request is similar to tm1 but does
not append a newline (as is done in tm and tm1).
tm request, except that
it causes gtroff to stop processing. With no argument it
prints `User Abort.' to standard error.
ex request also causes gtroff to stop processing;
see also 5.30 I/O.
When doing something involved it is useful to leave the debugging statements in the code and have them turned on by a command line flag.
.if \n(DB .tm debugging output |
To activate these statements say
groff -rDB=1 file |
If it is known in advance that there will be many errors and no useful
output, gtroff can be forced to suppress formatted output with
the `-z' flag.
stderr. Names of all defined
macros, strings, and diversions are print together with their size in
bytes. Since gtroff sometimes adds nodes by itself, the
returned size can be larger than expected.
This request differs from UNIX troff: gtroff
reports the sizes of diversions, ignores an additional argument to
print only the total of the sizes, and the size isn't returned in
blocks of 128 characters.
stderr.
stderr.
Empty slots in the page trap list are printed as well, because they can
affect the priority of subsequently planted traps.
gtroff to flush its output immediately. The intent
is for interactive use, but this behaviour is currently not
implemented in gtroff. Contrary to UNIX troff,
TTY output is sent to a device driver also (grotty), making it
non-trivial to communicate interactively.
This request causes a line break.
Consider the following in file `test':
.de xxx . backtrace .. .de yyy . xxx .. . .yyy |
On execution, gtroff prints the following:
test:2: backtrace: macro `xxx' test:5: backtrace: macro `yyy' test:8: backtrace: file `test' |
The option `-b' of gtroff internally calls a variant of
this request on each error and warning.
slimit number register
to set the maximum number of objects on the input stack.
If slimit is less than or equal to 0,
there is no limit set.
With no limit, a buggy recursive macro can exhaust virtual memory.
The default value is 1000; this is a compile-time constant.
gtroff emit a warning if the additional space inserted for
each space between words in an output line is larger or equal to
limit. A negative value is changed to zero; no argument toggles the
warning on and off without changing limit. The default scaling
indicator is `m'. At startup, spreadwarn is deactivated, and
limit is set to 3m.
For example,
.spreadwarn 0.2m |
will cause a warning if gtroff must add 0.2m or more for each
interword space in a line.
This request is active only if text is justified to both margins (using `.ad b').
gtroff has command line options for printing out more warnings
(`-w') and for printing backtraces (`-b') when a warning
or an error occurs. The most verbose level of warnings is `-ww'.
.warn 0 disables all warnings,
and .warn 1 disables all warnings except that about missing
glyphs. If no argument is given, all warnings are enabled.
The read-only number register .warn contains the current warning
level.
5.34.1 Warnings
The warnings that can be given to gtroff are divided into the
following categories. The name associated with each warning is used by
the `-w' and `-W' options; the number is used by the
warn request and by the .warn register.
char is a misnomer since it reports
missing glyphs -- there aren't missing input characters, only invalid
ones. This is enabled by default.
el request with no matching ie request.
See section 5.21.2 if-else.
di or da without an argument when there is no
current diversion.
\} where a number was expected.
\X is encountered, the escape character is ignored, and
X is printed.
ig request. These are
conditions that are errors when they do not occur in ignored text.
GNU troff has a number of features which cause incompatibilities
with documents written with old versions of troff.
Long names cause some incompatibilities. UNIX troff
interprets
.dsabcd |
as defining a string `ab' with contents `cd'. Normally, GNU
troff interprets this as a call of a macro named
dsabcd. Also UNIX troff interprets
\*[ or \n[ as references to a string or number register
called `['. In GNU troff, however, this is normally
interpreted as the start of a long name. In compatibility mode GNU
troff interprets long names in the traditional way
(which means that they are not recognized as names).
The read-only number register .C is 1 if compatibility mode is
on, 0 otherwise.
Compatibility mode can be also turned on with the `-C' command line option.
The do request turns off compatibility mode
while executing its arguments as a gtroff command.
.do fam T |
executes the fam request when compatibility mode
is enabled.
gtroff restores the previous compatibility setting
before interpreting any files sourced by the cmd.
Two other features are controlled by `-C'. If not in
compatibility mode, GNU troff preserves the input level in
delimited arguments:
.ds xx ' \w'abc\*(xxdef' |
In compatibility mode, the string `72def'' is returned; without `-C' the resulting string is `168' (assuming a TTY output device).
Finally, the escapes \f, \H, \m, \M,
\R, \s, and \S are transparent for recognizing the
beginning of a line only in compatibility mode (this is a rather obscure
feature). For example, the code
.de xx Hallo! .. \fB.xx\fP |
prints `Hallo!' in bold face if in compatibility mode, and `.xx' in bold face otherwise.
GNU troff does not allow the use of the escape sequences
\|, \^, \&, \{, \},
\SP, \', \`, \-, \_, \!,
\%, and \c in names of strings, macros, diversions, number
registers, fonts or environments; UNIX troff does. The
\A escape sequence (see section 5.5 Identifiers) may be helpful in
avoiding use of these escape sequences in names.
Fractional point sizes cause one noteworthy incompatibility. In
UNIX troff the ps request ignores scale
indicators and thus
.ps 10u |
sets the point size to 10 points, whereas in GNU troff it
sets the point size to 10 scaled points. See section 5.19.2 Fractional Type Sizes, for more information.
In GNU troff there is a fundamental difference between
(unformatted) input characters and (formatted) output glyphs.
Everything that affects how a glyph is output is stored
with the glyph node; once a glyph node has been constructed it is
unaffected by any subsequent requests that are executed, including
bd, cs, tkf, tr, or fp requests.
Normally glyphs are constructed from input characters at the
moment immediately before the glyph is added to the current output
line. Macros, diversions and strings are all, in fact, the same type of
object; they contain lists of input characters and glyph nodes in
any combination. A glyph node does not behave like an input
character for the purposes of macro processing; it does not inherit any
of the special properties that the input character from which it was
constructed might have had. For example,
.di x \\\\ .br .di .x |
prints `\\' in GNU troff; each pair of input backslashes
is turned into one output backslash and the resulting output backslashes
are not interpreted as escape characters when they are reread.
UNIX troff would interpret them as escape characters
when they were reread and would end up printing one `\'. The
correct way to obtain a printable backslash is to use the \e
escape sequence: This always prints a single instance of the current
escape character, regardless of whether or not it is used in a
diversion; it also works in both GNU troff and UNIX
troff.@footnotegroff_147.html{To be completely independent of the current
escape character, use \(rs which represents a reverse solidus
(backslash) glyph. To store, for some reason, an escape sequence in a
diversion that will be interpreted when the diversion is reread, either
use the traditional \! transparent output facility, or, if this
is unsuitable, the new \? escape sequence.
See section 5.26 Diversions, and 5.33 gtroff Internals, for more information.
This chapter describes all preprocessors that come with groff or
which are freely available.
6.1 geqn6.2 gtbl6.3 gpic6.4 ggrn6.5 grap6.6 grefer6.7 gsoelim
geqn
6.1.1 Invoking geqn
geqn gtbl
6.2.1 Invoking gtbl
gtbl gpic
6.3.1 Invoking gpic
gpic ggrn
6.4.1 Invoking ggrn
ggrn grap
A free implementation of grap, written by Ted Faber,
is available as an extra package from the following address:
http://www.lunabase.org/~faber/Vault/software/grap/ |
grefer
6.6.1 Invoking grefer
grefer gsoelim
6.7.1 Invoking gsoelim
gsoelim
7.1 Special Characters 7.2 grotty7.3 grops7.4 grodvi7.5 grolj47.6 grolbp7.7 grohtml7.8 gxditview
See section 8.2 Font Files.
grotty
7.2.1 Invoking grotty
grotty grops
7.3.1 Invoking grops7.3.2 Embedding POSTSCRIPT
grops grodvi
7.4.1 Invoking grodvi
grodvi grolj4
7.5.1 Invoking grolj4
grolj4 grolbp
7.6.1 Invoking grolbp
grolbp grohtml
7.7.1 Invoking grohtml7.7.2 grohtmlspecific registers and strings
grohtml grohtml specific registers and strings ps4html and www-image-template are defined
by the pre-grohtml preprocessor. pre-grohtml reads in
the troff input, marks up the inline equations and passes the
result firstly to
troff -Tps -rps4html=1 -dwww-image-template=template |
and secondly to
troff -Thtml |
The PostScript device is used to create all the image files, and the
register ps4html enables the macro sets to ignore floating
keeps, footers, and headings.
The register www-image-template is set to the user specified
template name or the default name.
gxditview
7.8.1 Invoking gxditview
gxditview
All files read and written by gtroff are text files. The
following two sections describe their format.
8.1 gtroffOutput8.2 Font Files
gtroff Output
This section describes the intermediate output format of GNU
troff. This output is produced by a run of gtroff
before it is fed into a device postprocessor program.
As groff is a wrapper program around gtroff that
automatically calls a postprocessor, this output does not show up
normally. This is why it is called intermediate.
groff provides the option `-Z' to inhibit postprocessing,
such that the produced intermediate output is sent to standard output
just like calling gtroff manually.
Here, the term troff output describes what is output by
gtroff, while intermediate output refers to the language
that is accepted by the parser that prepares this output for the
postprocessors. This parser is smarter on whitespace and implements
obsolete elements for compatibility, otherwise both formats are the
same.@footnotegroff_181.html{The parser and postprocessor for intermediate output
can be found in the file
`groff-source-dir/src/libs/libdriver/input.cc'.
The main purpose of the intermediate output concept is to facilitate
the development of postprocessors by providing a common programming
interface for all devices. It has a language of its own that is
completely different from the gtroff language. While the
gtroff language is a high-level programming language for text
processing, the intermediate output language is a kind of low-level
assembler language by specifying all positions on the page for writing
and drawing.
The intermediate output produced by gtroff is fairly readable,
while output from AT&T troff is rather hard to
understand because of strange habits that are still supported, but not
used any longer by gtroff.
8.1.1 Language Concepts 8.1.2 Command Reference 8.1.3 Intermediate Output Examples 8.1.4 Output Language Compatibility
During the run of gtroff, the input data is cracked down to the
information on what has to be printed at what position on the intended
device. So the language of the intermediate output format can be quite
small. Its only elements are commands with and without arguments.
In this section, the term command always refers to the intermediate
output language, and never to the gtroff language used for document
formatting. There are commands for positioning and text writing, for drawing, and
for device controlling.
8.1.1.1 Separation 8.1.1.2 Argument Units 8.1.1.3 Document Parts
AT&T troff output has strange requirements on whitespace.
The gtroff output parser, however, is smart about whitespace by
making it maximally optional. The whitespace characters, i.e., the
tab, space, and newline characters, always have a syntactical meaning.
They are never printable because spacing within the output is always
done by positioning commands.
Any sequence of space or tab characters is treated as a single syntactical space. It separates commands and arguments, but is only required when there would occur a clashing between the command code and the arguments without the space. Most often, this happens when variable-length command names, arguments, argument lists, or command clusters meet. Commands and arguments with a known, fixed length need not be separated by syntactical space.
A line break is a syntactical element, too. Every command argument can be followed by whitespace, a comment, or a newline character. Thus a syntactical line break is defined to consist of optional syntactical space that is optionally followed by a comment, and a newline character.
The normal commands, those for positioning and text, consist of a
single letter taking a fixed number of arguments. For historical reasons,
the parser allows to stack such commands on the same line, but
fortunately, in gtroff's intermediate output, every command with
at least one argument is followed by a line break, thus providing
excellent readability.
The other commands -- those for drawing and device controlling -- have a more complicated structure; some recognize long command names, and some take a variable number of arguments. So all `D' and `x' commands were designed to request a syntactical line break after their last argument. Only one command, `x X', has an argument that can stretch over several lines; all other commands must have all of their arguments on the same line as the command, i.e., the arguments may not be splitted by a line break.
Empty lines (these are lines containing only space and/or a comment), can occur everywhere. They are just ignored.
Some commands take integer arguments that are assumed to represent values in a measurement unit, but the letter for the corresponding scale indicator is not written with the output command arguments. Most commands assume the scale indicator `u', the basic unit of the device, some use `z', the scaled point unit of the device, while others, such as the color commands, expect plain integers.
Note that single characters can have the eighth bit set, as can the names of fonts and special characters. The names of characters and fonts can be of arbitrary length. A character that is to be printed will always be in the current font.
A string argument is always terminated by the next whitespace character (space, tab, or newline); an embedded `#' character is regarded as part of the argument, not as the beginning of a comment command. An integer argument is already terminated by the next non-digit character, which then is regarded as the first character of the next argument or command.
A correct intermediate output document consists of two parts, the prologue and the body.
The task of the prologue is to set the general device parameters
using three exactly specified commands. gtroff's prologue
is guaranteed to consist of the following three lines (in that order):
x T device x res n h v x init |
with the arguments set as outlined in 8.1.2.4 Device Control Commands. Note that the parser for the intermediate output format is able to swallow additional whitespace and comments as well even in the prologue.
The body is the main section for processing the document data.
Syntactically, it is a sequence of any commands different from the
ones used in the prologue. Processing is terminated as soon as the
first `x stop' command is encountered; the last line of any
gtroff intermediate output always contains such a command.
Semantically, the body is page oriented. A new page is started by a `p' command. Positioning, writing, and drawing commands are always done within the current page, so they cannot occur before the first `p' command. Absolute positioning (by the `H' and `V' commands) is done relative to the current page; all other positioning is done relative to the current location within this page.
This section describes all intermediate output commands, both from
AT&T troff as well as the gtroff extensions.
8.1.2.1 Comment Command 8.1.2.2 Simple Commands 8.1.2.3 Graphics Commands 8.1.2.4 Device Control Commands 8.1.2.5 Obsolete Command
#anything<end of line>
This command is the only possibility for commenting in the intermediate output. Each comment can be preceded by arbitrary syntactical space; every command can be terminated by a comment.
The commands in this subsection have a command code consisting of a single character, taking a fixed number of arguments. Most of them are commands for positioning and text writing. These commands are smart about whitespace. Optionally, syntactical space can be inserted before, after, and between the command letter and its arguments. All of these commands are stackable, i.e., they can be preceded by other simple commands or followed by arbitrary other commands on the same line. A separating syntactical space is only necessary when two integer arguments would clash or if the preceding argument ends with a string argument.
C xxx<whitespace>
c g
f n
H n
h n
gtroff doesn't use this.
m color-scheme [component ...]
gtroff's escape sequence \m. No position changing.
These commands are a gtroff extension.
mc cyan magenta yellow
md
mg gray
mk cyan magenta yellow black
mr red green blue
N n
gtroff extension.
n b a
troff, the integer arguments
b and a informed about the space before and after the
current line to make the intermediate output more human readable
without performing any action. In groff, they are just ignored, but
they must be provided for compatibility reasons.
p n
s n
troff used the unit points (`p') instead.
See section 8.1.4 Output Language Compatibility.
t xxx<whitespace>
t xxx dummy-arg<whitespace>
gtroff extension; it is only used for devices whose `DESC'
file contains the tcommand keyword (see section 8.2.1 `DESC' File Format).
u n xxx<whitespace>
gtroff extension; it is only used for devices
whose `DESC' file contains the tcommand keyword
(see section 8.2.1 `DESC' File Format).
V n
v n
gtroff doesn't use this.
w
Each graphics or drawing command in the intermediate output starts with the letter `D', followed by one or two characters that specify a subcommand; this is followed by a fixed or variable number of integer arguments that are separated by a single space character. A `D' command may not be followed by another command on the same line (apart from a comment), so each `D' command is terminated by a syntactical line break.
gtroff output follows the classical spacing rules (no space
between command and subcommand, all arguments are preceded by a
single space character), but the parser allows optional space between
the command letters and makes the space before the first argument
optional. As usual, each space can be any sequence of tab and space
characters.
Some graphics commands can take a variable number of arguments. In this case, they are integers representing a size measured in basic units `u'. The arguments called h1, h2, ..., hn stand for horizontal distances where positive means right, negative left. The arguments called v1, v2, ..., vn stand for vertical distances where positive means down, negative up. All these distances are offsets relative to the current location.
Unless indicated otherwise, each graphics command directly corresponds
to a similar gtroff \D escape sequence. See section 5.24 Drawing Requests.
Unknown `D' commands are assumed to be device-specific. Its arguments are parsed as strings; the whole information is then sent to the postprocessor.
In the following command reference, the syntax element <line break> means a syntactical line break as defined above.
D~ h1 v1 h2 v2 ... hn vn<line break>
Da h1 v1 h2 v2<line break>
DC d<line break>
DC d dummy-arg<line break>
gtroff extension.
Dc d<line break>
DE h v<line break>
gtroff extension.
De h v<line break>
DF color-scheme [component ...]<line break>
gtroff's
escape sequences \D'F ...' and \M (with no other
corresponding graphics commands). No position changing. This command
is a gtroff extension.
DFc cyan magenta yellow<line break>
DFd<line break>
DFg gray<line break>
DFk cyan magenta yellow black<line break>
DFr red green blue<line break>
Df n<line break>
mg 0 0 65536 Df -1 |
sets all colors to blue.
No position changing. This command is a gtroff extension.
Dl h v<line break>
Dp h1 v1 h2 v2 ... hn vn<line break>
gtroff extension.
Dp h1 v1 h2 v2 ... hn vn<line break>
gtroff extension.
Dt n<line break>
gtroff extension.
Each device control command starts with the letter `x',
followed by a space character (optional or arbitrary space or tab in
gtroff) and a subcommand letter or word; each argument (if any)
must be preceded by a syntactical space. All `x' commands are
terminated by a syntactical line break; no device control command can
be followed by another command on the same line (except a comment).
The subcommand is basically a single letter, but to increase
readability, it can be written as a word, i.e., an arbitrary sequence
of characters terminated by the next tab, space, or newline character.
All characters of the subcommand word but the first are simply ignored.
For example, gtroff outputs the initialization command
`x i' as `x init' and the resolution command
`x r' as `x res'.
In the following, the syntax element <line break> means a syntactical line break (see section 8.1.1.1 Separation).
xF name<line break>
Use name as the intended name for the current file in error
reports. This is useful for remembering the original file name when
gtroff uses an internal piping mechanism. The input file is
not changed by this command. This command is a gtroff extension.
xf n s<line break>
Mount font position n (a non-negative integer) with font named s (a text word). See section 5.18.3 Font Positions.
xH n<line break>
Set glyph height to n (a positive integer in scaled
points `z'). AT&T troff uses the unit points
(`p') instead. See section 8.1.4 Output Language Compatibility.
xi<line break>
Initialize device. This is the third command of the prologue.
xp<line break>
Parsed but ignored. The original UNIX troff manual writes
pause device, can be restarted |
xr n h v<line break>
Resolution is n, while h is the minimal horizontal motion, and v the minimal vertical motion possible with this device; all arguments are positive integers in basic units `u' per inch. This is the second command of the prologue.
xS n<line break>
Set slant to n (an integer in basic units `u').
xs<line break>
Terminates the processing of the current file; issued as the last command of any intermediate troff output.
xt<line break>
Generate trailer information, if any. In gtroff, this is actually just ignored.
xT xxx<line break>
Set name of device to word xxx, a sequence of characters ended
by the next white space character. The possible device names coincide
with those from the groff `-T' option. This is the first
command of the prologue.
xu n<line break>
Configure underlining of spaces. If n is 1, start
underlining of spaces; if n is 0, stop underlining of spaces.
This is needed for the cu request in nroff mode and is ignored
otherwise. This command is a gtroff extension.
xX anything<line break>
Send string anything uninterpreted to the device. If the line
following this command starts with a `+' character this line is
interpreted as a continuation line in the following sense. The
`+' is ignored, but a newline character is sent instead to the
device, the rest of the line is sent uninterpreted. The same applies
to all following lines until the first character of a line is not a
`+' character. This command is generated by the gtroff
escape sequence \X. The line-continuing feature is a
gtroff extension.
troff output, the writing of a single
glyph is mostly done by a very strange command that combines a
horizontal move and a single character giving the glyph name. It
doesn't have a command code, but is represented by a 3-character
argument consisting of exactly 2 digits and a character.
In gtroff, arbitrary syntactical space around and within this
command is allowed to be added. Only when a preceding command on the
same line ends with an argument of variable length a separating space
is obligatory. In AT&T troff, large clusters of these
and other commands are used, mostly without spaces; this made such output
almost unreadable.
For modern high-resolution devices, this command does not make sense
because the width of the glyphs can become much larger than two
decimal digits. In gtroff, this is only used for the devices
X75, X75-12, X100, and X100-12. For other
devices, the commands `t' and `u' provide a better
functionality.
This section presents the intermediate output generated from the same
input for three different devices. The input is the sentence
`hell world' fed into gtroff on the command line.
ps
This is the standard output of gtroff if no `-T' option
is given.
shell> echo "hell world" | groff -Z -T ps x T ps x res 72000 1 1 x init p1 x font 5 TR f5 s10000 V12000 H72000 thell wh2500 tw H96620 torld n12000 0 x trailer V792000 x stop |
This output can be fed into grops to get its representation as
a PostScript file.
latin1
This is similar to the high-resolution device except that the positioning is done at a minor scale. Some comments (lines starting with `#') were added for clarification; they were not generated by the formatter.
shell> echo "hell world" | groff -Z -T latin1 # prologue x T latin1 x res 240 24 40 x init # begin a new page p1 # font setup x font 1 R f1 s10 # initial positioning on the page V40 H0 # write text `hell' thell # inform about space, and issue a horizontal jump wh24 # write text `world' tworld # announce line break, but do nothing because ... n40 0 # ... the end of the document has been reached x trailer V2640 x stop |
This output can be fed into grotty to get a formatted text
document.
troff output
shell> echo "hell world" | groff -Z -T X100 x T X100 x res 100 1 1 x init p1 x font 5 TR f5 s10 V16 H100 # write text with jump-and-write commands ch07e07l03lw06w11o07r05l03dh7 n16 0 x trailer V1100 x stop |
This output can be fed into xditview or gxditview
for displaying in X.
Due to the obsolete jump-and-write command, the text clusters in the
AT&T troff output are almost unreadable.
The intermediate output language of AT&T troff
was first documented in the UNIX troff manual, with later
additions documented in A Typesetter-indenpendent TROFF,
written by Brian Kernighan.
The gtroff intermediate output format is compatible with this
specification except for the following features.
groff devices are also fundamentally different from the ones in
AT&T troff. For example, the AT&T
PostScript device is called post and has a resolution of only
720 units per inch, suitable for printers 20 years ago, while
groff's ps device has a resolution of
72000 units per inch. Maybe, by implementing some rescaling
mechanism similar to the classical quasi device independence,
groff could emulate AT&T's post device.
gtroff, while
AT&T troff has point (`p'). This isn't an
incompatibility but a compatible extension, for both units coincide
for all devices without a sizescale parameter in the `DESC'
file, including all postprocessors from AT&T and
groff's text devices. The few groff devices with
a sizescale parameter either do not exist for AT&T
troff, have a different name, or seem to have a different
resolution. So conflicts are very unlikely.
gtroff used this
feature it is kept for compatibility reasons.
The gtroff font format is roughly a superset of the
ditroff font format (as used in later versions of AT&T
troff and its descendants). Unlike the ditroff font
format, there is no associated binary format; all files are text
files.@footnotegroff_194.html{Plan 9 troff has also abandoned the binary
format. The font files for device name are stored in a directory
`devname'. There are two types of file: a device description
file called `DESC' and for each font f a font file
called `f'.
8.2.1 `DESC' File Format 8.2.2 Font File Format
The `DESC' file can contain the following types of line. Except
for the charset keyword which must comes last (if at all), the
order of the lines is not important.
res n
hor n
vert n
sizescale n
unitwidth and sizes commands are given in scaled points.
See section 5.19.2 Fractional Type Sizes, for more information.
unitwidth n
prepro program
groff with option `-Thtml' only.
postpro program
postpro grodvi |
in the file `devdvi/DESC' makes groff call grodvi
if option `-Tdvi' is given (and `-Z' isn't used).
tcommand
sizes s1 s2 ... sn 0
styles S1 S2 ... Sm
fonts n F1 F2 F3 ... Fn
family fam
use_charnames_in_special
gtroff should encode special
characters inside special commands. Currently, this is only used
by the HTML output device. See section 5.31 Postprocessor Access.
papersize string ...
A0-A7, B0-B7, C0-C7,
D0-D7, DL, and the US paper types letter,
legal, tabloid, ledger, statement,
executive, com10, and monarch. Case is not significant
for string if it holds predefined paper types. Alternatively,
string can be a file name (e.g. `/etc/papersize'); if the file
can be opened, groff reads the first line and tests for the above
paper sizes. Finally, string can be a custom paper size in the format
length,width (no spaces before and after the comma).
Both length and width must have a unit appended; valid values
are `i' for inches, `C' for centimeters, `p' for points, and
`P' for picas. Example: 12c,235p. An argument which starts
with a digit is always treated as a custom paper format. papersize
sets both the vertical and horizontal dimension of the output medium.
More than one argument can be specified; groff scans from left to
right and uses the first valid paper specification.
pass_filenames
gtroff to emit the name of the source file currently
being processed. This is achieved by the intermediate output command
`F'. Currently, this is only used by the HTML output
device.
print program
groff are ignored.
charset
The res, unitwidth, fonts, and sizes lines
are mandatory. Other commands are ignored by gtroff but may be
used by postprocessors to store arbitrary information about the device
in the `DESC' file.
Here a list of obsolete keywords which are recognized by groff
but completely ignored: spare1, spare2,
biggestfont.
A font file, also (and probably better) called a font description file, has two sections. The first section is a sequence of lines each containing a sequence of blank delimited words; the first word in the line is a key, and subsequent words give a value for that key.
name f
spacewidth n
slant n
ligatures lig1 lig2 ... lign [0]
special
Other commands are ignored by gtroff but may be used by
postprocessors to store arbitrary information about the font in the font
file.
The first section can contain comments which start with the `#' character and extend to the end of a line.
The second section contains one or two subsections. It must contain a
charset subsection and it may also contain a kernpairs
subsection. These subsections can appear in any order. Each
subsection starts with a word on a line by itself.
The word charset starts the character set
subsection.@footnotegroff_196.html{This keyword is misnamed since it starts a list
of ordered glyphs, not characters. The charset line is
followed by a sequence of lines. Each line gives information for one
glyph. A line comprises a number of fields separated by blanks or
tabs. The format is
name metrics type code
[entity-name] [-- comment]
name identifies the glyph name@footnotegroff_196.html{The distinction between
input, characters, and output, glyphs, is not clearly separated in the
terminology of groff; for example, the char request
should be called glyph since it defines an output entity.:
If name is a single character c then it corresponds
to the gtroff input character c; if it is of the form
`\c' where c is a single character, then it
corresponds to the special character \[c]; otherwise it
corresponds to the special character `\[name]'. If it
is exactly two characters xx it can be entered as
`\(xx'. Note that single-letter special characters can't
be accessed as `\c'; the only exception is `\-' which
is identical to \[-].
gtroff supports 8-bit input characters; however some utilities
have difficulties with eight-bit characters. For this reason, there is
a convention that the entity name `charn' is equivalent to
the single input character whose code is n. For example,
`char163' would be equivalent to the character with code 163
which is the pounds sterling sign in the ISO Latin-1 character set.
You shouldn't use `charn' entities in font description files
since they are related to input, not output. Otherwise, you get
hard-coded connections between input and output encoding which
prevents use of different (input) character sets.
The name `---' is special and indicates that the glyph is
unnamed; such glyphs can only be used by means of the \N
escape sequence in gtroff.
The type field gives the glyph type:
1
2
3
The code field gives the code which the postprocessor uses to
print the glyph. The glyph can also be input to gtroff
using this code by means of the \N escape sequence. code
can be any integer. If it starts with `0' it is interpreted as
octal; if it starts with `0x' or `0X' it is interpreted as
hexadecimal. Note, however, that the \N escape sequence only
accepts a decimal integer.
The entity-name field gives an ASCII string
identifying the glyph which the postprocessor uses to print the
gtroff glyph name. This field is optional and has been
introduced so that the HTML device driver can encode its
character set. For example, the glyph `\[Po]' is
represented as `£' in HTML 4.0.
Anything on the line after the entity-name field resp. after `--' will be ignored.
The metrics field has the form:
width[ |
There must not be any spaces between these subfields (it has been split
here into two lines for better legibility only). Missing subfields are
assumed to be 0. The subfields are all decimal integers. Since
there is no associated binary format, these values are not required to
fit into a variable of type `char' as they are in ditroff.
The width subfield gives the width of the glyph. The height
subfield gives the height of the glyph (upwards is positive); if a
glyph does not extend above the baseline, it should be given a zero
height, rather than a negative height. The depth subfield gives
the depth of the glyph, that is, the distance from the baseline to the
lowest point below the baseline to which the glyph extends (downwards is
positive); if a glyph does not extend below the baseline, it should be
given a zero depth, rather than a negative depth. The
italic-correction subfield gives the amount of space that should
be added after the glyph when it is immediately to be followed by a
glyph from a roman font. The left-italic-correction subfield
gives the amount of space that should be added before the glyph when it
is immediately to be preceded by a glyph from a roman font. The
subscript-correction gives the amount of space that should be
added after a glyph before adding a subscript. This should be less
than the italic correction.
A line in the charset section can also have the format
name " |
This indicates that name is just another name for the glyph mentioned in the preceding line.
The word kernpairs starts the kernpairs section. This contains a
sequence of lines of the form:
c1 c2 n |
This means that when glyph c1 appears next to glyph c2 the space between them should be increased by n. Most entries in the kernpairs section have a negative value for n.
A.1 GNU Free Documentation License License for copying this manual.
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. |
The purpose of this License is to make a manual, textbook, or other written document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgments", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being list their titles, with the Front-Cover Texts being list, and with the Back-Cover Texts being list. A copy of the license is included in the section entitled ``GNU Free Documentation License''. |
If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being list"; likewise for Back-Cover Texts.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
Requests appear without the leading control character (normally either `.' or `'').
| Jump to: | A B C D E F H I K L M N O P R S T U V W |
|---|