Repository navigation
PDF20 Spec 09 Embedded Fonts
Part of: PDF20-Spec-09-Text
Navigation: PDF20-Spec-09-Font-Descriptors | PDF20-Spec-Index | Next →
9.9
Embedded font programs
9.9.1 General This clause describes how a font program can be embedded in a PDF file as data contained in a PDF stream object. For text in text rendering mode 3, font programs may be embedded. For text in other text rendering modes, font programs should be embedded. NOTE 1
Such a stream object is also called a font file by analogy with font programs that are available from sources external to PDF processors.
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 124 — Embedded font organisation for various font types" summarises 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.
© ISO 2020 – All rights reserved
351
ISO 32000-2:2020(E)
Table 124 — Embedded font organisation for various font types
352
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. The font program provided as the value of this key shall conform to the Adobe Type 1 Font Format and/or Adobe Technical Note #5015, Type 1 Font Format Supplement.
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. The font program provided as the value of this key shall conform to the TrueType Reference Manual. The font program shall include these tables: "glyf", "head", "hhea", "hmtx", "loca", and "maxp". The "cvt " (notice the trailing SPACE), "fpgm", and "prep" tables shall also be included if they are required by the font instructions.
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. The font program provided as the value of this key shall conform to Adobe Technical Note #5176.
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. The font program provided as the value of this key shall conform to Adobe Technical Note #5176.
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
Key
Subtype
Description
FontFile3
OpenType
(PDF 1.6) OpenType font program, as described in ISO/IEC 14496-22. OpenType is an extension of TrueType that allows inclusion of font programs that use the Compact Font Format (CFF). •
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 shall include these tables: "head", "hhea", "hmtx", "loca", and "maxp". The "cvt " (notice the trailing SPACE), "fpgm", and "prep" tables shall 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 shall 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 shall include the "cmap" table.
A FontFile3 entry with an OpenType subtype may appear in the font descriptor for these types of font dictionaries. ISO/IEC 14496-22 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. The font program provided as the value of this key shall conform to ISO/IEC 14496-22:2019. NOTE
The absence of some optional tables (such as those used for advanced line layout) can 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 — Entries common to all stream dictionaries"), plus the additional entries listed in "Table 125 — Additional entries in an embedded font stream dictionary". Table 125 — Additional entries in an embedded font stream dictionary Key
Type
Value
Length1
integer
(Required for Type 1 and TrueType font programs) 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 font programs) 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 font programs) 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 PDF processor.
© ISO 2020 – All rights reserved
353
ISO 32000-2:2020(E)
Key
Type
Value
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.
NOTE 2
EXAMPLE
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 can be in binary or ASCII hexadecimal format, PDF supports only the binary format. However, the entire font program can be encoded using any filters. 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 124 — Embedded font organisation for various font types", 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 apply 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.5.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. 354
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
The "vhea" and "vmtx" tables that specify vertical metrics shall never be used by a PDF processor. 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 can 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, PDF processors can use the data in OpenType fonts to do advanced line layout, automatically substitute ligatures, provide selections of alternative glyphs to users, and handle complex writing scripts.
The process of finding glyph descriptions in OpenType fonts by a PDF processor shall be the following: •
For Type 1 fonts using "CFF " tables, the process shall be as described in 9.6.5.2, "Encodings for Type 1 fonts".
•
For TrueType fonts using "glyf" tables, the process shall be as described in 9.6.5.4, "Encodings for TrueType fonts". Since this process sometimes produces ambiguous results, PDF writers, instead of using a simple font, should use a Type 0 font with an Identity-H encoding and use the glyph indices as character codes, as described following "Table 116 — Predefined CJK CMap names".
•
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".
9.9.2 Font subsets PDF documents may include subsets of PDF fonts whose Subtype is Type1, TrueType or OpenType. The font and font descriptor that describe a font subset are slightly different from those of ordinary fonts. These differences allow a PDF processor to recognise font subsets and to merge documents containing different subsets of the same font. (For more information on font descriptors, see 9.8, "Font descriptors".) For a font subset, the PostScript name of the font, that is, the value of the font’s BaseFont entry and the font descriptor’s FontName entry, shall begin with a tag followed by a plus sign (+) followed by the PostScript name of the font from which the subset was created. The tag shall consist of exactly six uppercase letters; the choice of letters is arbitrary, but different subsets of the same font in the same PDF file shall have different tags. The glyph name .notdef shall be defined in the font subset. NOTE EXAMPLE
It is recommended that PDF processors treat multiple subset fonts as completely independent entities, even if they appear to have been created from the same original font. EOODIA+Poetica is the name of a subset of Poetica®, a Type 1 font.
9.10 Extraction of text content 9.10.1
General
The preceding subclauses describe all the facilities for showing text and causing glyphs to be painted on the page. In addition to rendering text, PDF processors often 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 © ISO 2020 – All rights reserved
355
ISO 32000-2:2020(E)
exporting of text to other file formats. Unicode 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. When extracting character content, a PDF processor 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 PDF processor. 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 using the following methods: •
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.
9.10.2
Mapping character codes to Unicode values
A PDF processor 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.6, "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 and the glyph selection algorithm (see 9.6.5, "Character encoding") uses a glyph name, that name can be looked up in the Adobe Glyph List and Adobe Glyph List for New Fonts to obtain the corresponding Unicode value.
•
If the font is a composite font that uses one of the predefined CMaps listed in "Table 116 — Predefined CJK CMap names" (except Identity–H and Identity–V) or whose descendant CIDFont uses the Adobe-GB1, Adobe-CNS1, Adobe-Japan1, Adobe-Korea1 (deprecated in PDF 2.0 (2020)) or Adobe-KR (added in PDF 2.0 (2020)) 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 a variety of online sources, e.g. https://github.com/adobe-type-tools/mapping-resources-pdf). e. Map the CID obtained in step (a) according to the CMap obtained in step (d), producing a Unicode value. Type 0 fonts whose descendant CIDFonts use the Adobe-GB1, Adobe-CNS1, Adobe-Japan1, Adobe356
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
Korea1 (deprecated in PDF 2.0 (2020)) or Adobe-KR (added in PDF 2.0 (2020)) character collection (as specified in the CIDSystemInfo dictionary) shall have a supplement number corresponding to the version of PDF supported by the PDF processor. If these methods fail to produce a Unicode value, there is no way to determine what the character code represents in which case a PDF processor may choose a character code of their choosing.
9.10.3
ToUnicode CMaps
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. This CMap differs from an ordinary one in these ways: •
The only pertinent entry in the CMap stream dictionary (see "Table 118 — Additional entries in a CMap stream dictionary") 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.
For simple fonts, character codes shall be written as 1 byte in the ToUnicode CMap. For CID keyed fonts character codes may have 1 byte, 2 bytes, or more than 2 bytes in the ToUnicode CMap. 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 . The specific mappings for several of the character
© ISO 2020 – All rights reserved
357
ISO 32000-2:2020(E)
codes are shown. 16 0 obj << /Type /CMap /CMapName /Adobe-Identity-UCS2 /CIDSystemInfo << /Registry (Adobe) /Ordering (UCS2) /Supplement 0 >> /Length 433
stream /CIDInit /ProcSet findresource begin 12 dict begin begincmap /CIDSystemInfo <</Registry (Adobe) /Ordering (UCS2) /Supplement 0
endcodespacerange 2 beginbfrange <0000> <005E> <0020> <005F> <0061> [<00660066> <00660069> <00660066006C>] endbfrange 1 beginbfchar <3A51> endbfchar endcmap CMapName currentdict /CMap defineresource pop end end endstream endobjdef /CMapName /Adobe-Identity-UCS2 def /CMapType 2 def 1 begincodespacerange <0000>
<00 00> to <00 5E> are mapped to the Unicode values SPACE (U+0020) to TILDE (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: LATIN SMALL LETTER F (U+0066) LATIN SMALL LETTER F (U+0066) are the Unicode values for the character sequence f f, LATIN SMALL LETTER F (U+0066) LATIN SMALL LETTER I (U+0069) for f i, and LATIN SMALL LETTER F (U+0066) LATIN SMALL LETTER F (U+0066) LATIN SMALL LETTER L (U+006c) for f f l. Finally, the character code <3A 51> is mapped to the Unicode value UNICODE HAN CHARACTER ‘U+2003E’ (U+2003E), which is expressed by the byte sequence in UTF-16BE encoding.
Example 2 in this subclause 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: n beginbfchar srcCode dstString endbfchar
where dstString may be a string of up to 512 bytes. Likewise, mappings after the beginbfrange operator may be defined as: 358
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
n beginbfrange srcCode1 srcCode2 dstString endbfrange
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 - (srcCode2 - srcCode1). 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. n beginbfrange srcCode1 srcCode2 [dstString1 dstString2…dstStringm] endbfrange
Consecutive codes starting with srcCode1 and ending with srcCode2 shall be mapped to the destination strings in the array starting with dstString1 and ending with dstStringm . The value of dstString can be a string of up to 512 bytes. The value of m represents the number of continuous character codes in the source character code range. 𝑚 = 𝑠𝑟𝑐𝐶𝑜𝑑𝑒2 − 𝑠𝑟𝑐𝐶𝑜𝑑𝑒1 + 1 NOTE
If number of dstString in array is different from m, the result of mapping is undefined.
© ISO 2020 – All rights reserved
359
ISO 32000-2:2020(E)
10
Navigation: PDF20-Spec-09-Font-Descriptors | PDF20-Spec-Index | Next →