📄 cmap.htm
字号:
<HTML>
<HEAD>
<TITLE>The 'cmap' 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=480 CELLPADDING=8 CELLSPACING=0 BORDER=0>
<TR><TD><IMG WIDTH=100 HEIGHT=1 ALT="DIAGRAM" SRC="/TRUETYPE/OTSPEC/pixel.gif" BORDER=0></TD>
<TD><H1>Table Formats</H1></TD>
</TR>
<TR><TD></TD><TD ALIGN=TOP>
<H2>cmap - Character To Glyph Index Mapping Table</H2>
<P>
This table defines the mapping of character
codes to the glyph index values used in the font. It may contain
more than one subtable, in order to support more than one character
encoding scheme. Character codes that do not correspond to any
glyph in the font should be mapped to glyph index 0. The glyph
at this location must be a special glyph representing a missing
character.
<P>
The table header indicates the character encodings for which subtables
are present. Each subtable is in one of four possible formats
and begins with a format code indicating the format used.
<P>
The platform ID and platform-specific encoding ID are used to
specify the subtable; this means that each platform ID/platform-specific
encoding ID pair may only appear once in the cmap table. Each
subtable can specify a different character encoding. (<CITE>See the
'name' table section).</CITE> The entries must be sorted first by
platform ID and then by platform-specific encoding ID.
<P>
When building a Unicode font for Windows, the platform ID should
be 3 and the encoding ID should be 1. When building a symbol font
for Windows, the platform ID should be 3 and the encoding ID should
be 0. When building a font that will be used on the Macintosh,
the platform ID should be 1 and the encoding ID should be 0.
<P>
All Microsoft Unicode encodings (Platform ID = 3, Encoding ID
= 1) must use Format 4 for their 'cmap' subtable. Microsoft <STRONG>strongly</STRONG>
recommends using a Unicode 'cmap' for all fonts. However, some
other encodings that appear in current fonts follow:
<TABLE BGCOLOR="F0F0F0" WIDTH=480>
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Platform ID</TH><TH BGCOLOR="#C0C0C0">Encoding ID</TH><TH BGCOLOR="#C0C0C0">Description</TH></TR>
</THEAD><TBODY>
<TR>
<TD VALIGN=TOP>3</TD><TD VALIGN=TOP>0</TD><TD VALIGN=TOP>Symbol</TD></TR>
<TR>
<TD VALIGN=TOP>3</TD><TD VALIGN=TOP>1</TD><TD VALIGN=TOP>Unicode</TD></TR>
<TR>
<TD VALIGN=TOP>3</TD><TD VALIGN=TOP>2
</TD><TD VALIGN=TOP>ShiftJIS</TD></TR>
<TR>
<TD VALIGN=TOP>3</TD><TD VALIGN=TOP>3
</TD><TD VALIGN=TOP>Big5</TD></TR>
<TR>
<TD VALIGN=TOP>3</TD><TD VALIGN=TOP>4
</TD><TD VALIGN=TOP>PRC</TD></TR>
<TR>
<TD VALIGN=TOP>3</TD><TD VALIGN=TOP>5
</TD><TD VALIGN=TOP>Wansung</TD></TR>
<TR>
<TD VALIGN=TOP>3</TD><TD VALIGN=TOP>6
</TD><TD VALIGN=TOP>Johab</TD></TR>
</TABLE>
<P>
The Character To Glyph Index Mapping Table
is organized as follows:
<TABLE BGCOLOR="F0F0F0" WIDTH=480>
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH>
<TH BGCOLOR="#C0C0C0">Description</TH></TR>
</THEAD><TBODY>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>Table version number (0).
</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>Number of encoding tables, <CITE>n.</CITE></TD></TR>
</TABLE>
<P>
This is followed by an entry for each of the
<CITE>n </CITE>encoding table specifying the particular encoding, and
the offset to the actual subtable:
<TABLE BGCOLOR="F0F0F0" WIDTH=480>
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Description</TH></TR>
</THEAD><TBODY>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>Platform ID.</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>Platform-specific encoding ID.</TD></TR>
<TR>
<TD VALIGN=TOP>ULONG</TD><TD VALIGN=TOP>Byte offset from beginning of table to the subtable for this encoding.</TD></TR>
</TABLE>
<H4>Format 0: Byte encoding table</H4>
<P>
This is the Apple standard character to glyph index mapping table.
<TABLE BGCOLOR="F0F0F0" WIDTH=480>
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TH></TR>
</THEAD><TBODY>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>format</TD><TD VALIGN=TOP>Format number is set to 0. </TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>length</TD><TD VALIGN=TOP>This is the length in bytes of the subtable.</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>version</TD>
<TD VALIGN=TOP>Version number (starts at 0).</TD></TR>
<TR>
<TD VALIGN=TOP>BYTE</TD><TD VALIGN=TOP>glyphIdArray[256]</TD>
<TD VALIGN=TOP>An array that maps character codes to glyph index values.</TD></TR>
</TABLE>
<P>
This is a simple 1 to 1 mapping of character
codes to glyph indices. The glyph set is limited to 256. Note
that if this format is used to index into a larger glyph set,
only the first 256 glyphs will be accessible.
<P><BR><H4>Format 2: High-byte mapping through
table</H4>
<P>
This subtable is useful for the national character
code standards used for Japanese, Chinese, and Korean characters.
These code standards use a mixed 8/16-bit encoding, in which certain
byte values signal the first byte of a 2-byte character (but these
values are also legal as the second byte of a 2-byte character).
Character codes are always 1-byte. The glyph set is limited to
256.
<P>
In addition, even for the 2-byte characters, the mapping of character
codes to glyph index values depends heavily on the first byte.
Consequently, the table begins with an array that maps the first
byte to a 4-word subHeader. For 2-byte character codes, the subHeader
is used to map the second byte's value through a subArray, as
described below. When processing mixed 8/16-bit text, subHeader
0 is special: it is used for single-byte character codes. When
subHeader zero is used, a second byte is not needed; the single
byte value is mapped through the subArray.
<TABLE BGCOLOR="F0F0F0" WIDTH=480>
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH><TH BGCOLOR="#C0C0C0">Name</TH>
<TH BGCOLOR="#C0C0C0">Description</TH></TR>
</THEAD><TBODY>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>format</TD>
<TD VALIGN=TOP>Format number is set to 2.</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>length</TD>
<TD VALIGN=TOP>Length in bytes.</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>version</TD>
<TD VALIGN=TOP>Version number (starts at 0)</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>subHeaderKeys[256]</TD>
<TD VALIGN=TOP>Array that maps high bytes to subHeaders: value is subHeader index * 8.</TD></TR>
<TR>
<TD VALIGN=TOP NOWRAP=NOWRAP>4 words struct</TD>
<TD VALIGN=TOP>subHeaders[ ]</TD><TD VALIGN=CENTER>Variable-length array of subHeader structures.</TD></TR>
<TR>
<TD VALIGN=TOP NOWRAP=NOWRAP>4 words-struct</TD>
<TD VALIGN=TOP>subHeaders[ ]</TD><TD VALIGN=TOP> </TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>glyphIndexArray[ ]</TD>
<TD VALIGN=TOP>Variable-length array containing subarrays used for mapping the low byte of 2-byte characters.</TD></TR>
</TABLE>
<P>
A subHeader is structured as follows:
<TABLE BGCOLOR="F0F0F0" WIDTH=480>
<THEAD>
<TR>
<TH BGCOLOR="#C0C0C0">Type</TH>
<TH BGCOLOR="#C0C0C0">Name</TH><TH BGCOLOR="#C0C0C0">Description</TH></TR>
</THEAD><TBODY>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>firstCode</TD>
<TD VALIGN=TOP>First valid low byte for this subHeader.</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>entryCount</TD>
<TD VALIGN=TOP>Number of valid low bytes for this subHeader. </TD></TR>
<TR>
<TD VALIGN=TOP>SHORT</TD><TD VALIGN=TOP>idDelta</TD>
<TD VALIGN=TOP>See text below.</TD></TR>
<TR>
<TD VALIGN=TOP>USHORT</TD><TD VALIGN=TOP>idRangeOffset</TD>
<TD VALIGN=TOP>See text below.</TD></TR>
</TABLE>
<P>
The firstCode and entryCount values specify
a subrange that begins at firstCode and has a length equal to
the value of entryCount. This subrange stays within the 0-255
range of the byte being mapped. Bytes outside of this subrange
are mapped to glyph index 0 (missing glyph).The offset of the
byte within this subrange is then used as index into a corresponding
subarray of glyphIndexArray. This subarray is also of length entryCount.
The value of the idRangeOffset is the number of bytes past the
actual location of the idRangeOffset word where the glyphIndexArray
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -