8.2.2 Font File Format

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

The name of the font is f.

spacewidth n

The normal width of a space is n.

slant n

The glyphs of the font have a slant of n degrees. (Positive means forward.)

ligatures lig1 lig2 ... lign [0]

Glyphs lig1, lig2, ..., lign are ligatures; possible ligatures are ‘ff’, ‘fi’, ‘fl’, ‘ffi’ and ‘ffl’. For backwards compatibility, the list of ligatures may be terminated with a 0. The list of ligatures may not extend over more than one line.

special

The font is special; this means that when a glyph is requested that is not present in the current font, it is searched for in any special fonts that are mounted.

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 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²: 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

the glyph has a descender, for example, ‘p’;

2

the glyph has an ascender, for example, ‘b’;

3

the glyph has both an ascender and a descender, for example, ‘(’.

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 grohtml 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 ‘--’ is 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 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.