[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
8.1 gtroff
Output8.2 Font Files
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
gtroff
Output
This section describes the format output of GNU troff
. The
output format used by GNU troff
is very similar to that used by
UNIX device-independent troff
(ditroff
).
8.1.1 Output Format 8.1.2 Device Control 8.1.3 Drawing Functions 8.1.4 Line Continuation
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The output format is text based, as opposed to a binary format (like TeX DVI). The output format is 8-bit clean, thus single characters can have the eighth bit set, as can the names of fonts and special characters.
The output format consists of single command characters with attached parameters which are separated from subsequent text by whitespace or a newline.
The names of characters and fonts can be of arbitrary length; drivers
should not assume that they will be only two characters long (as
ditroff
does).
When a character is to be printed, that character will always be in the
current font. Unlike ditroff
, it is not necessary for drivers to
search special fonts to find a character.
Hn
Vn
hn
vn
cn
Cn
nnc
txxx
This command is only allowed if the `tcommand' line is present in the `DESC' file.
un xxx
This command is only allowed if the `tcommand' line is present in the `DESC' file.
nab
pn
sn
fn
x ... \n
Dc x...\n
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `x' command is normally followed by a letter or word indicating the function to perform, followed by white space separated arguments.
The first argument can be abbreviated to the first letter.
x init
x T
x res n h v
x H
The first three output commands are guaranteed to be:
x T device x res n h v x init |
For example, the input
crunchy \fH\s+2frog\s0\fP!? |
will produce
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `D' drawing command has been extended. These extensions will
only be used by GNU pic
if the `-x' option is given.
See section 5.23 Drawing Requests.
Df n
DC d
DE dx dy
Dp dx1 dy1 dx2 dy2 ... dxn dyn
pic
only uses this command to generate triangles and rectangles.
DP dx1 dy1 dx2 dy2 ... dxn dyn
Dp
but draw a solid rather than outlined polygon.
Dt n
troff
drivers use a line thickness
proportional to the current point size; drivers should continue to do
this if no Dt
command has been given, or if a Dt
command
has been given with a negative value of n. A zero value of
n selects the smallest available line thickness.
A difficulty arises in how the current position should be changed after
the execution of these commands. This is not of great importance since
the code generated by GNU pic
does not depend on this. Given a
drawing command of the form
\D'c x1 y1 x2 y2 ... xn yn' |
where c is not one of `c', `e', `l', `a' or
`~', UNIX troff
will treat each of the x value
as a horizontal quantity, and each of the y values as a vertical
quantity and will assume that the width of the drawn object is sum if
all x values, and that the height is the sum of all y values.
(The assumption about the height can be seen by examining the st
and sb
registers after using such a D
command in a
\w
escape sequence.) This rule also holds for all the original
drawing commands with the exception of De
. For the sake of
compatibility GNU troff
also follows this rule, even though it
produces an ugly result in the case of the Df
, Dt
, and, to
a lesser extent, DE
commands. Thus after executing a
D
command of the form
Dc x1 y1 x2 y2 ... xn yn |
the current position should be increased horizontally by the sum of all x values and vertically by the sum of all y values.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There is a continuation convention which permits the argument to the
`x X' command to contain newlines: When outputting the argument
to the `x X' command, GNU troff
will follow each newline
in the argument with a `+' character (as usual, it will terminate
the entire argument with a newline); thus if the line after the line
containing the `x X' command starts with `+', then the
newline ending the line containing the `x X' command should be
treated as part of the argument to the `x X' command, the
`+' should be ignored, and the part of the line following the
`+' should be treated like the part of the line following the
`x X' command.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The gtroff
font format is roughly a superset of the
ditroff
font format. Unlike the ditroff
font format,
there is no associated binary format; all files are text files. 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
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `DESC' file can contain the following types of line:
res n
hor n
vert n
sizescale n
unitwidth
and sizes
commands are given in scaled points.
See section 5.18.2 Fractional Type Sizes, for more information.
unitwidth n
tcommand
sizes s1 s2 ... sn 0
styles S1 S2 ... Sm
fonts n F1 F2 F3 ... Fn
family fam
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A font 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. The
charset
line is followed by a sequence of lines. Each line gives
information for one character. A line comprises a number of fields
separated by blanks or tabs. The format is
name metrics type code comment |
name identifies the character: 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 gtroff
input
character \c; otherwise it corresponds to the groff input
character `\[name]'. (If it is exactly two characters
xx it can be entered as `\(xx'.) gtroff
supports 8-bit characters; however some utilities have difficulties with
eight-bit characters. For this reason, there is a convention that the
name `charn' is equivalent to the single character whose code
is n. For example, `char163' would be equivalent to the
character with code 163 which is the pounds sterling sign in ISO
Latin-1 character set. The name `---' is special and indicates
that the character is unnamed; such characters can only be used by means
of the \N
escape sequence in gtroff
.
The type field gives the character type:
1
2
3
The code field gives the code which the postprocessor uses to
print the character. The character can also be input to gtroff
using this code by means of the \N
escape sequence. The code can
be any integer. If it starts with `0' it will be interpreted as
octal; if it starts with `0x' or `0X' it will be interpreted as
hexadecimal.
Anything on the line after the code field will be ignored.
The metrics field has the form:
width[,height[,depth[,italic_correction [,left_italic_correction[,subscript_correction]]]]] |
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 character. The
height subfield gives the height of the character (upwards is
positive); if a character 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 character, that is, the distance below
the lowest point below the baseline to which the character extends
(downwards is positive); if a character does not extend below above 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 character when it is immediately to be
followed by a character from a Roman font. The
left_italic_correction subfield gives the amount of space that
should be added before the character when it is immediately to be
preceded by a character from a Roman font. The
subscript_correction gives the amount of space that should be
added after a character 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 character 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 character c1 appears next to character c2 the space between them should be increased by n. Most entries in kernpairs section will have a negative value for n.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |