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