Repository navigation
PDF Spec 09 CIDFonts
Part of: PDF-Spec-09-Text
Navigation: PDF-Spec-09-Fonts | PDF-Spec-Index | PDF-Spec-09-Font-Descriptors
| lozenge | 327 | 215 | | Euro | 333 | 219 | | apple | 360 | 240 |
When the font has no Encoding entry, or the font descriptor's Symbolic flag is set (in which case the Encoding entry is ignored), this shall occur:
- If the font contains a (3, 0) subtable, the range of character codes shall be one of these: 0x0000 - 0x00FF, 0xF000 - 0xF0FF, 0xF100 - 0xF1FF, or 0xF200 - 0xF2FF. Depending on the range of codes, each byte from the string shall be prepended with the high byte of the range, to form a two-byte character, which shall be used to select the associated glyph description from the subtable.
- Otherwise, if the font contains a (1, 0) subtable, single bytes from the string shall be used to look up the associated glyph descriptions from the subtable.
If a character cannot be mapped in any of the ways described previously, a conforming reader may supply a mapping of its choosing.
A composite font, also called a Type 0 font, is one whose glyphs are obtained from a fontlike object called a CIDFont . A composite font shall be represented by a font dictionary whose Subtype value is Type0 . The Type 0 font is known as the root font , and its associated CIDFont is called its descendant.
- NOTE 1 Composite fonts in PDF are analogous to composite fonts in PostScript but with some limitations. In particular, PDF requires that the character encoding be defined by a CMap, which is only one of several encoding methods available in PostScript. Also, PostScript allows a Type 0 font to have multiple descendants, which might also be Type 0 fonts. PDF supports only a single descendant, which shall be a CIDFont.
When the current font is composite, the text-showing operators shall behave differently than with simple fonts. For simple fonts, each byte of a string to be shown selects one glyph, whereas for composite fonts, a sequence of one or more bytes are decoded to select a glyph from the descendant CIDFont.
- NOTE 2 This facility supports the use of very large character sets, such as those for the Chinese, Japanese, and Korean languages. It also simplifies the organization of fonts that have complex encoding requirements.
This sub-clause first introduces the architecture of CID-keyed fonts , which are the only kind of composite font supported in PDF. Then it describes the CIDFont and CMap dictionaries, which are the PDF objects that represent the correspondingly named components of a CID-keyed font. Finally, it describes the Type 0 font dictionary, which combines a CIDFont and a CMap to produce a font whose glyphs may be accessed by means of variable-length character codes in a string to be shown.
CID-keyed fonts provide a convenient and efficient method for defining multiple-byte character encodings and fonts with a large number of glyphs. These capabilities provide great flexibility for representing text in writing systems for languages with large character sets, such as Chinese, Japanese, and Korean (CJK).
The CID-keyed font architecture specifies the external representation of certain font programs, called CMap and CIDFont files, along with some conventions for combining and using those files. As mentioned earlier, PDF does not support the entire CID-keyed font architecture, which is independent of PDF; CID-keyed fonts may be used in other environments.
- NOTE For complete documentation on the architecture and the file formats, see Adobe Technical Notes #5092, CIDKeyed Font Technology Overview , and #5014, Adobe CMap and CIDFont Files Specification . This sub-clause describes only the PDF objects that represent these font programs.
The term CID-keyed font reflects the fact that CID (character identifier) numbers are used to index and access the glyph descriptions in the font. This method is more efficient for large fonts than the method of accessing by character name, as is used for some simple fonts. CIDs range from 0 to a maximum value that may be subject to an implementation limit (see Table C.1).
A character collection is an ordered set of glyphs. The order of the glyphs in the character collection shall determine the CID number for each glyph. Each CID-keyed font shall explicitly reference the character collection on which its CID numbers are based; see 9.7.3, "CIDSystemInfo Dictionaries".
A CMap (character map) file shall specify the correspondence between character codes and the CID numbers used to identify glyphs. It is equivalent to the concept of an encoding in simple fonts. Whereas a simple font allows a maximum of 256 glyphs to be encoded and accessible at one time, a CMap can describe a mapping from multiple-byte codes to thousands of glyphs in a large CID-keyed font.
EXAMPLE A CMap can describe Shift-JIS, one of several widely used encodings for Japanese.
A CMap file may reference an entire character collection or a subset of a character collection. The CMap file's mapping yields a font number (which in PDF shall be 0) and a character selector (which in PDF shall be a CID). Furthermore, a CMap file may incorporate another CMap file by reference, without having to duplicate it. These features enable character collections to be combined or supplemented and make all the constituent characters accessible to text-showing operations through a single encoding.
A CIDFont contains the glyph descriptions for a character collection. The glyph descriptions themselves are typically in a format similar to those used in simple fonts, such as Type 1. However, they are identified by CIDs rather than by names, and they are organized differently.
In PDF, the data from a CMap file and CIDFont shall be represented by PDF objects as described in 9.7.4, "CIDFonts" and 9.7.5, "CMaps". The CMap file and CIDFont programs themselves may be either referenced by name or embedded as stream objects in the PDF file.
A CID-keyed font, then, shall be the combination of a CMap with a CIDFont containing glyph descriptions. It shall be represented as a Type 0 font. It contains an Encoding entry whose value shall be a CMap dictionary, and its DescendantFonts entry shall reference the CIDFont dictionary with which the CMap has been combined.
CIDFont and CMap dictionaries shall contain a CIDSystemInfo entry specifying the character collection assumed by the CIDFont associated with the CMap-that is, the interpretation of the CID numbers used by the CIDFont. A character collection shall be uniquely identified by the Registry , Ordering , and Supplement entries in the CIDSystemInfo dictionary, as described in Table 116. In order to be compatible, the Registry and Ordering values must be the same.
The CIDSystemInfo entry in a CIDFont is a dictionary that shall specify the CIDFont's character collection. The CIDFont need not contain glyph descriptions for all the CIDs in a collection; it may contain a subset. The CIDSystemInfo entry in a CMap file shall be either a single dictionary or an array of dictionaries, depending on whether it associates codes with a single character collection or with multiple character collections; see 9.7.5, "CMaps".
For proper behaviour, the CIDSystemInfo entry of a CMap shall be compatible with that of the CIDFont or CIDFonts with which it is used.
Table 116 - Entries in a CIDSystemInfo dictionary
| Key | Type | Value |
|---|---|---|
| Registry | ASCII string | (Required) A string identifying the issuer of the character collection. For information about assigning a registry identifier, contact the Adobe Solutions Network or consult the ASN Web site (see the Bibliography). |
Table 116 - Entries in a CIDSystemInfo dictionary (continued)
| Key | Type | Value |
|---|---|---|
| Ordering | ASCII string | (Required) A string that uniquely names the character collection within the specified registry. |
| Supplement | integer | (Required) The supplement number of the character collection. An original character collection has a supplement number of 0. Whenever additional CIDs are assigned in a character collection, the supplement number shall be increased. Supplements shall not alter the ordering of existing CIDs in the character collection. This value shall not be used in determining compatibility between character collections. |
A CIDFont program contains glyph descriptions that are accessed using a CID as the character selector. There are two types of CIDFonts:
- A Type 0 CIDFont contains glyph descriptions based on CFF
NOTE The term 'Type 0' when applied to a CIDFont has a different meaning than for a 'Type 0 font'.
- A Type 2 CIDFont contains glyph descriptions based on the TrueType font format
A CIDFont dictionary is a PDF object that contains information about a CIDFont program. Although its Type value is Font , a CIDFont is not actually a font. It does not have an Encoding entry, it may not be listed in the Font subdictionary of a resource dictionary, and it may not be used as the operand of the Tf operator. It shall be used only as a descendant of a Type 0 font. The CMap in the Type 0 font shall be what defines the encoding that maps character codes to CIDs in the CIDFont. Table 117 lists the entries in a CIDFont dictionary.
Table 117 - Entries in a CIDFont dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Required) The type of PDF object that this dictionary describes; shall be Font for a CIDFont dictionary. |
| Subtype | name | (Required) The type of CIDFont shall be CIDFontType0 or CIDFontType2 . |
| BaseFont | name | (Required) The PostScript name of the CIDFont. For Type 0 CIDFonts, this shall be the value of the CIDFontName entry in the CIDFont program. For Type 2 CIDFonts, it shall be derived the same way as for a simple TrueType font; see 9.6.3, "TrueType Fonts". In either case, the name may have a subset prefix if appropriate; see 9.6.4, "Font Subsets". |
| CIDSystemInfo | dictionary | (Required) A dictionary containing entries that define the character collection of the CIDFont. See Table 116. |
| FontDescriptor | dictionary | (Required; shall be an indirect reference) A font descriptor describing the CIDFont's default metrics other than its glyph widths (see 9.8, "Font Descriptors"). |
| DW | integer | (Optional) The default width for glyphs in the CIDFont (see 9.7.4.3, "Glyph Metrics in CIDFonts"). Default value: 1000 (defined in user units). |
Table 117 - Entries in a CIDFont dictionary (continued)
| Key | Type | Value |
|---|---|---|
| W | array | (Optional) A description of the widths for the glyphs in the CIDFont. NOTE The array's elements have a variable format that can specify individual widths for consecutive CIDs or one width for a range of CIDs (see 9.7.4.3, "Glyph Metrics in CIDFonts"). Default value: none (the DW value shall be used for all glyphs). |
| DW2 | array | (Optional; applies only to CIDFonts used for vertical writing) An array of two numbers specifying the default metrics for vertical writing (see 9.7.4.3, "Glyph Metrics in CIDFonts"). Default value: [880 - 1000]. |
| W2 | array | (Optional; applies only to CIDFonts used for vertical writing) A description of the metrics for vertical writing for the glyphs in the CIDFont (see 9.7.4.3, "Glyph Metrics in CIDFonts"). Default value: none (the DW2 value shall be used for all glyphs). |
| CIDToGIDMap | stream or name | (Optional; Type 2 CIDFonts only) A specification of the mapping from CIDs to glyph indices. If the value is a stream, the bytes in the stream shall contain the mapping from CIDs to glyph indices: the glyph index for a particular CID value c shall be a 2-byte value stored in bytes 2 × c and 2 × c + 1, where the first byte shall be the high-order byte. If the value of CIDToGIDMap is a name, it shall be Identity , indicating that the mapping between CIDs and glyph indices is the identity mapping. Default value: Identity . This entry may appear only in a Type 2 CIDFont whose associated TrueType font program is embedded in the PDF file. |
Type 0 and Type 2 CIDFonts handle the mapping from CIDs to glyph descriptions in somewhat different ways.
For Type 0, the CIDFont program contains glyph descriptions that are identified by CIDs. The CIDFont program identifies the character collection by a CIDSystemInfo dictionary, which should be copied into the PDF CIDFont dictionary. CIDs shall be interpreted uniformly in all CIDFont programs supporting a given character collection, whether the program is embedded in the PDF file or obtained from an external source.
When the CIDFont contains an embedded font program that is represented in the Compact Font Format (CFF), the FontFile3 entry in the font descriptor (see Table 126) may be CIDFontType0C or OpenType . There are two cases, depending on the contents of the font program:
- The 'CFF' font program has a Top DICT that uses CIDFont operators: The CIDs shall be used to determine the GID value for the glyph procedure using the charset table in the CFF program. The GID value shall then be used to look up the glyph procedure using the CharStrings INDEX table.
NOTE Although in many fonts the CID value and GID value are the same, the CID and GID values may differ.
- The 'CFF' font program has a Top DICT that does not use CIDFont operators: The CIDs shall be used directly as GID values, and the glyph procedure shall be retrieved using the CharStrings INDEX.
For Type 2, the CIDFont program is actually a TrueType font program, which has no native notion of CIDs. In a TrueType font program, glyph descriptions are identified by glyph index values. Glyph indices are internal to the font and are not defined consistently from one font to another. Instead, a TrueType font program contains a 'cmap' table that provides mappings directly from character codes to glyph indices for one or more predefined encodings.
PDF 32000-1:2008
TrueType font programs are integrated with the CID-keyed font architecture in one of two ways, depending on whether the font program is embedded in the PDF file:
- If the TrueType font program is embedded, the Type 2 CIDFont dictionary shall contain a CIDToGIDMap entry that maps CIDs to the glyph indices for the appropriate glyph descriptions in that font program.
- If the TrueType font program is not embedded but is referenced by name, the Type 2 CIDFont dictionary shall not contain a CIDToGIDMap entry, since it is not meaningful to refer to glyph indices in an external font program. In this case, CIDs shall not participate in glyph selection, and only predefined CMaps may be used with this CIDFont (see 9.7.5, "CMaps"). The conforming reader shall select glyphs by translating characters from the encoding specified by the predefined CMap to one of the encodings in the TrueType font's 'cmap' table. The means by which this is accomplished are implementation-dependent.
Even though the CIDs are not used to select glyphs in a Type 2 CIDFont, they shall always be used to determine the glyph metrics, as described in the next sub-clause.
Every CIDFont shall contain a glyph description for CID 0, which is analogous to the . notdef character name in simple fonts (see 9.7.6.3, "Handling Undefined Characters").
As discussed in 9.2.4, "Glyph Positioning and Metrics", the width of a glyph refers to the horizontal displacement between the origin of the glyph and the origin of the next glyph when writing in horizontal mode. In this mode, the vertical displacement between origins shall be 0. Widths for a CIDFont are defined using the DW and W entries in the CIDFont dictionary. These widths shall be consistent with the actual widths given in the CIDFont program.
The W array allows the definition of widths for individual CIDs. The elements of the array shall be organized in groups of two or three, where each group shall be in one of these two formats:
In the first format, c shall be an integer specifying a starting CID value; it shall be followed by an array of n numbers that shall specify the widths for n consecutive CIDs, starting with c . The second format shall define the same width, w , for all CIDs in the range c first to c last .
EXAMPLE 1 In this example, the glyphs having CIDs 120, 121, and 122 are 400, 325, and 500 units wide, respectively. CIDs in the range 7080 through 8032 all have a width of 1000 units.
W
entry example:
/W [ 120 [ 400 325 500 ] 7080 8032 1000 ]
Glyphs from a CIDFont may be shown in vertical writing mode. This is selected by the WMode entry in the associated CMap dictionary; see 9.7.5, "CMaps". To be used in this way, the CIDFont shall define the vertical displacement for each glyph and the position vector that relates the horizontal and vertical writing origins.
The default position vector and vertical displacement vector shall be specified by the DW2 entry in the CIDFont dictionary. DW2 shall be an array of two values: the vertical component of the position vector v and the vertical component of the displacement vector w1 (see Figure 40). The horizontal component of the position vector shall be half the glyph width, and that of the displacement vector shall be 0.
EXAMPLE 2 If the DW2
/ DW2 [ 880
entry is -1000 ]
then a glyph's position vector and vertical displacement vector are
v w0 2 ÷ 880 ( , ) = w1 0 1000 -( , ) =
where w0 is the width (horizontal displacement) for the same glyph.
NOTE A negative value for the vertical component places the origin of the next glyph below the current glyph because vertical coordinates in a standard coordinate system increase from bottom to top.
The W2 array shall define vertical metrics for individual CIDs. The elements of the array shall be organized in groups of two or five, where each group shall be in one of these two formats:
In the first format, c is a starting CID and shall be followed by an array containing numbers interpreted in groups of three. Each group shall consist of the vertical component of the vertical displacement vector w 1 (whose horizontal component shall be 0) followed by the horizontal and vertical components for the position vector v . Successive groups shall define the vertical metrics for consecutive CIDs starting with c . The second format defines a range of CIDs from c first to c last , that shall be followed by three numbers that define the vertical metrics for all CIDs in this range.
EXAMPLE 3
/W2 [ 120 [ -1000 250 772 ] 7080 8032 -1000 500 900 ]
This W2 entry defines the vertical displacement vector for the glyph with CID 120 as (0, -1000) and the position vector as (250, 772). It also defines the displacement vector for CIDs in the range 7080 through 8032 as (0, -1000) and the position vector as (500, 900).
A CMap shall specify the mapping from character codes to character selectors. In PDF, the character selectors shall be CIDs in a CIDFont (as mentioned earlier, PostScript CMaps can use names or codes as well). A CMap serves a function analogous to the Encoding dictionary for a simple font. The CMap shall not refer directly to a specific CIDFont; instead, it shall be combined with it as part of a CID-keyed font, represented in PDF as a Type 0 font dictionary (see 9.7.6, "Type 0 Font Dictionaries"). Within the CMap, the character mappings shall refer to the associated CIDFont by font number , which in PDF shall be 0.
PDF also uses a special type of CMap to map character codes to Unicode values (see 9.10.3, "ToUnicode CMaps").
A CMap shall specify the writing mode-horizontal or vertical-for any CIDFont with which the CMap is combined. The writing mode determines which metrics shall be used when glyphs are painted from that font.
NOTE Writing mode is specified as part of the CMap because, in some cases, different shapes are used when writing horizontally and vertically. In such cases, the horizontal and vertical variants of a CMap specify different CIDs for a given character code.
A CMap shall be specified in one of two ways:
- As a name object identifying a predefined CMap, whose value shall be one of the predefined CMap names defined in Table 118.
- As a stream object whose contents shall be a CMap file.
Several of the CMaps define mappings from Unicode encodings to character collections. Unicode values appearing in a text string shall be represented in big-endian order (high-order byte first). CMap names containing 'UCS2' use UCS-2 encoding; names containing ' UTF16' use UTF-16BE (big-endian) encoding.
NOTE 1 Table 118 lists the names of the predefined CMaps. These CMaps map character codes to CIDs in a single descendant CIDFont. CMaps whose names end in H specify horizontal writing mode; those ending in V specify vertical writing mode.
Table 118 - Predefined CJK CMap names
| Name | Description |
|---|---|
| Chinese (Simplified) | Chinese (Simplified) |
| GB-EUC-H | Microsoft Code Page 936 (lfCharSet 0x86), GB 2312-80 character set, EUC-CN encoding |
| GB-EUC-V | Vertical version of GB-EUC-H |
| GBpc-EUC-H | Mac OS, GB 2312-80 character set, EUC-CN encoding, Script Manager code 19 |
| GBpc-EUC-V | Vertical version of GBpc-EUC-H |
| GBK-EUC-H | Microsoft Code Page 936 (lfCharSet 0x86), GBK character set, GBK encoding |
| GBK-EUC-V | Vertical version of GBK-EUC-H |
| GBKp-EUC-H | Same as GBK-EUC-H but replaces half-width Latin characters with proportional forms and maps character code 0x24 to a dollar sign ($) instead of a yuan symbol (¥) |
| GBKp-EUC-V | Vertical version of GBKp-EUC-H |
| GBK2K-H | GB 18030-2000 character set, mixed 1-, 2-, and 4-byte encoding |
| GBK2K-V | Vertical version of GBK2K-H |
| UniGB-UCS2-H | Unicode (UCS-2) encoding for the Adobe-GB1 character collection |
| UniGB-UCS2-V | Vertical version of UniGB-UCS2-H |
| UniGB-UTF16-H | Unicode (UTF-16BE) encoding for the Adobe-GB1 character collection; contains mappings for all characters in the GB18030-2000 character set |
| UniGB-UTF16-V | Vertical version of UniGB-UTF16-H |
| Chinese (Traditional) | Chinese (Traditional) |
| B5pc-H | Mac OS, Big Five character set, Big Five encoding, Script Manager code 2 |
| B5pc-V | Vertical version of B5pc-H |
| HKscs-B5-H | Hong Kong SCS, an extension to the Big Five character set and encoding |
| HKscs-B5-V | Vertical version of HKscs-B5-H |
| ETen-B5-H | Microsoft Code Page 950 (lfCharSet 0x88), Big Five character set with ETen extensions |
| ETen-B5-V | Vertical version of ETen-B5-H |
| ETenms-B5-H | Same as ETen-B5-H but replaces half-width Latin characters with proportional forms |
Table 118 - Predefined CJK CMap names (continued)
| Name | Description |
|---|---|
| ETenms-B5-V | Vertical version of ETenms-B5-H |
| CNS-EUC-H | CNS 11643-1992 character set, EUC-TW encoding |
| CNS-EUC-V | Vertical version of CNS-EUC-H |
| UniCNS-UCS2-H | Unicode (UCS-2) encoding for the Adobe-CNS1 character collection |
| UniCNS-UCS2-V | Vertical version of UniCNS-UCS2-H |
| UniCNS-UTF16-H | Unicode (UTF-16BE) encoding for the Adobe-CNS1 character collection; contains mappings for all the characters in the HKSCS-2001 character set and contains both 2- and 4-byte character codes |
| UniCNS-UTF16-V | Vertical version of UniCNS-UTF16-H |
| Japanese | |
| 83pv-RKSJ-H | Mac OS, JIS X 0208 character set with KanjiTalk6 extensions, Shift-JIS encoding, Script Manager code 1 |
| 90ms-RKSJ-H | Microsoft Code Page 932 (lfCharSet 0x80), JIS X 0208 character set with NEC and IBM® extensions |
| 90ms-RKSJ-V | Vertical version of 90ms-RKSJ-H |
| 90msp-RKSJ-H | Same as 90ms-RKSJ-H but replaces half-width Latin characters with proportional forms |
| 90msp-RKSJ-V | Vertical version of 90msp-RKSJ-H |
| 90pv-RKSJ-H | Mac OS, JIS X 0208 character set with KanjiTalk7 extensions, Shift-JIS encoding, Script Manager code 1 |
| Add-RKSJ-H | JIS X 0208 character set with Fujitsu FMR extensions, Shift-JIS encoding |
| Add-RKSJ-V | Vertical version of Add-RKSJ-H |
| EUC-H | JIS X 0208 character set, EUC-JP encoding |
| EUC-V | Vertical version of EUC-H |
| Ext-RKSJ-H | JIS C 6226 (JIS78) character set with NEC extensions, Shift-JIS encoding |
| Ext-RKSJ-V | Vertical version of Ext-RKSJ-H |
| H | JIS X 0208 character set, ISO-2022-JP encoding |
| V | Vertical version of H |
| UniJIS-UCS2-H | Unicode (UCS-2) encoding for the Adobe-Japan1 character collection |
| UniJIS-UCS2-V | Vertical version of UniJIS-UCS2-H |
| UniJIS-UCS2-HW-H | Same as UniJIS-UCS2-H but replaces proportional Latin characters with half- width forms |
| UniJIS-UCS2-HW-V | Vertical version of UniJIS-UCS2-HW-H |
| UniJIS-UTF16-H | Unicode (UTF-16BE) encoding for the Adobe-Japan1 character collection; contains mappings for all characters in the JIS X 0213:1000 character set |
| UniJIS-UTF16-V | Vertical version of UniJIS-UTF16-H |
| Korean |
Table 118 - Predefined CJK CMap names (continued)
| Name | Description |
|---|---|
| KSC-EUC-H | KS X 1001:1992 character set, EUC-KR encoding |
| KSC-EUC-V | Vertical version of KSC-EUC-H |
| KSCms-UHC-H | Microsoft Code Page 949 (lfCharSet 0x81), KS X 1001:1992 character set plus 8822 additional hangul, Unified Hangul Code (UHC) encoding |
| KSCms-UHC-V | Vertical version of KSCms - UHC-H |
| KSCms-UHC-HW-H | Same as KSCms-UHC-H but replaces proportional Latin characters with half- width forms |
| KSCms-UHC-HW-V | Vertical version of KSCms-UHC-HW-H |
| KSCpc-EUC-H | Mac OS, KS X 1001:1992 character set with Mac OS KH extensions, Script Manager Code 3 |
| UniKS-UCS2-H | Unicode (UCS-2) encoding for the Adobe-Korea1 character collection |
| UniKS-UCS2-V | Vertical version of UniKS-UCS2-H |
| UniKS-UTF16-H | Unicode (UTF-16BE) encoding for the Adobe-Korea1 character collection |
| UniKS-UTF16-V | Vertical version of UniKS-UTF16-H |
| Generic | |
| Identity-H | The horizontal identity mapping for 2-byte CIDs; may be used with CIDFonts using any Registry , Ordering , and Supplement values. It maps 2-byte character codes ranging from 0 to 65,535 to the same 2-byte CID value, interpreted high- order byte first. |
| Identity-V | Vertical version of Identity-H. The mapping is the same as for Identity-H. |
NOTE 2 The Identity-H and Identity-V CMaps may be used to refer to glyphs directly by their CIDs when showing a text string.
When the current font is a Type 0 font whose Encoding entry is Identity-H or Identity-V, the string to be shown shall contain pairs of bytes representing CIDs, high-order byte first. When the current font is a CIDFont, the string to be shown shall contain pairs of bytes representing CIDs, high-order byte first. When the current font is a Type 2 CIDFont in which the CIDToGIDMap entry is Identity and if the TrueType font is embedded in the PDF file, the 2-byte CID values shall be identical glyph indices for the glyph descriptions in the TrueType font program.
Navigation: PDF-Spec-09-Fonts | PDF-Spec-Index | PDF-Spec-09-Font-Descriptors