grub-dev: File Structure

 
 11.2 File Structure
 ===================
 
 A file *section* consists of a 4-byte name, a 32-bit big-endian length
 (not including the name or length), and then LENGTH more
 section-type-specific bytes.
 
    The standard file extension for PFF2 font files is '.pf2'.
 
 11.2.1 Section Types
 --------------------
 
 'FILE'
      *File type ID* (ASCII string).  This must be the first section in
      the file.  It has length 4 and the contents are the four bytes of
      the ASCII string 'PFF2'.
 
 'NAME'
      *Font name* (ASCII string).  This is the full font name including
      family, weight, style, and point size.  For instance, "Helvetica
      Bold Italic 14".
 
 'FAMI'
      *Font family name* (ASCII string).  For instance, "Helvetica".
      This should be included so that intelligent font substitution can
      take place.
 
 'WEIG'
      *Font weight* (ASCII string).  Valid values are 'bold' and
      'normal'.  This should be included so that intelligent font
      substitution can take place.
 
 'SLAN'
      *Font slant* (ASCII string).  Valid values are 'italic' and
      'normal'.  This should be included so that intelligent font
      substitution can take place.
 
 'PTSZ'
      *Font point size* (uint16be).
 
 'MAXW'
      *Maximum character width in pixels* (uint16be).
 
 'MAXH'
      *Maximum character height in pixels* (uint16be).
 
 'ASCE'
      *Ascent in pixels* (uint16be).  ⇒Font Metrics, for details.
 
 'DESC'
      *Descent in pixels* (uint16be).  ⇒Font Metrics, for details.
 
 'CHIX'
      *Character index.*  The character index begins with a 32-bit
      big-endian unsigned integer indicating the total size of the
      section, not including this size value.  For each character, there
      is an instance of the following entry structure:
 
         * *Unicode code point.*  (32-bit big-endian integer.)
 
         * *Storage flags.*  (byte.)
 
              * Bits 2..0:
 
                If equal to 000 binary, then the character data is stored
                uncompressed beginning at the offset indicated by the
                character's *offset* value.
 
                If equal to 001 binary, then the character data is stored
                within a compressed character definition block that
                begins at the offset within the file indicated by the
                character's *offset* value.
 
         * *Offset.*  (32-bit big-endian integer.)
 
           A marker that indicates the remainder of the file is data
           accessed via the character index (CHIX) section.  When reading
           this font file, the rest of the file can be ignored when
           scanning the sections.  The length should be set to -1
           (0xFFFFFFFF).
 
           Supported data structures:
 
           Character definition Each character definition consists of:
 
              * *Width.*  Width of the bitmap in pixels.  The bitmap's
                extents represent the glyph's bounding box.  'uint16be'.
 
              * *Height.*  Height of the bitmap in pixels.  The bitmap's
                extents represent the glyph's bounding box.  'uint16be'.
 
              * *X offset.*  The number of pixels to shift the bitmap by
                horizontally before drawing the character.  'int16be'.
 
              * *Y offset.*  The number of pixels to shift the bitmap by
                vertically before drawing the character.  'int16be'.
 
              * *Device width.*  The number of pixels to advance
                horizontally from this character's origin to the origin
                of the next character.  'int16be'.
 
              * *Bitmap data.*  This is encoded as a string of bits.  It
                is organized as a row-major, top-down, left-to-right
                bitmap.  The most significant bit of each byte is taken
                to be the leftmost or uppermost bit in the byte.  For the
                sake of compact storage, rows are not padded to byte
                boundaries (i.e., a single byte may contain bits
                belonging to multiple rows).  The last byte of the bitmap
                *is* padded with zero bits in the bits positions to the
                right of the last used bit if the bitmap data does not
                fill the last byte.
 
                The length of the *bitmap data* field is (WIDTH * HEIGHT
                + 7) / 8 using integer arithmetic, which is equivalent to
                ceil(WIDTH * HEIGHT / 8) using real number arithmetic.
 
                It remains to be determined whether bitmap fonts usually
                make all glyph bitmaps the same height, or if smaller
                glyphs are stored with bitmaps having a lesser height.
                In the latter case, the baseline would have to be used to
                calculate the location the bitmap should be anchored at
                on screen.