SIRTX Font format
Information on the SIRTX Font format
Overview
The SIRTX Font format is used as a native format for pixel (bitmap) fonts. It provides support for full Unicode range of characters, up to 64 thousand glyphs, with a maximum size of 255 by 255 pixels.
The font files are divided in four blocks. The magic, the headers, the character map, and the glyph data. The magic is used to identify the format and it's version. The headers include the glyph geometry and glyph count. They may also hold additional metadata such as the font's name or additional geometry hints. The character map maps Unicode code points to specific glyphs. And the glyph data contains the actual bitmaps. All but the glyph data is 8 byte aligned. All data in the format is in network byte order (big endian).
Magic
The file magic is a string of eight bytes: 0x00, 0x07, 0x53 ("S"), 0x46 ("F"), 0x0d ("\r"), 0x0a ("\n"), 0xc0, 0x0a ("\n"). This magic is fixed for all files of this type.
Headers
The header section consists of headers with each a size being a multiple of 8 bytes. Each header can be marked as optional, meaning the header is not required to be supported by a renderer for basic usage of the font. The last header is the Master header. It marks the end of the header section.
All headers follow the following structure:
| Offset † | Size [Byte] | Description |
|---|---|---|
| 0 | 2 | Data start marker, always 0x0600 |
| 2 | 1 | Value A |
| 3 | 1 | Value B |
| 4 | 1 | Value C |
| 5 | 1 | Type and flags The lower 6 bit are the type. The 7th bit indicates that this header has an extra section. The 8th bit (MSB) indicates that this header is optional. Optional headers can be ignored by renderers if they don't support them. All other headers must be supported or loading of the font must be cancelled. |
| 6 | 2 | Value X |
| 8 | C*8 | Extra data if the extra bit is set in the Types and flags field. The Value C stores the amount of extra data in units of 8 bytes. |
†: Relative to header. Add eight for offset relative to file.
The following headers are defined. All undefined/unknown headers should be treated as invalid (and font loading cancelled) unless the optional flag is set.
| Type | Has extra | Optional | Multiplicity | Value A | Value B | Value C | Value X | Extra | Info |
|---|---|---|---|---|---|---|---|---|---|
| 0 | no | no | 1 | Glyph width in pixel. |
Glyph height in pixel. |
Glyph bit depth in bit. |
Number of glyphs | none | Master header Always the last header. If many headers are included it might be useful to include an Early hints header. |
| 1 | no | yes | 0..n | Glyph width in pixel. |
Glyph height in pixel. |
Number of records that can be skipped. |
Font flags | none | Early hints |
| 2 | no | yes | 0..1 | horizontal middle line | vertical middle line | Baseline | Font flags | none | Geometry hints |
| 3 | yes | yes | 0..1 | Major version | Minor version (upper 6 bit) and version type (lower 2 bits). Valid version types: devel (0), beta (1), rc (2), stable (3) |
extra length | Datecode of last modification | If C is 2 or more: first 16 byte are UUID of the font. If C is 3 or more: reminder 0x00/0xFF-padded font name in UTF-8 |
Identity header |
| 4 | yes | yes | 0..1 | A (MSB) and B (LSB): backup code point or all-zeros or all-ones to mark as not given | extra length | Backup colour in 4+12-format | If C is 4 or more: first 4 byte codepoint or all-ones. If C is 8 or more: second 4 byte 0x00, and 24 bit RGB value or all-ones. |
Display colour and icontext The backup values will ne used if the other values are not given or not supported |
|
| 5-63 | Reserved | ||||||||
Character map
The character map is a list of eight byte long code point runs. Each run consists of the start code point, the length, and the first entry in the glyph data, The last run is marked to signal the end of the map. This is done by setting the start value to all ones. It is valid that multiple characters map to the same glyph. Each run is encoded as follows:
The character map must be sorted by the start code point with lowest value first.
A code point can be mapped to multiple glyphs. In that case the highest glyph must be mapped first. The renderer will use the first mapping for any given code point for which it can render a glyph. This is useful when some glyphs contain extensions not all renderers support. It is currently unspecified how this interacts with runs of a length larger than one glyph. Also, this is not supported by all software, hence it should be used with care.
| Offset † | Size [Byte] | Description |
|---|---|---|
| 0 | 4 | The start code point. The last run uses the value of all ones. |
| 4 | 2 | The length of the run minus one. If the run is only one character long a value of zero is encoded. |
| 6 | 2 | The first entry into the glyph data (corresponding to the start code point). If length is non-zero each additional n-th code point is mapped to the n-th next glyph. |
†: Relative to current run.
Glyph data
The glyph data is encoded in accordance with the bit depth value from the header. For a bit depth of one the glyph data is encoded as one bit per pixel. The leftmost pixel is encoded as MSB. Each row is padded with zeros to the next full byte. This format is the same as the WBMP Type 0 image data. See the WAP WAE Specification (version 1.1, 24-May-1999) section 6 and appendix A for details.