EBDT — Embedded Bitmap Data Table
The EBDT table is used to embed monochrome or grayscale bitmap glyph data. It is used together with the EBLC table, which provides embedded bitmap locators, and the EBSC table, which provides embedded bitmap scaling information.
OpenType embedded bitmaps are also called “sbits” (for “scaler bitmaps”). A set of bitmaps for a face at a given size is called a strike.
The EBLC table identifies the sizes and glyph ranges of the sbits, and has offsets to glyph bitmap data within the EBDT table. The EBDT table then stores the glyph bitmap data, using a number of different possible formats. Glyph metrics information may be stored in either the EBLC or EBDT table, depending upon the formats used in each table. The EBSC table identifies sizes that will be handled by scaling up or scaling down other sbit sizes.
Table structure
The EBDT table begins with a header containing simply the table version number.
EBDT Header
| Type | Name | Description |
|---|---|---|
| uint16 | majorVersion | Major version of the EBDT table, = 2. |
| uint16 | minorVersion | Minor version of the EBDT table, = 0. |
Note: The first version of the EBDT table is 2.0.
The rest of the EBDT table is a collection of bitmap data. The bitmap data can be in a number of possible formats, indicated by information in the EBLC 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.
There are also two different formats for glyph metrics: big glyph metrics and small glyph metrics. A BigGlyphMetrics record defines metrics information for both horizontal and vertical layouts. This is important in fonts (such as Kanji) where both types of layout may be used. The SmallGlyphMetrics record defines metrics information for one layout direction only. Which direction applies, horizontal or vertical, is determined by the flags field in the BitmapSize records within the EBLC table.
BigGlyphMetrics record
| Type | Name | Description |
|---|---|---|
| uint8 | height | Number of rows in the bitmap. |
| uint8 | width | Number of columns in the bitmap. |
| int8 | horiBearingX | Distance in pixels from the horizontal origin to the left edge of the bitmap. |
| int8 | horiBearingY | Distance in pixels from the horizontal origin to the top edge of the bitmap. |
| uint8 | horiAdvance | Horizontal advance width in pixels. |
| int8 | vertBearingX | Distance in pixels from the vertical origin to the left edge of the bitmap. |
| int8 | vertBearingY | Distance in pixels from the vertical origin to the top edge of the bitmap. |
| uint8 | vertAdvance | Vertical advance width in pixels. |
SmallGlyphMetrics record
| Type | Name | Description |
|---|---|---|
| uint8 | height | Number of rows in the bitmap. |
| uint8 | width | Number of columns in the bitmap. |
| int8 | bearingX | Distance in pixels from the horizontal origin to the left edge of the bitmap (for horizontal text); or distance in pixels from the vertical origin to the top edge of the bitmap (for vertical text). |
| int8 | bearingY | Distance in pixels from the horizontal origin to the top edge of the bitmap (for horizontal text); or distance in pixels from the vertical origin to the left edge of the bitmap (for vertical text). |
| uint8 | advance | Horizontal or vertical advance width in pixels. |
Some of the bitmap data formats allow a composite bitmap to be defined, using one or more bitmaps as components. The composite formats allow for any number of components, and allow the components to be positioned anywhere in the composite glyph. The components are referenced using an EbdtComponent record.
EbdtComponent record
| Type | Name | Description |
|---|---|---|
| uint16 | glyphID | Component glyph ID |
| int8 | xOffset | Position of component left |
| int8 | yOffset | Position of component top |
The EbdtComponent record contains the glyph ID of the component, which can be used to look up the location of component glyph data in the EBLC table. The record also contains xOffset and yOffset values that specify where to position the top-left corner of the component within the composite. Nested composites (a composite of composites) are allowed, and the number of nesting levels is determined by implementation stack space.
Glyph bitmap data formats
The nine different formats currently defined for glyph bitmap data are listed and described below. Different formats are better for different purposes.
In all formats, if the bitDepth is greater than 1, all of a pixel’s bits are stored consecutively in memory, and all of a row’s pixels are stored consecutively.
Each format can contain black/white or grayscale bitmaps depending on the setting of the bitDepth field in the EBLC table. For performance reasons, a byte-aligned format for embedded bitmaps with bitDepth of 8 is recommended.
Format 1: small metrics, byte-aligned data
GlyphBitmapFormat1 table
| Type | Name | Description |
|---|---|---|
| SmallGlyphMetrics | smallMetrics | Metrics information for the glyph |
| uint8 | imageData[variable] | Byte-aligned bitmap data |
Glyph bitmap format 1 consists of a small metrics records (either horizontal or vertical depending on the flags field of the BitmapSize record within the EBLC table) followed by byte aligned bitmap data. The bitmap data begins with the most significant bit of the first byte corresponding to the top-left pixel of the bounding box, proceeding through succeeding bits moving left to right. The data for each row is padded to a byte boundary, so the next row begins with the most significant bit of a new byte. 1 bits correspond to black, and 0 bits to white.
Format 2: small metrics, bit-aligned data
GlyphBitmapFormat2 table
| Type | Name | Description |
|---|---|---|
| SmallGlyphMetrics | smallMetrics | Metrics information for the glyph |
| uint8 | imageData[variable] | Bit-aligned bitmap data |
Glyph bitmap format 2 is the same as format 1 except that the bitmap data is bit aligned. This means that the data for a new row will begin with the bit immediately following the last bit of the previous row. The start of each glyph must be byte aligned, so the last row of a glyph may require padding. This format takes a little more time to parse, but saves file space compared to format 1.
Format 3: (obsolete)
This format is not supported in OpenType.
Format 4: (not supported) metrics in EBLC, compressed data
Glyph bitmap format 4 is a compressed format used by Apple in some of their East Asian fonts. This format is not supported in OpenType.
Format 5: metrics in EBLC, bit-aligned image data only
GlyphBitmapFormat5 table
| Type | Name | Description |
|---|---|---|
| uint8 | imageData[variable] | Bit-aligned bitmap data |
Glyph bitmap format 5 is similar to format 2 except that no metrics information is included, just the bit aligned data. This format is for use with EBLC indexSubTable format 2 or format 5, which will contain the metrics information for all glyphs. It works well for Kanji fonts.
In Windows, the rasterizer recalculates sbit metrics for Format 5 bitmap data, allowing correct ABC widths to be reported, even if the bitmaps have white space on either side of the bitmap image. This allows fonts to store monospaced bitmap glyphs in the efficient Format 5 without breaking calls to the GetABCWidths API.
Format 6: big metrics, byte-aligned data
GlyphBitmapFormat6 table
| Type | Name | Description |
|---|---|---|
| BigGlyphMetrics | bigMetrics | Metrics information for the glyph |
| uint8 | imageData[variable] | Byte-aligned bitmap data |
Glyph bitmap format 6 is the same as format 1 except that is uses big glyph metrics instead of small.
Format7: big metrics, bit-aligned data
GlyphBitmapFormat7 table
| Type | Name | Description |
|---|---|---|
| BigGlyphMetrics | bigMetrics | Metrics information for the glyph |
| uint8 | imageData[variable] | Bit-aligned bitmap data |
Glyph bitmap format 7 is the same as format 2 except that is uses big glyph metrics instead of small.
Format 8: small metrics, component data
Format 8 allows definition of composite bitmaps using one or more component bitmaps. See the Table structure section above for a description of the EbdtComponent record.
GlyphBitmapFormat8 table
| Type | Name | Description |
|---|---|---|
| SmallGlyphMetrics | smallMetrics | Metrics information for the glyph |
| uint8 | pad | Pad to 16-bit boundary |
| uint16 | numComponents | Number of components |
| EbdtComponent | components[numComponents] | Array of EbdtComponent records |
Format 9: big metrics, component data
Format 9 allows definition of composite bitmaps using one or more component bitmaps. See the Table structure section above for a description of the EbdtComponent record.
GlyphBitmapFormat9 table
| Type | Name | Description |
|---|---|---|
| BigGlyphMetrics | bigMetrics | Metrics information for the glyph |
| uint16 | numComponents | Number of components |
| EbdtComponent | components[numComponents] | Array of EbdtComponent records |
OpenType specification