groff: Font File Format

 
 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.
 
 Font File Format-Footnote-1::) 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(2) (⇒Font File Format-Footnote-2):
 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 that 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
 that 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.