sbix — Standard Bitmap Graphics Table (OpenType 1.8.3)
This table provides access to bitmap data in a standard graphics format, such as PNG, JPEG or TIFF.
The 'sbix' table has functionality somewhat similar to the EBDT table in that both provide bitmap data for glyph presentation. They are different in three important respects, however. First, whereas the EBDT table supports only black/white or grayscale bitmaps, the 'sbix' table supports color bitmaps. Secondly, whereas the EBDT table uses formats specific to the OpenType specification, the 'sbix' table uses standard bitmap graphics formats that are in common use. Thirdly, whereas the EBDT table must be used in conjunction with other tables (EBLC and EBSC) for processing the bitmap data, the 'sbix' table contains complete data required for processing bitmaps.
A font that includes an 'sbix' table may also include outline glyph data in a 'glyf' or 'CFF ' table. An 'sbix' table can provide bitmap data for all glyph IDs, or for only a subset of glyph IDs. A font can also include different bitmap data for different sizes (“strikes”), and the glyph coverage for one size can be different from that for another size.
Header
The 'sbix' table begins with a header:
'sbix' Header
| Type | Name | Description |
|---|---|---|
| uint16 | version | Table version number — set to 1 |
| uint16 | flags | Bit 0: Set to 1. Bit 1: Draw outlines. Bits 2 to 15: reserved (set to 0). |
| uint32 | numStrikes | Number of bitmap strikes. |
| Offset32 | strikeOffsets[numStrikes] | Offsets from the beginning of the 'sbix' table to data for each individual bitmap strike. |
For historical reasons, bit 0 of the flags field should always be set to 1.
If bit 1 of the flags field is clear, then the application is instructed to draw only the bitmaps for each glyph supported in the 'sbix' table. If bit 1 is set, then the application is instructed to draw the bitmap and the outline, in that order (that is, with the outline overlaid on top of the bitmap). If the 'sbix' table does not contain bitmap data for a glyph, then the outline is always drawn, regardless of the state of bit 1.
Note: Application support for bit 1 of the flags field is optional. To ensure the best compatibility, set this bit to 0.
Strikes
Each strike includes a header and the glyph bitmap data. The header has the following format:
| Type | Name | Description |
|---|---|---|
| uint16 | ppem | The PPEM size for which this strike was designed. |
| uint16 | ppi | The device pixel density (in PPI) for which this strike was designed. (E.g., 96 PPI, 192 PPI.) |
| Offset32 | glyphDataOffsets[numGlyphs+1] | Offset from the beginning of the strike data header to bitmap data for an individual glyph ID. |
The glyphDataOffset array includes offsets for every glyph ID, plus one extra. The number of glyphs is determined from the 'maxp' table. The length of the bitmap data for each glyph is variable, and can be determined from the difference between two consecutive offsets. Hence, the length of data for glyph N is glyphDataOffset[N+1] - glyphDataOffset[N]. If this is zero, there is no bitmap data for that glyph in this strike. There is one extra offset in the array in order to provide the length of data for the last glyph.
Note: The length of data for non-printing glyphs, such as space, should always be zero.
A strike does not need to include data for every glyph, and does not need to include data for the same set of glyphs as other strikes. If the application is using bitmap data to draw text and there is bitmap data for a glyph in any strike, then the glyph must be drawn using a bitmap from some strike. If the exact size is not available, implementations may choose a bitmap based on the closest available larger size, or the closest available integer-multiple larger size, or on some other basis. The only cases in which a glyph is not drawn using a bitmap are if the application has not requested that text be drawn using bitmap data or if there is no bitmap data for the glyph in any strike.
Each strike targets a specific PPEM size and device pixel density (PPI). Thus, a font can contain two strikes for the same PPEM but different pixel densities, or two strikes for the same pixel density but different PPEMs. Note that some platforms may not support targeting of strikes for particular pixel densities.
Glyph data
The data for each glyph includes a header and the actual, embedded graphic data, with the following format:
| Type | Name | Description |
|---|---|---|
| int16 | originOffsetX | The horizontal (x-axis) offset from the left edge of the graphic to the glyph’s origin. That is, the x-coordinate of the point on the baseline at the left edge of the glyph. |
| int16 | originOffsetY | The vertical (y-axis) offset from the bottom edge of the graphic to the glyph’s origin. That is, the y-coordinate of the point on the baseline at the left edge of the glyph. |
| Tag | graphicType | Indicates the format of the embedded graphic data: one of 'jpg ', 'png ' or 'tiff', or the special format 'dupe'. |
| uint8 | data[] | The actual embedded graphic data. The total length is inferred from sequential entries in the glyphDataOffsets array and the fixed size (8 bytes) of the preceding fields. |
The graphicType field indicates the format of the embedded graphic data. Three standard formats are supported: JPEG, PNG and TIFF; these are indicated using tag values 'jpg ', 'png ' and 'tiff', respectively.
The special graphicType of 'dupe' indicates that the data field contains a uint16, big-endian glyph ID. The bitmap data for the indicated glyph should be used for the current glyph.
Note: Apple’s specification for TrueType fonts allows for a graphicType tag value of 'pdf ' or 'mask'. These values are not supported in the OpenType specification, however.
Table dependencies
The glyph count is derived from the 'maxp' table. Advance and side-bearing glyph metrics are stored in the 'hmtx' table for horizontal layout, and the 'vmtx' table for vertical layout.