📄 ebdt.htm
字号:
<HTML>
<HEAD>
<TITLE>The 'EBDT' Table</TITLE>
<STYLE>
<!--
BODY {background: #FFFFFF; link: #000080}
H1 {font-size: 24pt; color: #c60029}
H2 {font-size: 18pt; color: black}
H3 {font-size: 16pt; color: black}
H4 {font-size: 14pt; color: black}
CAPTION {font-size: 16pt; font-weight: Bold}
A:link {text-decoration: none}
-->
</STYLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" LINK="#000080">
<TABLE WIDTH=530 CELLPADDING=8 CELLSPACING=0 BORDER=0>
<TR>
<TD><IMG WIDTH=100 HEIGHT=1 ALT="" SRC="/TRUETYPE/OTSPEC/pixel.gif" BORDER=0></TD>
<TD><H1>Table Formats</H1></TD></TR>
<TR>
<TD></TD><TD ALIGN=TOP><H2>EBDT - Embedded Bitmap Data Table
</H2>
<P>
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.
<P>
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.
<P>
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.
<P>
The 'EBDT' table uses the same format as Apple has defined for
the QuickDraw GX 'bdat' table.
<P>
The 'EBDT' table begins with a header containing simply the table
version number.
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name
<TH BGCOLOR="#C0C0C0">Description</TH></TR>
</THEAD><TBODY>
<TR>
<TD VALIGN=TOP>FIXED</TD><TD VALIGN=TOP>version</TD>
<TD VALIGN=TOP>Initially defined as 0x00020000</TD></TR>
</TABLE>
<P>
<P>
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.
<P>
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.
<BR> <BR><FONT SIZE=5>bigGlyphMetrics</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>height</TD></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>width</TD></TR>
<TR>
<TD VALIGN=TOP>CHAR</TD><TD VALIGN=TOP>horiBearingX</TD></TR>
<TR>
<TD VALIGN=TOP>CHAR</TD><TD VALIGN=TOP>horiBearingY</TD></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>horiAdvance</TD></TR>
<TR>
<TD VALIGN=TOP>CHAR</TD><TD VALIGN=TOP>vertBearingX</TD></TR>
<TR>
<TD VALIGN=TOP>CHAR</TD><TD VALIGN=TOP>vertBearingY</TD></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>vertAdvance</TD></TR>
</TABLE>
<P>
<BR> <BR><FONT SIZE=5>smallGlyphMetrics</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>height</TD></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>width</TD></TR>
<TR>
<TD VALIGN=TOP>CHAR</TD><TD VALIGN=TOP>BearingX</TD></TR>
<TR>
<TD VALIGN=TOP>CHAR</TD><TD VALIGN=TOP>BearingY</TD></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>Advance</TD></TR>
</TABLE> <P>
<P>
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.
<P>
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.
<P>
<B>Note:</B> Each of these formats can contain black/white or grayscale bitmaps depending on the setting of the bitDepth field in the 'EBLC' table. For performance reasons, we recommend using a byte-aligned format for embedded bitmaps with bitDepth of 8.
<BR> <BR><FONT SIZE=5>Format 1: small metrics, byte-aligned data</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TH></TR>
<TR>
<TD VALIGN=TOP>smallGlyphMetrics</TD>
<TD VALIGN=TOP>smallMetrics</TD><TD VALIGN=TOP>Metrics information for the glyph</TD></TR>
<TR>
<TD VALIGN=TOP>VARIABLE</TD><TD VALIGN=TOP>image data</TD>
<TD VALIGN=TOP>Byte-aligned bitmap data</TD></TR>
</TABLE> <P>
<P>
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.
<BR> <BR><FONT SIZE=5>Format 2: small metrics, bit-aligned data</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TH></TR>
<TR>
<TD VALIGN=TOP>smallGlyphMetrics</TD>
<TD VALIGN=TOP>small Metrics</TD><TD VALIGN=TOP>Metrics information for the glyph</TD></TR>
<TR>
<TD VALIGN=TOP>VARIABLE</TD><TD VALIGN=TOP>image data</TD>
<TD VALIGN=TOP>Bit-aligned bitmap data</TD></TR>
</TABLE> <P>
<P>
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.<BR><p>
<FONT SIZE=4><STRONG>Format 3: (obsolete)</STRONG></FONT><br>
<FONT SIZE=4><STRONG>Format 4: (not supported) metrics in EBLC, compressed data</STRONG></FONT>
<P>
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.
<BR> <BR><FONT SIZE=5>Format 5: metrics in EBLC, bit-aligned image data only</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TD></TR>
<TR>
<TD VALIGN=TOP>VARIABLE</TD><TD VALIGN=TOP>image data</TD>
<TD VALIGN=TOP>Bit-aligned bitmap data</TD></TR>
</TABLE> <P>
<P>
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.
<P>
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.
<BR> <BR><FONT SIZE=5>Format 6: big metrics, byte-aligned data</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TD></TR>
<TR>
<TD VALIGN=TOP>bigGlyphMetrics</TD>
<TD VALIGN=TOP>bigMetrics</TD><TD VALIGN=TOP>Metrics information for the glyph</TD></TR>
<TR>
<TD VALIGN=TOP>VARIABLE</TD><TD VALIGN=TOP>image data</TD>
<TD VALIGN=TOP>Byte-aligned bitmap data</TD></TR>
</TABLE> <P>
<P>
Glyph bitmap format 6 is the same as format
1 except that is uses big glyph metrics instead of small.
<BR> <BR><FONT SIZE=5>Format7: big metrics, bit-aligned data</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TD></TR>
<TR>
<TD VALIGN=TOP>bigGlyphMetrics</TD>
<TD VALIGN=TOP>bigMetrics</TD><TD VALIGN=TOP>Metrics information for the glyph</TD></TR>
<TR>
<TD VALIGN=TOP>VARIABLE</TD><TD VALIGN=TOP>image data</TD>
<TD VALIGN=TOP>Bit-aligned bitmap data</TD></TR>
</TABLE> <P>
<P>
Glyph bitmap format 7 is the same as format
2 except that is uses big glyph metrics instead of small.<BR>
<BR> <BR><FONT SIZE=5>bdtComponent; array used by Formats 8 and 9</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>glyphCode</TD>
<TD VALIGN=TOP>Component glyph code</TD></TR>
<TR>
<TD VALIGN=TOP>CHAR</TD><TD VALIGN=TOP>xOffset</TD>
<TD VALIGN=TOP>Position of component left</TD></TR>
<TR>
<TD VALIGN=TOP>CHAR</TD><TD VALIGN=TOP>yOffset</TD>
<TD VALIGN=TOP>Position of component top</TD></TR>
</TABLE> <P>
<P>
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.
<BR> <BR><FONT SIZE=5>Format 8: small metrics, component data</FONT>
<TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TD></TR>
<TR>
<TD VALIGN=TOP>smallGlyphMetrics</TD>
<TD VALIGN=TOP>smallMetrics</TD><TD VALIGN=TOP>Metrics information for the glyph</TD></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>pad</TD>
<TD VALIGN=TOP>Pad to short boundary</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>numComponents</TD>
<TD VALIGN=TOP>Number of components</TD></TR>
<TR>
<TD VALIGN=TOP>ebdtComponent</TD>
<TD VALIGN=TOP>componentArray[n]</TD><TD VALIGN=TOP>Glyph code, offset array</TD></TR>
</TABLE> <P>
<BR> <BR><FONT SIZE=5>Format 9: big metrics, component data</FONT><TABLE WIDTH=530 BGCOLOR="#F0F0F0">
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TD></TR>
<TR>
<TD VALIGN=TOP>bigGlyphMetrics</TD>
<TD VALIGN=TOP>bigMetrics</TD><TD VALIGN=TOP>Metrics information for the glyph</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>numComponents</TD>
<TD VALIGN=TOP>Number of components</TD></TR>
<TR>
<TD VALIGN=TOP>ebdtComponent</TD>
<TD VALIGN=TOP>componentArray[n]</TD><TD VALIGN=TOP>Glyph code, offset array</TD></TR>
</TABLE> <P>
<P>
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.
<br> <br>
<FONT FACE="Arial, Helvetica" SIZE=1>
Microsoft Typography Web Site <A HREF="/truetype/otspec/CPYRIGHT.htm">© 1996 Microsoft Corporation</A>
<BR>
Comments to the Microsoft Typography group: <A HREF="mailto:ttwsite@microsoft.com">ttwsite@microsoft.com</A>
<BR>
<A HREF="/truetype/default.htm">Home</a> | <a href="/truetype/creators.htm"> Information for Developers</a>
<BR>
Last updated 05 September 1996
</FONT>
</TD>
</TABLE>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -