eblc.htm

TrueType字库标准文档

<BR>&nbsp;<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>&nbsp;&nbsp;<P>
<P>
The following diagram illustrates the meaning
of the glyph metrics.<BR>

<P>
<A HREF="/TRUETYPE/OTSPEC/GLYPHMET.HTM">IMAGE: The meaning of glyph metrics</A>

<P>
The bitmapSizeTable for each strike contains
the offset to an array of indexSubTableArray elements. Each element
describes a glyph code range and an offset to the indexSubTable
for that range. This allows a strike to contain multiple glyph
code ranges and to be represented in multiple index formats if
desirable.

<BR>&nbsp;<BR><FONT SIZE=5>indexSubTableArray</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>USHORT</TD><TD VALIGN=TOP>firstGlyphIndex</TD>
<TD VALIGN=TOP>first glyph code of this range</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>lastGlyphIndex</TD>
<TD VALIGN=TOP>last glyph code of this range (inclusive)</TD></TR>
<TR>
<TD VALIGN=TOP>ULONG</TD><TD VALIGN=TOP>additionalOffsetToIndexSubtable</TD>
<TD VALIGN=TOP>add to indexSubTableArrayOffset to get offset from beginning of 'EBLC'</TR>
</TABLE>&nbsp;&nbsp;<P>
<P>
After determining the strike, the rasterizer
searches this array for the range containing the given glyph code.
When the range is found, the additionalOffsetToIndexSubtable is
added to the indexSubTableArrayOffset to get the offset of the
indexSubTable in the 'EBLC'.
<P>
The first indexSubTableArray is located after the last bitmapSizeSubTable
entry. Then the indexSubTables for the strike follow. Another
indexSubTableArray (if more than one strike) and its indexSubTables
are next. The 'EBLC' continues with an array and indexSubTables
for each strike.
<P>
We now have the offset to the indexSubTable. All indexSubTable
formats begin with an indexSubHeader which identifies the indexSubTable
format, the format of the 'EBDT' image data, and the offset from
the beginning of the 'EBDT' table to the beginning of the image
data for this range.

<BR>&nbsp;<BR><FONT SIZE=5>indexSubHeader</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>USHORT</TD><TD VALIGN=TOP>indexFormat</TD>
<TD VALIGN=TOP>format of this indexSubTable</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>imageFormat</TD>
<TD VALIGN=TOP>format of 'EBDT' image data</TD></TR>
<TR>
<TD VALIGN=TOP>ULONG</TD><TD VALIGN=TOP>imageDataOffset</TD>
<TD VALIGN=TOP>offset to image data in 'EBDT' table</TD></TR>
</TABLE>&nbsp;&nbsp;<P>
<P>
There are currently five different formats
used for the indexSubTable, depending upon the size and type of
bitmap data in the glyph code range. Apple 'bloc' tables support
only formats 1 through 3.
<P>
The choice of which indexSubTable format to use is up to the font
manufacturer, but should be made with the aim of minimizing the
size of the font file. Ranges of glyphs with variable metrics
- that is, where glyphs may differ from each other in bounding
box height, width, side bearings or advance - must use format
1, 3 or 4. Ranges of glyphs with constant metrics can save space
by using format 2 or 5, which keep a single copy of the metrics
information in the indexSubTable rather than a copy per glyph
in the 'EBDT' table. In some monospaced fonts it makes sense to
store extra white space around some of the glyphs to keep all
metrics identical, thus permitting the use of format 2 or 5.
<P>
Structures for each indexSubTable format are listed below.

<BR>&nbsp;<BR><FONT SIZE=5>indexSubTable1: variable metrics glyphs with 4 byte offsets</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>indexSubHeader</TD>
<TD VALIGN=TOP>header</TD><TD VALIGN=TOP>header info</TD></TR>
<TR>
<TD VALIGN=TOP>ULONG</TD><TD VALIGN=TOP>offsetArray[]</TD>
<TD VALIGN=TOP>offsetArray[glyphIndex]+imageDataOffset=
<BR>
glyphData<BR>
sizeOfArray=(lastGlyph-firstGlyph+1)+1+1 pad if needed</TD></TR>
</TABLE>&nbsp;&nbsp;<P>

<BR>&nbsp;<BR><FONT SIZE=5>indexSubTable2: all glyphs have identical metrics</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>indexSubHeader</TD>
<TD VALIGN=TOP>header</TD><TD VALIGN=TOP>header info</TD></TR>
<TR>
<TD VALIGN=TOP>ULONG</TD><TD VALIGN=TOP>imageSize</TD>
<TD VALIGN=TOP>all the glyphs are of the same size</TD></TR>
<TR>
<TD VALIGN=TOP>bigGlyphMetrics</TD>
<TD VALIGN=TOP>bigMetrics</TD><TD VALIGN=TOP>all glyphs have the same metrics; glyph data may be compressed, byte-aligned, or bit-aligned</TD></TR>
</TABLE>&nbsp;&nbsp;<P>

<BR>&nbsp;<BR><FONT SIZE=5>indexSubTable3: variable metrics glyphs with 2 byte offsets</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>indexSubHeader</TD>
<TD VALIGN=TOP>header</TD><TD VALIGN=TOP>header info</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>offsetArray[]
<TD VALIGN=TOP>offsetArray[glyphIndex]+imageDataOffset=<BR>
glyphData<BR>
sizeOfArray=(lastGlyph-firstGlyph+1)+1+1 pad if needed
</TR>
</TABLE>&nbsp;&nbsp;<P>

<BR>&nbsp;<BR><FONT SIZE=5>indexSubTable4: variable metrics glyphs with sparse glyph codes</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>indexSubHeader</TD>
<TD VALIGN=TOP>header</TD><TD VALIGN=TOP>header info</TD></TR>
<TR>
<TD VALIGN=TOP>ULONG</TD><TD VALIGN=TOP>numGlyphs</TD>
<TD VALIGN=TOP>array length</TD></TR>
<TR>
<TD VALIGN=TOP>codeOffsetPair</TD>
<TD VALIGN=TOP>glyphArray[]</TD><TD VALIGN=TOP>one per glyph; sizeOfArray=numGlyphs+1</TD></TR>
</TABLE>&nbsp;&nbsp;<P>
<PRE>
codeOffsetPair:
used by indexSubTable4
</PRE>

<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>USHORT</TD><TD VALIGN=TOP>glyphCode</TD>
<TD VALIGN=TOP>code of glyph present</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>offset</TD>
<TD VALIGN=TOP>location in EBDT</TD></TR>
</TABLE>&nbsp;&nbsp;<P>

indexSubTable5: constant metrics glyphs with sparse glyph codes
<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>indexSubHeader</TD>
<TD VALIGN=TOP>header</TD><TD VALIGN=TOP>header info</TD></TR>
<TR>
<TD VALIGN=TOP>ULONG</TD><TD VALIGN=TOP>imageSize</TD>
<TD VALIGN=TOP>all glyphs have the same data size</TD></TR>
<TR>
<TD VALIGN=TOP>bigGlyphMetrics</TD>
<TD VALIGN=TOP>bigMetrics</TD><TD VALIGN=TOP>all glyphs have the same metrics</TD></TR>
<TR>
<TD VALIGN=TOP>ULONG</TD><TD VALIGN=TOP>numGlyphs</TD>
<TD VALIGN=TOP>array length</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>glyphCodeArray[]</TD>
<TD VALIGN=TOP>one per glyph, sorted by glyph code; sizeOfArray=numGlyphs</TD></TR>
</TABLE>&nbsp;&nbsp;<P>
<P>
The size of the 'EBDT' image data can be calculated
from the indexSubTable information. For the constant metrics formats
(2 and 5) the image data size is constant, and is given in the
imageSize field. For the variable metrics formats (1, 3, and 4)
image data must be stored contiguously and in glyph code order,
so the image data size may be calculated by subtracting the offset
for the current glyph from the offset of the next glyph. Because
of this, it is necessary to store one extra element in the offsetArray
pointing just past the end of the range's image data. This will
allow the correct calculation of the image data size for the last
glyph in the range.
<P>
Contiguous, or nearly contiguous, ranges of glyph codes are handled
best by formats 1, 2, and 3 which store an offset for every glyph
code in the range. Very sparse ranges of glyph codes should use
format 4 or 5 which explicitly call out the glyph codes represented
in the range. A small number of missing glyphs can be efficiently
represented in formats 1 or 3 by having the offset for the missing
glyph be followed by the same offset for the next glyph, thus
indicating a data size of zero.
<P>
The only difference between formats 1 and 3 is the size of the
offsetArray elements: format 1 uses ULONG's while format 3 uses
USHORT's. Therefore format 1 can cover a greater range (&gt; 64k
bytes) while format 3 saves more space in the 'EBLC' table. Since
the offsetArray elements are added to the imageDataOffset base
address in the indexSubHeader, a very large set of glyph bitmap
data could be addressed by splitting it into multiple ranges,
each less than 64k bytes in size, allowing the use of the more
efficient format 3.
<P>
The 'EBLC' table specification requires double word (ULONG) alignment
for all subtables. This occurs naturally for indexSubTable formats
1, 2, and 4, but may not for formats 3 and 5, since they include
arrays of type USHORT. When there is an odd number of elements
in these arrays it is necessary to add an extra padding element
to maintain proper alignment.

&nbsp;<br>&nbsp;<br>
<FONT FACE="Arial, Helvetica" SIZE=1>
Microsoft Typography Web Site <A HREF="/truetype/otspec/CPYRIGHT.htm">&copy; 1996 Microsoft Corporation</A>
<BR>
Comments to the Microsoft Typography group: <A HREF="mailto:[e-mail]">[e-mail]</A>
<BR>
<A HREF="/truetype/default.htm">Home</a> | <a href="/truetype/creators.htm"> Information for Developers</a>
&nbsp;<BR>
Last updated 05 September 1996

</FONT>
</TD></TR>
</TABLE>
</BODY>
</HTML>