CBDT - Color Bitmap Data Table (OpenType 1.7)
Table structure
Two tables are used to embed color bitmaps in OFF fonts. They are the 'CBLC' table for embedded bitmap locators and the 'CBDT' table for embedded color bitmap data. The formats of these two tables are backward compatible with EBLC and EBDT used for embedded monochrome and grayscale bitmaps
The 'EBDT' table begins with a header containing simply the table version number
Type | Name | Description |
---|---|---|
FIXED | version | Initially defined as 0x00030000 |
The rest of the 'CBDT' table is a collection of bitmap data. The data can be presented in three possible formats, indicated by information in the 'CBLC' table. Some of the formats contain metric information plus image data, and other formats contain only the image data. Long word alignment is not required for these sub tables; byte alignment is sufficient.
Uncompressed Color Bitmaps
The value ‘32’ of the bitDepth field of bitmapSizeTable struct defined in the CBLC table, to identify color bitmaps with 8-bit blue/green/red/alpha channels per pixel, encoded in that order for each pixel (referred to as BGRA from hereon). The color channels represent pre-multiplied color and are encode colors in the sRGB colorspace. For example, the color “full-green with half translucency” is encoded as \x00\x80\x00\x80, and not \x00\xFF\x00\x80.
All imageFormat values defined in the EBDT / EBLC tables are valid for use with the CBDT / CBLC tables.
Compressed Color Bitmaps
Images for each individual glyph are stored as straight PNG data. Only the following chunks are allowed in such PNG data: IHDR, PLTE, tRNS, sRGB, IDAT, and IEND. If other chunks are present, the behavior is undefined. The image data shall be in the sRGB colorspace, regardless of color information that may be present in other chunks in the PNG data. The individual images must have the same size as expected by the table in the bitmap metrics.
Glyph Metrics
There are also two different formats for glyph metrics: big glyph metrics and small glyph metrics. Big glyph metrics define metrics information for both horizontal and vertical layouts. This is important in fonts (such as Kanji) where both types of layout may be used. Small glyph metrics define metrics information for one layout direction only. Which direction applies, horizontal or vertical, is determined by the ‘flags’ field in the bitmapSizeTable field of the 'CBLC' table.
bigGlyphMetrics
Type | Name |
---|---|
BYTE | height |
BYTE | width |
CHAR | horiBearingX |
CHAR | horiBearingY |
BYTE | horiAdvance |
CHAR | vertBearingX |
CHAR | vertBearingY |
BYTE | vertAdvance |
smallGlyphMetrics
Type | Name |
---|---|
BYTE | height |
BYTE | width |
CHAR | BearingX |
CHAR | BearingY |
BYTE | Advance |
Glyph Bitmap Data Formats
In addition to nine different formats already defined for glyph bitmap data in the EBDT table, there are three new formats described below
Format 17: small metrics, PNG image data
Type | Name | Description |
---|---|---|
smallGlyphMetrics | glyphMetrics | Metrics information for the glyph |
ULONG | dataLen | Length of data in bytes |
Variable | data | Raw PNG data |
Format 18: big metrics, PNG image data
Type | Name | Description |
---|---|---|
bigGlyphMetrics | glyphMetrics | Metrics information for the glyph |
ULONG | dataLen | Length of data in bytes |
Variable | data | Raw PNG data |
Format 19: metrics in CBLC, PNG image data
Type | Name | Description |
---|---|---|
ULONG | dataLen | Length of data in bytes |
Variable | data | Raw PNG data |
Scaling behavior
Applications using these glyphs may need to scale them to fit the raster size available for display. How this scaling takes place is application dependent. It is recommended that where possible the application downscale using the closest sized bitmap that is larger than the desired end raster size.
OpenType specification