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.
Other commands are ignored by
gtroff but may be used by
postprocessors to store arbitrary information about the font in the font
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
subsection. These subsections can appear in any order. Each subsection
starts with a word on a line by itself.
charset starts the character set
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] [
name identifies the glyph name2: 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
]; 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
The type field gives the glyph type:
The code field gives the code which the postprocessor uses to
print the glyph. The glyph can also be input to
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
The entity-name field gives an ASCII string identifying
the glyph which the postprocessor uses to print the
name. This field is optional and has been introduced so that the
grohtml device driver can encode its character set. For example,
the glyph ‘\[Po]’ is represented as ‘£’ in
Anything on the line after the entity-name field resp. after ‘--’ is ignored.
The metrics field has the form:
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
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
This indicates that name is just another name for the glyph mentioned in the preceding line.
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.
 This keyword is misnamed since it starts a list of ordered glyphs, not characters.
 The distinction between
input, characters, and output, glyphs, is not clearly separated in the
groff; for example, the
char request should
glyph since it defines an output entity.