Repository navigation
PDF Spec 09 Encoding
Part of: PDF-Spec-09-Text
Navigation: PDF-Spec-09-Font-Descriptors | PDF-Spec-Index | Next →
% Bits 2, 6, and 19
- The font family class and subclass ID bytes, given in the sFamilyClass field of the 'OS/2' table in a TrueType font. This field is documented in Microsoft's TrueType 1.0 Font Files Technical Specification .
- Ten bytes for the PANOSE classification number for the font. The PANOSE classification system is documented in Hewlett-Packard Company's PANOSE Classification Metrics Guide .
See the Bibliography for more information about these documents.
EXAMPLE This is an example of a Style entry in the font descriptor:
/Style << /Panose < 01 05 02 02 03 00 00 00 00 00 00 00 > >>
A CIDFont may be made up of different classes of glyphs, each class requiring different sets of the font-wide attributes that appear in font descriptors.
EXAMPLE 1 Latin glyphs, for example, may require different attributes than kanji glyphs.
The font descriptor shall define a set of default attributes that apply to all glyphs in the CIDFont. The FD entry in the font descriptor shall contain exceptions to these defaults.
The key for each entry in an FD dictionary shall be the name of a class of glyphs-that is, a particular subset of the CIDFont's character collection. The entry's value shall be a font descriptor whose contents shall override the font-wide attributes for that class only. This font descriptor shall contain entries for metric information only; it shall not include FontFile , FontFile2 , FontFile3 , or any of the entries listed in Table 122.
The FD dictionary should contain at least the metrics for the proportional Latin glyphs. With the information for these glyphs, a more accurate substitution font can be created.
The names of the glyph classes depend on the character collection, as identified by the Registry , Ordering , and Supplement entries in the CIDSystemInfo dictionary. Table 125 lists the valid keys for the Adobe-GB1, Adobe-CNS1, Adobe-Japan1, Adobe-Japan2, and Adobe-Korea1 character collections.
Table 125 - Glyph classes in CJK fonts
| Character Collection | Class | Glyphs in Class |
|---|---|---|
| Adobe-GB1 | Alphabetic Dingbats Generic Hanzi HRoman HRomanRot Kana Proportional ProportionalRot | Full-width Latin, Greek, and Cyrillic glyphs Special symbols Typeface-independent glyphs, such as line-drawing Full-width hanzi (Chinese) glyphs Half-width Latin glyphs Same as HRoman but rotated for use in vertical writing Japanese kana (katakana and hiragana) glyphs Proportional Latin glyphs Same as Proportional but rotated for use in vertical writing |
| Adobe-CNS1 | Alphabetic Dingbats Generic Hanzi HRoman HRomanRot Kana Proportional ProportionalRot | Full-width Latin, Greek, and Cyrillic glyphs Special symbols Typeface-independent glyphs, such as line-drawing Full-width hanzi (Chinese) glyphs Half-width Latin glyphs Same as HRoman but rotated for use in vertical writing Japanese kana (katakana and hiragana) glyphs Proportional Latin glyphs Same as Proportional but rotated for use in vertical writing |
| Adobe-Japan1 | Alphabetic AlphaNum Dingbats DingbatsRot Generic GenericRot HKana HKanaRot HRoman HRomanRot Kana Kanji Proportional ProportionalRot Ruby | Full-width Latin, Greek, and Cyrillic glyphs Numeric glyphs Special symbols Same as Dingbats but rotated for use in vertical writing Typeface-independent glyphs, such as line-drawing Same as Generic but rotated for use in vertical writing Half-width kana (katakana and hiragana) glyphs Same as HKana but rotated for use in vertical writing Half-width Latin glyphs Same as HRoman but rotated for use in vertical writing Full-width kana (katakana and hiragana) glyphs Full-width kanji (Chinese) glyphs Proportional Latin glyphs Same as Proportional but rotated for use in vertical writing Glyphs used for setting ruby (small glyphs that serve to annotate other glyphs with meanings or readings) |
| Adobe-Japan2 | Alphabetic Dingbats HojoKanji | Full-width Latin, Greek, and Cyrillic glyphs Special symbols Full-width kanji glyphs |
Table 125 - Glyph classes in CJK fonts (continued)
| Character Collection | Class | Glyphs in Class |
|---|---|---|
| Adobe-Korea1 | Alphabetic Dingbats Generic Hangul Hanja HRoman HRomanRot Kana Proportional ProportionalRot | Full-width Latin, Greek, and Cyrillic glyphs Special symbols Typeface-independent glyphs, such as line-drawing Hangul and jamo glyphs Full-width hanja (Chinese) glyphs Half-width Latin glyphs Same as HRoman but rotated for use in vertical writing Japanese kana (katakana and hiragana) glyphs Proportional Latin glyphs Same as Proportional but rotated for use in vertical writing |
EXAMPLE 2 This example illustrates an FD dictionary containing two entries.
/FD << /Proportional 25 0 R /HKana 26 0 R >> 25 0 obj << /Type /FontDescriptor /FontName /HeiseiMin-W3-Proportional /Flags 2 /AvgWidth 478 /MaxWidth 1212 /MissingWidth 250 /StemV 105 /StemH 45 /CapHeight 660 /XHeight 394 /Ascent 720 /Descent -270 /Leading 83 >> endobj 26 0 obj << /Type /FontDescriptor /FontName /HeiseiMin-W3-HKana /Flags 3 /AvgWidth 500 /MaxWidth 500 /MissingWidth 500 /StemV 50 /StemH 75 /Ascent 720 /Descent 0 /Leading 83 >> endobj
A font program may be embedded in a PDF file as data contained in a PDF stream object.
NOTE 1 Such a stream object is also called a font file by analogy with font programs that are available from sources external to the conforming writer.
Font programs are subject to copyright, and the copyright owner may impose conditions under which a font program may be used. These permissions are recorded either in the font program or as part of a separate license. One of the conditions may be that the font program cannot be embedded, in which case it should not be incorporated into a PDF file. A font program may allow embedding for the sole purpose of viewing and printing the document but not for creating new or modified text that uses the font (in either the same document or other documents). The latter operation would require the user performing the operation to have a licensed copy of the font program, not a copy extracted from the PDF file. In the absence of explicit information to the contrary, embedded font programs shall be used only to view and print the document and not for any other purposes.
Table 126 summarizes the ways in which font programs shall be embedded in a PDF file, depending on the representation of the font program. The key shall be the name used in the font descriptor to refer to the font file stream; the subtype shall be the value of the Subtype key, if present, in the font file stream dictionary. Further details of specific font program representations are given below.
Table 126 - Embedded font organization for various font types
| Key | Subtype | Description |
|---|---|---|
| FontFile | - | Type 1 font program, in the original (noncompact) format described in Adobe Type 1 Font Format . This entry may appear in the font descriptor for a Type1 or MMType1 font dictionary. |
| FontFile2 | - | (PDF 1.1) TrueType font program, as described in the TrueType Reference Manual . This entry may appear in the font descriptor for a TrueType font dictionary or ( PDF 1.3 ) for a CIDFontType2 CIDFont dictionary. |
| FontFile3 | Type1C | (PDF 1.2) Type 1-equivalent font program represented in the Compact Font Format (CFF), as described in Adobe Technical Note #5176, The Compact Font Format Specification . This entry may appear in the font descriptor for a Type1 or MMType1 font dictionary. |
| FontFile3 | CIDFontType0C | (PDF 1.3) Type 0 CIDFont program represented in the Compact Font Format (CFF), as described in Adobe Technical Note #5176, The Compact Font Format Specification . This entry may appear in the font descriptor for a CIDFontType0 CIDFont dictionary. |
Table 126 - Embedded font organization for various font types (continued)
| Key | Subtype | Description |
|---|---|---|
| FontFile3 | OpenType | ( PDF 1.6 ) OpenType® font program, as described in the OpenType Specification v.1.4 (see the Bibliography). OpenType is an extension of TrueType that allows inclusion of font programs that use the Compact Font Format (CFF). A FontFile3 entry with an OpenType subtype may appear in the font descriptor for these types of font dictionaries: • A TrueType font dictionary or a CIDFontType2 CIDFont dictionary, if the embedded font program contains a 'glyf' table. In addition to the 'glyf' table, the font program must include these tables: 'head', 'hhea', 'hmtx', 'loca', and 'maxp'. The 'cvt ' (notice the trailing SPACE), 'fpgm', and 'prep' tables must also be included if they are required by the font instructions. • A CIDFontType0 CIDFont dictionary, if the embedded font program contains a 'CFF ' table (notice the trailing SPACE) with a Top DICT that uses CIDFont operators (this is equivalent to subtype CIDFontType0C ). In addition to the 'CFF ' table, the font program must include the 'cmap' table. • A Type1 font dictionary or CIDFontType0 CIDFont dictionary, if the embedded font program contains a 'CFF ' table without CIDFont operators. In addition to the 'CFF ' table, the font program must include the 'cmap' table. The OpenType Specification describes a set of required tables; however, not all tables are required in the font file, as described for each type of font dictionary that can include this entry. NOTE The absence of some optional tables (such as those used for advanced line layout) may prevent editing of text containing the font. |
The stream dictionary for a font file shall contain the normal entries for a stream, such as Length and Filter (listed in Table 5), plus the additional entries listed in Table 127.
Table 127 - Additional entries in an embedded font stream dictionary
| Key | Type | Value |
|---|---|---|
| Length1 | integer | (Required for Type 1 and TrueType fonts) The length in bytes of the clear-text portion of the Type 1 font program, or the entire TrueType font program, after it has been decoded using the filters specified by the stream's Filter entry, if any. |
| Length2 | integer | (Required for Type 1 fonts) The length in bytes of the encrypted portion of the Type 1 font program after it has been decoded using the filters specified by the stream's Filter entry. |
| Length3 | integer | (Required for Type 1 fonts) The length in bytes of the fixed-content portion of the Type 1 font program after it has been decoded using the filters specified by the stream's Filter entry. If Length3 is 0, it indicates that the 512 zeros and cleartomark have not been included in the FontFile font program and shall be added by the conforming reader. |
| Subtype | name | (Required if referenced from FontFile3 ; PDF 1.2) A name specifying the format of the embedded font program. The name shall be Type1C for Type 1 compact fonts, CIDFontType0C for Type 0 compact CIDFonts, or OpenType for OpenType fonts. |
| Metadata | stream | (Optional; PDF 1.4) A metadata stream containing metadata for the embedded font program (see 14.3.2, "Metadata Streams"). |
- NOTE 2 A standard Type 1 font program, as described in the Adobe Type 1 Font Format specification, consists of three parts: a clear-text portion (written using PostScript syntax), an encrypted portion, and a fixed-content portion. The fixed-content portion contains 512 ASCII zeros followed by a cleartomark operator, and perhaps followed
by additional data. Although the encrypted portion of a standard Type 1 font may be in binary or ASCII hexadecimal format, PDF supports only the binary format. However, the entire font program may be encoded using any filters.
- EXAMPLE This code shows the structure of an embedded standard Type 1 font.
12 0 obj << /Filter /ASCII85Decode /Length 41116 /Length1 2526 /Length2 32393 /Length3 570 >> stream ,p>`rDKJj'E+LaU0eP.@+AH9dBOu$hFD55nC … Omitted data … JJQ&Nt')<=^p&mGf(%:%h1%9c//K(/*o=.C>UXkbVGTrr~> endstream endobj
As noted in Table 126, a Type 1-equivalent font program or a Type 0 CIDFont program may be represented in the Compact Font Format (CFF). The Length1 , Length2 , and Length3 entries are not needed in that case and shall not be present. Although CFF enables multiple font or CIDFont programs to be bundled together in a single file, an embedded CFF font file in PDF shall consist of exactly one font or CIDFont (as appropriate for the associated font dictionary).
According to the Adobe Type 1 Font Format specification, a Type 1 font program may contain a PaintType entry specifying whether the glyphs' outlines are to be filled or stroked. For fonts embedded in a PDF file, this entry shall be ignored; the decision whether to fill or stroke glyph outlines is entirely determined by the PDF text rendering mode parameter (see 9.3.6, "Text Rendering Mode"). This shall also applies to Type 1 compact fonts and Type 0 compact CIDFonts.
A TrueType font program may be used as part of either a font or a CIDFont. Although the basic font file format is the same in both cases, there are different requirements for what information shall be present in the font program. These TrueType tables shall always be present if present in the original TrueType font program: 'head', 'hhea', 'loca', 'maxp', 'cvt', 'prep', 'glyf', 'hmtx', and 'fpgm'. If used with a simple font dictionary, the font program shall additionally contain a cmap table defining one or more encodings, as discussed in 9.6.6.4, "Encodings for TrueType Fonts". If used with a CIDFont dictionary, the cmap table is not needed and shall not be present, since the mapping from character codes to glyph descriptions is provided separately.
The 'vhea' and 'vmtx' tables that specify vertical metrics shall never be used by a conforming reader. The only way to specify vertical metrics in PDF shall be by means of the DW2 and W2 entries in a CIDFont dictionary.
- NOTE 3 Beginning with PDF 1.6, font programs may be embedded using the OpenType format, which is an extension of the TrueType format that allows inclusion of font programs using the Compact Font Format (CFF). It also allows inclusion of data to describe glyph substitutions, kerning, and baseline adjustments. In addition to rendering glyphs, conforming readers may use the data in OpenType fonts to do advanced line layout, automatically substitute ligatures, provide selections of alternate glyphs to users, and handle complex writing scripts.
The process of finding glyph descriptions in OpenType fonts by a conforming reader shall be the following:
-
For Type 1 fonts using 'CFF' tables, the process shall be as described in 9.6.6.2, "Encodings for Type 1 Fonts".
-
For TrueType fonts using 'glyf' tables, the process shall be as described in 9.6.6.4, "Encodings for TrueType Fonts". Since this process sometimes produces ambiguous results, conforming writers, instead of using a simple font, shall use a Type 0 font with an Identity-H encoding and use the glyph indices as character codes, as described following Table 118.
-
For CIDFontType0 fonts using 'CFF' tables, the process shall be as described in the discussion of embedded Type 0 CIDFonts in 9.7.4.2, "Glyph Selection in CIDFonts".
-
For CIDFontType2 fonts using 'glyf' tables, the process shall be as described in the discussion of embedded Type 2 CIDFonts in 9.7.4.2, "Glyph Selection in CIDFonts".
As discussed in 9.6.4, "Font Subsets", an embedded font program may contain only the subset of glyphs that are used in the PDF document. This may be indicated by the presence of a CharSet or CIDSet entry in the font descriptor that refers to the font file.
The preceding sub-clauses describe all the facilities for showing text and causing glyphs to be painted on the page. In addition to displaying text, conforming readers sometimes need to determine the information content of text-that is, its meaning according to some standard character identification as opposed to its rendered appearance. This need arises during operations such as searching, indexing, and exporting of text to other file formats.
The Unicode standard defines a system for numbering all of the common characters used in a large number of languages. It is a suitable scheme for representing the information content of text, but not its appearance, since Unicode values identify characters, not glyphs. For information about Unicode, see the Unicode Standard by the Unicode Consortium (see the Bibliography).
When extracting character content, a conforming reader can easily convert text to Unicode values if a font's characters are identified according to a standard character set that is known to the conforming reader. This character identification can occur if either the font uses a standard named encoding or the characters in the font are identified by standard character names or CIDs in a well-known collection. 9.10.2, "Mapping Character Codes to Unicode Values", describes in detail the overall algorithm for mapping character codes to Unicode values.
If a font is not defined in one of these ways, the glyphs can still be shown, but the characters cannot be converted to Unicode values without additional information:
- This information can be provided as an optional ToUnicode entry in the font dictionary (PDF 1.2 ; see 9.10.3, "ToUnicode CMaps" ) , whose value shall be a stream object containing a special kind of CMap file that maps character codes to Unicode values.
- An ActualText entry for a structure element or marked-content sequence (see 14.9.4, "Replacement Text") may be used to specify the text content directly.
A conforming reader can use these methods, in the priority given, to map a character code to a Unicode value. Tagged PDF documents, in particular, shall provide at least one of these methods (see 14.8.2.4.2, "Unicode Mapping in Tagged PDF"):
-
If the font dictionary contains a ToUnicode CMap (see 9.10.3, "ToUnicode CMaps"), use that CMap to convert the character code to Unicode.
-
If the font is a simple font that uses one of the predefined encodings MacRomanEncoding , MacExpertEncoding , or WinAnsiEncoding , or that has an encoding whose Differences array includes only character names taken from the Adobe standard Latin character set and the set of named characters in the Symbol font (see Annex D):
-
a) Map the character code to a character name according to Table D.1 and the font's Differences array.
-
b) Look up the character name in the Adobe Glyph List (see the Bibliography) to obtain the corresponding Unicode value.
-
If the font is a composite font that uses one of the predefined CMaps listed in Table 118 (except Identity-H and Identity-V) or whose descendant CIDFont uses the Adobe-GB1, Adobe-CNS1, Adobe-Japan1, or Adobe-Korea1 character collection:
-
a) Map the character code to a character identifier (CID) according to the font's CMap.
-
b) Obtain the registry and ordering of the character collection used by the font's CMap (for example, Adobe and Japan1) from its CIDSystemInfo dictionary.
-
c) Construct a second CMap name by concatenating the registry and ordering obtained in step (b) in the format registry -ordering -UCS2 (for example, Adobe-Japan1-UCS2).
-
d) Obtain the CMap with the name constructed in step (c) (available from the ASN Web site; see the Bibliography).
-
e) Map the CID obtained in step (a) according to the CMap obtained in step (d), producing a Unicode value.
- NOTE Type 0 fonts whose descendant CIDFonts use the Adobe-GB1, Adobe-CNS1, Adobe-Japan1, or AdobeKorea1 character collection (as specified in the CIDSystemInfo dictionary) shall have a supplement number corresponding to the version of PDF supported by the conforming reader. See Table 3 for a list of the character collections corresponding to a given PDF version. (Other supplements of these character collections can be used, but if the supplement is higher-numbered than the one corresponding to the supported PDF version, only the CIDs in the latter supplement are considered to be standard CIDs.)
If these methods fail to produce a Unicode value, there is no way to determine what the character code represents in which case a conforming reader may choose a character code of their choosing.
The CMap defined in the ToUnicode entry of the font dictionary shall follow the syntax for CMaps introduced in 9.7.5, "CMaps" and fully documented in Adobe Technical Note #5014, Adobe CMap and CIDFont Files Specification . Additional guidance regarding the CMap defined in this entry is provided in Adobe Technical Note #5411, ToUnicode Mapping File Tutorial . This CMap differs from an ordinary one in these ways:
- The only pertinent entry in the CMap stream dictionary (see Table 120) is UseCMap , which may be used if the CMap is based on another ToUnicode CMap.
- The CMap file shall contain begincodespacerange and endcodespacerange operators that are consistent with the encoding that the font uses. In particular, for a simple font, the codespace shall be one byte long.
- It shall use the beginbfchar , endbfchar , beginbfrange , and endbfrange operators to define the mapping from character codes to Unicode character sequences expressed in UTF-16BE encoding.
- EXAMPLE 1 This example illustrates a Type 0 font that uses the Identity-H CMap to map from character codes to CIDs and whose descendant CIDFont uses the Identity mapping from CIDs to TrueType glyph indices. Text strings shown using this font simply use a 2-byte glyph index for each glyph. In the absence of a ToUnicode entry, no information would be available about what the glyphs mean.
14 0 obj
<< /Type /Font /Subtype /Type0 /BaseFont /Ryumin -Light /Encoding /Identity -H /DescendantFonts [ 15 0 R ] /ToUnicode 16 0 R
>> endobj 15 0 obj << /Type /Font /Subtype /CIDFontType2 /BaseFont /Ryumin -Light /CIDSystemInfo 17 0 R /FontDescriptor 18 0 R /CIDToGIDMap /Identity >> endobj
EXAMPLE 2 In this example, the value of the ToUnicode entry is a stream object that contains the definition of the CMap.
The begincodespacerange and endcodespacerange operators define the source character code range to be the 2-byte character codes from < 00 00 > to < FF FF >. The specific mappings for several of the character codes are shown.
16 0 obj << /Length 433 >> stream /CIDInit /ProcSet findresource begin 12 dict begin begincmap /CIDSystemInfo << /Registry ( Adobe ) /Ordering ( UCS ) /Supplement 0 >> def /CMapName /Adobe -Identity -UCS def /CMapType 2 def 1 begincodespacerange < 0000 > < FFFF > endcodespacerange 2 beginbfrange < 0000 > < 005E > < 0020 > < 005F > < 0061 > [ < 00660066 > < 00660069 > < 00660066006C > ] endbfrange 1 beginbfchar <3A51> <D840DC3E> endbfchar endcmap CMapName currentdict /CMap defineresource pop end end endstream endobj
< 00 00 > to < 00 5E > are mapped to the Unicode values U+0020 to U+007E This is followed by the definition of a mapping where each character code represents more than one Unicode value:
< 005F > < 0061 > [ < 00660066 > < 00660069 > < 00660066006C > ]
In this case, the original character codes are the glyph indices for the ligatures ff, fi, and ffl. The entry defines the mapping from the character codes < 00 5F >, < 00 60 >, and < 00 61 > to the strings of Unicode values with a Unicode scalar value for each character in the ligature: U+0066 U+0066 are the Unicode values for the character sequence f f, U+0066 U+0069 for f i, and U+0066 U+0066 U+006c for f f l.
Finally, the character code < 3A 51> is mapped to the Unicode value U+2003E, which is expressed by the byte sequence <D840DC3E> in UTF-16BE encoding.
EXAMPLE 2 in this sub-clause illustrates several extensions to the way destination values may be defined. To support mappings from a source code to a string of destination codes, this extension has been made to the ranges defined after a beginbfchar operator:
srcCode dstString
where dstString may be a string of up to 512 bytes. Likewise, mappings after the beginbfrange operator may be defined as:
srcCode 1 srcCode 2 dstString
In this case, the last byte of the string shall be incremented for each consecutive code in the source code range.
When defining ranges of this type, the value of the last byte in the string shall be less than or equal to 255 -( srcCode 2 -srcCode 1). This ensures that the last byte of the string shall not be incremented past 255; otherwise, the result of mapping is undefined.
To support more compact representations of mappings from a range of source character codes to a discontiguous range of destination codes, the CMaps used for the ToUnicode entry may use this syntax for the mappings following a beginbfrange definition.
srcCode 1 srcCode 2 [ dstString 1 dstString 2 … dstString m ]
Navigation: PDF-Spec-09-Font-Descriptors | PDF-Spec-Index | Next →