EBDT - Embedded Bitmap Data Table

Three new tables are used to embed bitmaps in TrueType fonts. They are the 'EBLC' table for embedded bitmap locators, the 'EBDT' table for embedded bitmap data, and the 'EBSC' table for embedded bitmap scaling information.

TrueType 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 keeps offsets to glyph bitmap data in indexSubTables. The 'EBDT' table then stores the glyph bitmap data, in a number of different possible formats. Glyph metrics information may be stored in either the 'EBLC' or 'EBDT' table, depending upon the indexSubTable and glyph bitmap data formats. The 'EBSC' table identifies sizes that will be handled by scaling up or scaling down other sbit sizes.

The 'EBDT' table uses the same format as Apple has defined for the QuickDraw GX 'bdat' table.

The 'EBDT' table begins with a header containing simply the table version number.

Type

Name

Description

FIXED

version

Initially defined as 0x00020000


The rest of the 'EBDT' table is a simply a collection of bitmap data. The 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. 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 'EBLC' 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


The nine different formats currently defined for glyph bitmap data are listed and described below. Different formats are better for different purposes. Apple 'bdat' tables support only formats 1 through 7.

Format 1: small metrics, byte-aligned data

Type

Name

Description

smallGlyphMetrics

smallMetrics

Metrics information for the glyph

VARIABLE

image data

Byte-aligned bitmap data


Glyph bitmap format 1 consists of small metrics records (either horizontal or vertical depending on the bitmapSizeTable 'flag' value in 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

Type

Name

Description

smallGlyphMetrics

small Metrics

Metrics information for the glyph

VARIABLE

image data

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)

Format 4: (not supported) metrics in EBLC, compressed data

Glyph bitmap format 4 is a compressed format used by Apple in some of their Far East fonts. MS has not implemented it in our rasterizer.

Format 5: metrics in EBLC, bit-aligned image data only

Type

Name

Description

VARIABLE

image data

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.

The rasterizer recalculates sbit metrics for Format 5 bitmap data, allowing Windows to report correct ABC widths, 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 Windows GetABCWidths call.

Format 6: big metrics, byte-aligned data

Type

Name

Description

bigGlyphMetrics

bigMetrics

Metrics information for the glyph

VARIABLE

image data

Byte-aligned bitmap data


Glyph bitmap format 6 is the same as format 1 except that is uses big glyph metrics instead of small.

Format 7: big metrics, bit-aligned data

Type

Name

Description

bigGlyphMetrics

bigMetrics

Metrics information for the glyph

VARIABLE

image data

Bit-aligned bitmap data


Glyph bitmap format 7 is the same as format 2 except that is uses big glyph metrics instead of small.

ebdtComponent; array used by Formats 8 and 9

Type

Name

Description

USHORT

glyphCode

Component glyph code

CHAR

xOffset

Position of component left

CHAR

yOffset

Position of component top


The component array, used by Formats 8 and 9, contains the glyph code of the component, which can be looked up in the 'EBLC' table, as well as xOffset and yOffset values which tell where to position the top-left corner of the component in the composite. Nested composites (a composite of composites) are allowed, and the number of nesting levels is determined by implementation stack space.

Format 8: small metrics, component data

Type

Name

Description

smallGlyphMetrics

smallMetrics

Metrics information for the glyph

BYTE

pad

Pad to short boundary

USHORT

numComponents

Number of components

ebdtComponent

componentArray[n]

Glyph code, offset array


Format 9: big metrics, component data

Type

Name

Description

bigGlyphMetrics

bigMetrics

Metrics information for the glyph

USHORT

numComponents

Number of components

ebdtComponent

componentArray[n]

Glyph code, offset array


Glyph bitmap formats 8 and 9 are used for composite bitmaps. For accented characters and other composite glyphs it may be more efficient to store a copy of each component separately, and then use a composite description to construct the finished glyph. The composite formats allow for any number of components, and allow the components to be positioned anywhere in the finished glyph. Format 8 uses small metrics, and format 9 uses big metrics.