Repository navigation
PDF Spec 09 Fonts
Part of: PDF-Spec-09-Text
Navigation: PDF-Spec-09-Text-Objects | PDF-Spec-Index | PDF-Spec-09-CIDFonts
There are several types of simple fonts, all of which have these properties:
- Glyphs in the font shall be selected by single-byte character codes obtained from a string that is shown by the text-showing operators. Logically, these codes index into a table of 256 glyphs; the mapping from codes to glyphs is called the font's encoding . Under some circumstances, the encoding may be altered by means described in 9.6.6, "Character Encoding".
- Each glyph shall have a single set of metrics, including a horizontal displacement or width, as described in 9.2.4, "Glyph Positioning and Metrics"; that is, simple fonts support only horizontal writing mode.
- Except for Type 0 fonts, Type 3 fonts in non-Tagged PDF documents, and certain standard Type 1 fonts, every font dictionary shall contain a subsidiary dictionary, the font descriptor , containing font-wide metrics and other attributes of the font; see 9.8, "Font Descriptors". Among those attributes is an optional font file stream containing the font program.
A Type 1 font program is a stylized PostScript program that describes glyph shapes. It uses a compact encoding for the glyph descriptions, and it includes hint information that enables high-quality rendering even at small sizes and low resolutions.
- NOTE 1 Details on this format are provided in a separate specification, Adobe Type 1 Font Format . An alternative, more compact but functionally equivalent representation of a Type 1 font program is documented in Adobe Technical Note #5176, The Compact Font Format Specification .
- NOTE 2 Although a Type 1 font program uses PostScript language syntax, using it does not require a full PostScript interpreter; a specialized Type 1 font interpreter suffices.
A Type 1 font dictionary may contain the entries listed in Table 111. Some entries are optional for the standard 14 fonts listed under 9.6.2.2, "Standard Type 1 Fonts (Standard 14 Fonts)", but are required otherwise.
Table 111 - Entries in a Type 1 font dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Required) The type of PDF object that this dictionary describes; shall be Font for a font dictionary. |
| Subtype | name | (Required) The type of font; shall be Type1 for a Type 1 font. |
| Name | name | (Required in PDF 1.0; optional otherwise) The name by which this font is referenced in the Font subdictionary of the current resource dictionary. This entry is obsolete and should not be used. |
| BaseFont | name | (Required) The PostScript name of the font. For Type 1 fonts, this is always the value of the FontName entry in the font program; for more information, see Section 5.2 of the PostScript Language Reference , Third Edition. The PostScript name of the font may be used to find the font program in the conforming reader or its environment. It is also the name that is used when printing to a PostScript output device. |
Table 111 - Entries in a Type 1 font dictionary (continued)
| Key | Type | Value |
|---|---|---|
| FirstChar | integer | (Required except for the standard 14 fonts) The first character code defined in the font's Widths array. Beginning with PDF 1.5, the special treatment given to the standard 14 fonts is deprecated. Conforming writers should represent all fonts using a complete font descriptor. For backwards capability, conforming readers shall still provide the special treatment identified for the standard 14 fonts. |
| LastChar | integer | (Required except for the standard 14 fonts) The last character code defined in the font's Widths array. Beginning with PDF 1.5, the special treatment given to the standard 14 fonts is deprecated. Conforming writers should represent all fonts using a complete font descriptor. For backwards capability, conforming readers shall still provide the special treatment identified for the standard 14 fonts. |
| Widths | array | (Required except for the standard 14 fonts; indirect reference preferred) An array of ( LastChar - FirstChar + 1) widths, each element being the glyph width for the character code that equals FirstChar plus the array index. For character codes outside the range FirstChar to LastChar , the value of MissingWidth from the FontDescriptor entry for this font shall be used. The glyph widths shall be measured in units in which 1000 units correspond to 1 unit in text space. These widths shall be consistent with the actual widths given in the font program. For more information on glyph widths and other glyph metrics, see 9.2.4, "Glyph Positioning and Metrics". Beginning with PDF 1.5, the special treatment given to the standard 14 fonts is deprecated. Conforming writers should represent all fonts using a complete font descriptor. For backwards capability, conforming readers shall still provide the special treatment identified for the standard 14 fonts. |
| FontDescriptor | dictionary | (Required except for the standard 14 fonts; shall be an indirect reference) A font descriptor describing the font's metrics other than its glyph widths (see 9.8, "Font Descriptors"'). For the standard 14 fonts, the entries FirstChar , LastChar , Widths , and FontDescriptor shall either all be present or all be absent. Ordinarily, these dictionary keys may be absent; specifying them enables a standard font to be overridden; see 9.6.2.2, "Standard Type 1 Fonts (Standard 14 Fonts)". Beginning with PDF 1.5, the special treatment given to the standard 14 fonts is deprecated. Conforming writers should represent all fonts using a complete font descriptor. For backwards capability, conforming readers shall still provide the special treatment identified for the |
| Encoding | name or dictionary | (Optional) A specification of the font's character encoding if different from its built-in encoding. The value of Encoding shall be either the name of a predefined encoding ( MacRomanEncoding , MacExpertEncoding , or WinAnsiEncoding , as described in Annex D) or an encoding dictionary that shall specify differences from the font's built-in encoding or from a specified predefined encoding (see 9.6.6, "Character Encoding"). |
| ToUnicode | stream | (Optional; PDF 1.2) A stream containing a CMap file that maps character codes to Unicode values (see 9.10, "Extraction of Text Content"). |
EXAMPLE
This example shows the font dictionary for the Adobe Garamond® Semibold font. The font has an encoding dictionary (object 25), although neither the encoding dictionary nor the font descriptor (object 7) is shown in the example.
14 0 obj << /Type /Font /Subtype /Type1 /BaseFont /AGaramond -Semibold /FirstChar 0 /LastChar 255 /Widths 21 0 R /FontDescriptor 7 0 R /Encoding 25 0 R >> endobj 21 0 obj [ 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 280 438 510 510 868 834 248 320 320 420 510 255 320 255 347 510 510 510 510 510 510 510 510 510 510 255 255 510 510 510 330 781 627 627 694 784 580 533 743 812 354 354 684 560 921 780 792 588 792 656 504 682 744 650 968 648 590 638 320 329 320 510 500 380 420 510 400 513 409 301 464 522 268 259 484 258 798 533 492 516 503 349 346 321 520 434 684 439 448 390 320 255 320 510 255 627 627 694 580 780 792 744 420 420 420 420 420 420 402 409 409 409 409 268 268 268 268 533 492 492 492 492 492 520 520 520 520 486 400 510 510 506 398 520 555 800 800 1044 360 380 549 846 792 713 510 549 549 510 522 494 713 823 549 274 354 387 768 615 496 330 280 510 549 510 549 612 421 421 1000 255 627 627 792 1016 730 500 1000 438 438 248 248 510 494 448 590 100 510 256 256 539 539 486 255 248 438 1174 627 580 627 580 580 354 354 354 354 792 792 790 792 744 744 744 268 380 380 380 380 380 380 380 380 380 380 ] endobj
The PostScript names of 14 Type 1 fonts, known as the standard 14 fonts , are as follows: Times-Roman, Helvetica, Courier, Symbol, Times-Bold, Helvetica-Bold, Courier-Bold, ZapfDingbats, Times-Italic, HelveticaOblique, Courier-Oblique, Times-BoldItalic, Helvetica-BoldOblique, Courier-BoldOblique
These fonts, or their font metrics and suitable substitution fonts, shall be available to the conforming reader.
NOTE
The character sets and encodings for these fonts are listed in Annex D. The font metrics files for the standard 14 fonts are available from the ASN Web site (see the Bibliography). For more information on font metrics, see Adobe Technical Note #5004, Adobe Font Metrics File Format Specification .
The multiple master font format is an extension of the Type 1 font format that allows the generation of a wide variety of typeface styles from a single font program. This is accomplished through the presence of various design dimensions in the font.
EXAMPLE 1 Examples of design dimensions are weight (light to extra-bold) and width (condensed to expanded).
Coordinates along these design dimensions (such as the degree of boldness) are specified by numbers. A particular choice of numbers selects an instance of the multiple master font. PDFs can contain multiple master instances.
NOTE Adobe Technical Note #5015, Type 1 Font Format Supplement , describes multiple master fonts in detail.
The font dictionary for a multiple master font instance may contain the same entries as a Type 1 font dictionary (see Table 111), with these differences:
- The value of Subtype shall be MMType1 .
- If the PostScript name of the instance contains SPACEs (20h), the SPACEs shall be replaced by LOW LINEs (underscores) (5Fh) in the value of BaseFont . For instance, as illustrated in this example, the name 'MinionMM 366 465 11 ' (which ends with a SPACE character) becomes /MinionMM_366_465_11_.
EXAMPLE 2 7 0 obj << /Type /Font /Subtype /MMType1 /BaseFont /MinionMM_366_465_11_ /FirstChar 32 /LastChar 255 /Widths 19 0 R /FontDescriptor 6 0 R /Encoding 5 0 R >> endobj 19 0 obj [ 187 235 317 430 427 717 607 168 326 326 421 619 219 317 219 282 427 … Omitted data … 569 0 569 607 607 607 239 400 400 400 400 253 400 400 400 400 400 ] endobj
This example illustrates a convention for including the numeric values of the design coordinates as part of the instance's BaseFont name. This convention is commonly used for accessing multiple master font instances from an external source in the conforming reader's environment; it is documented in Adobe Technical Note #5088, Font Naming Issues . However, this convention is not prescribed as part of the PDF specification.
If the font program for a multiple master font instance is embedded in the PDF file, it shall be an ordinary Type 1 font program, not a multiple master font program. This font program is called a snapshot of the multiple master font instance that incorporates the chosen values of the design coordinates.
A TrueType font dictionary may contain the same entries as a Type 1 font dictionary (see Table 111), with these differences:
- The value of Subtype shall be TrueType .
- The value of Encoding is subject to limitations that are described in 9.6.6, "Character Encoding".
- The value of BaseFont is derived differently.
The PostScript name for the value of BaseFont may be determined in one of two ways:
-
If the TrueType font program's 'name' table contains a PostScript name, it shall be used.
-
In the absence of such an entry in the 'name' table, a PostScript name shall be derived from the name by which the font is known in the host operating system. On a Windows system, the name shall be based on the lfFaceName field in a LOGFONT structure; in the Mac OS, it shall be based on the name of the FOND resource. If the name contains any SPACEs, the SPACEs shall be removed.
-
NOTE 1 The TrueType font format was developed by Apple Computer, Inc., and has been adopted as a standard font format for the Microsoft Windows operating system. Specifications for the TrueType font file format are available in Apple's TrueType Reference Manual and Microsoft's TrueType 1.0 Font Files Technical Specification (see Bibliography).
-
NOTE 2 A TrueType font program may be embedded directly in a PDF file as a stream object.
-
NOTE 3 The Type 42 font format that is defined for PostScript does not apply to PDF.
-
NOTE 4 For CJK (Chinese, Japanese, and Korean) fonts, the host font system's font name is often encoded in the host operating system's script. For instance, a Japanese font may have a name that is written in Japanese using some (unidentified) Japanese encoding. Thus, TrueType font names may contain multiple-byte character codes, each of which requires multiple characters to represent in a PDF name object (using the # notation to quote special characters as needed).
PDF documents may include subsets of Type 1 and TrueType fonts. The font and font descriptor that describe a font subset are slightly different from those of ordinary fonts. These differences allow a conforming reader to recognize 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-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 (+). The tag shall consist of exactly six uppercase letters; the choice of letters is arbitrary, but different subsets in the same PDF file shall have different tags.
EXAMPLE EOODIA+Poetica is the name of a subset of Poetica ® , a Type 1 font.
Type 3 fonts differ from the other fonts supported by PDF. A Type 3 font dictionary defines the font; font dictionaries for other fonts simply contain information about the font and refer to a separate font program for the actual glyph descriptions. In Type 3 fonts, glyphs shall be defined by streams of PDF graphics operators. These streams shall be associated with glyph names. A separate encoding entry shall map character codes to the appropriate glyph names for the glyphs.
- NOTE 1 Type 3 fonts are more flexible than Type 1 fonts because the glyph descriptions may contain arbitrary PDF graphics operators. However, Type 3 fonts have no hinting mechanism for improving output at small sizes or low resolutions.
A Type 3 font dictionary may contain the entries listed in Table 112.
Table 112 - Entries in a Type 3 font dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Required) The type of PDF object that this dictionary describes; shall be Font for a font dictionary. |
| Subtype | name | (Required) The type of font; shall be Type3 for a Type 3 font. |
| Name | name | (Required in PDF 1.0; optional otherwise) See Table 111. |
Table 112 - Entries in a Type 3 font dictionary (continued)
| Key | Type | Value |
|---|---|---|
| FontBBox | rectangle | (Required) A rectangle (see 7.9.5, "Rectangles") expressed in the glyph coordinate system, specifying the font bounding box . This is the smallest rectangle enclosing the shape that would result if all of the glyphs of the font were placed with their origins coincident and then filled. If all four elements of the rectangle are zero, a conforming reader shall make no assumptions about glyph sizes based on the font bounding box. If any element is nonzero, the font bounding box shall be accurate. If any glyph's marks fall outside this bounding box, incorrect behavior may result. |
| FontMatrix | array | (Required) An array of six numbers specifying the font matrix , mapping glyph space to text space (see 9.2.4, "Glyph Positioning and Metrics"). NOTE A common practice is to define glyphs in terms of a 1000-unit glyph coordinate system, in which case the font matrix is [0.001 0 0 0.001 0 0]. |
| CharProcs | dictionary | (Required) A dictionary in which each key shall be a glyph name and the value associated with that key shall be a content stream that constructs and paints the glyph for that character. The stream shall include as its first operator either d0 or d1 , followed by operators describing one or more graphics objects, which may include path, text, or image objects. See below for more details about Type 3 glyph descriptions. |
| Encoding | name or dictionary | (Required) An encoding dictionary whose Differences array shall specify the complete character encoding for this font (see 9.6.6, "Character Encoding"). |
| FirstChar | integer | (Required) The first character code defined in the font's Widths array. |
| LastChar | integer | (Required) The last character code defined in the font's Widths array. |
| Widths | array | (Required; should be an indirect reference) An array of ( LastChar - FirstChar + 1) widths, each element being the glyph width for the character code that equals FirstChar plus the array index. For character codes outside the range FirstChar to LastChar , the width shall be 0. These widths shall be interpreted in glyph space as specified by FontMatrix (unlike the widths of a Type 1 font, which are in thousandths of a unit of text space). If FontMatrix specifies a rotation, only the horizontal component of the transformed width shall be used. That is, the resulting displacement shall be horizontal in text space, as is the case for all simple fonts. |
| FontDescriptor | dictionary | (Required in Tagged PDF documents; shall be an indirect reference) A font descriptor describing the font's default metrics other than its glyph widths (see 9.8, "Font Descriptors"). |
| Resources | dictionary | (Optional but should be used; PDF 1.2) A list of the named resources, such as fonts and images, required by the glyph descriptions in this font (see 7.8.3, "Resource Dictionaries"). If any glyph descriptions refer to named resources but this dictionary is absent, the names shall be looked up in the resource dictionary of the page on which the font is used. |
| ToUnicode | stream | (Optional; PDF 1.2) A stream containing a CMap file that maps character codes to Unicode values (see 9.10, "Extraction of Text Content"). |
For each character code shown by a text-showing operator that uses a Type 3 font, the conforming reader shall:
- a) Look up the character code in the font's Encoding entry, as described in 9.6.6, "Character Encoding," to obtain a glyph name.
- b) Look up the glyph name in the font's CharProcs dictionary to obtain a stream object containing a glyph description. If the name is not present as a key in CharProcs , no glyph shall be painted.
- c) Invoke the glyph description. The graphics state shall be saved before this invocation and shall be restored afterward; therefore, any changes the glyph description makes to the graphics state do not persist after it finishes.
When the glyph description begins execution, the current transformation matrix (CTM) shall be the concatenation of the font matrix ( FontMatrix in the current font dictionary) and the text space that was in effect at the time the text-showing operator was invoked (see 9.4.4, "Text Space Details"). This means that shapes described in the glyph coordinate system are transformed into the user coordinate system and appear in the appropriate size and orientation on the page. The glyph description shall describe the glyph in terms of absolute coordinates in the glyph coordinate system, placing the glyph origin at (0, 0) in this space. It shall make no assumptions about the initial text position.
Aside from the CTM, the graphics state shall be inherited from the environment of the text-showing operator that caused the glyph description to be invoked. To ensure predictable results, the glyph description shall initialize any graphics state parameters on which it depends. In particular, if it invokes the S (stroke) operator, it shall explicitly set the line width, line join, line cap, and dash pattern to appropriate values.
- NOTE 2 Normally, it is unnecessary and undesirable to initialize the current colour parameter because the text-showing operators are designed to paint glyphs with the current colour.
The glyph description shall execute one of the operators described in Table 113 to pass width and bounding box information to the font machinery. This shall precede the execution of any path construction or pathpainting operators describing the glyph.
- NOTE 3 Type 3 fonts in PDF are very similar to those in PostScript. Some of the information provided in Type 3 font dictionaries and glyph descriptions, while seemingly redundant or unnecessary, is nevertheless required for correct results when a conforming reader prints to a PostScript output device. This applies particularly to the operands of the d0 and d1 operators, are the equivalent of PostScript's setcharwidth and setcachedevice . For further explanation, see Section 5.7 of the PostScript Language Reference, Third Edition.
Table 113 - Type 3 font operators
| Operands | Operator | Description |
|---|---|---|
| w x w y | d0 | Set width information for the glyph and declare that the glyph description specifies both its shape and its colour. NOTE This operator name ends in the digit 0 . w x denotes the horizontal displacement in the glyph coordinate system; it shall be consistent with the corresponding width in the font's Widths array. w y shall be 0 (see 9.2.4, "Glyph Positioning and Metrics"). This operator shall only be permitted in a content stream appearing in a Type 3 font's CharProcs dictionary. It is typically used only if the glyph description executes operators to set the colour explicitly. |
Table 113 - Type 3 font operators (continued)
| Operands | Operator | Description |
|---|---|---|
| w x w y ll x ll y ur x ur y | d1 | Set width and bounding box information for the glyph and declare that the glyph description specifies only shape, not colour. NOTE This operator name ends in the digit 1 . w x denotes the horizontal displacement in the glyph coordinate system; it shall be consistent with the corresponding width in the font's Widths array. w y shall be 0 (see 9.2.4, "Glyph Positioning and Metrics"). ll x and ll y denote the coordinates of the lower-left corner, and ur x and ur y denote the upper-right corner, of the glyph bounding box. The glyph bounding box is the smallest rectangle, oriented with the axes of the glyph coordinate system, that completely encloses all marks placed on the page as a result of executing the glyph's description. The declared bounding box shall be correct-in other words, sufficiently large to enclose the entire glyph. If any marks fall outside this bounding box, the result is unpredictable. A glyph description that begins with the d1 operator should not execute any operators that set the colour (or other colour-related parameters) in the graphics state; any use of such operators shall be ignored. The glyph description is executed solely to determine the glyph's shape. Its colour shall be determined by the graphics state in effect each time this glyph is painted by a text-showing operator. For the same reason, the glyph description shall not include an image; however, an image mask is acceptable, since it merely defines a region of the page to be painted with the current colour. This operator shall be used only in a content stream appearing in a Type 3 font's CharProcs dictionary. |
EXAMPLE This example shows the definition of a Type 3 font with only two glyphs-a filled square and a filled triangle, selected by the character codes a and b. Figure 47 shows the result of showing the string ( ababab ) using this font.
Figure 47 - Output from the example in 9.6.5, "Type 3 Fonts"
4 0 obj << /Type /Font /Subtype /Type3 /FontBBox [ 0 0 750 750 ] /FontMatrix [ 0.001 0 0 0.001 0 0 ] /CharProcs 10 0 R /Encoding 9 0 R /FirstChar 97 /LastChar 98 /Widths [ 1000 1000 ] >> endobj 9 0 obj << /Type /Encoding /Differences [ 97 /square /triangle ] >> endobj 10 0 obj << /square 11 0 R /triangle 12 0 R >> endobj 11 0 obj << /Length 39 >> stream 1000 0 0 0 750 750 d1 0 0 750 750 re f endstream endobj 12 0 obj << /Length 48 >> stream 1000 0 0 0 750 750 d1 0 0 m 375 750 l 750 0 l f endstream endobj
A font's encoding is the association between character codes (obtained from text strings that are shown) and glyph descriptions. This sub-clause describes the character encoding scheme used with simple PDF fonts. Composite fonts (Type 0) use a different character mapping algorithm, as discussed in 9.7, "Composite Fonts".
Except for Type 3 fonts, every font program shall have a built-in encoding. Under certain circumstances, a PDF font dictionary may change the encoding used with the font program to match the requirements of the conforming writer generating the text being shown.
- NOTE This flexibility in character encoding is valuable for two reasons:
It permits showing text that is encoded according to any of the various existing conventions. For example, the Microsoft Windows and Apple Mac OS operating systems use different standard encodings for Latin text, and many conforming writers use their own special-purpose encodings.
It permits conforming writers to specify how characters selected from a large character set are to be encoded.
Some character sets consist of more than 256 characters, including ligatures, accented characters, and other symbols required for high-quality typography or non-Latin writing systems. Different encodings may select different subsets of the same character set.
One commonly used font encoding for Latin-text font programs is often referred to as StandardEncoding or sometimes as the Adobe standard encoding. The name StandardEncoding shall have no special meaning in PDF, but this encoding does play a role as a default encoding (as shown in Table 114). The regular encodings used for Latin-text fonts on Mac OS and Windows systems shall be named MacRomanEncoding and WinAnsiEncoding , respectively. An encoding named MacExpertEncoding may be used with 'expert' fonts that contain additional characters useful for sophisticated typography. Complete details of these encodings and of the characters present in typical fonts are provided in Annex D.
In PDF, a font is classified as either nonsymbolic or symbolic according to whether all of its characters are members of the standard Latin character set; see D.2, 'Latin Character Set and Encodings'. This shall be indicated by flags in the font descriptor; see 9.8.2, "Font Descriptor Flags". Symbolic fonts contain other character sets, to which the encodings mentioned previously ordinarily do not apply. Such font programs have built-in encodings that are usually unique to each font. The standard 14 fonts include two symbolic fonts, Symbol and ZapfDingbats, whose encodings and character sets are documented in Annex D.
A font program's built-in encoding may be overridden by including an Encoding entry in the PDF font dictionary. The possible encoding modifications depend on the font type. The value of the Encoding entry shall be either a named encoding (the name of one of the predefined encodings MacRomanEncoding , MacExpertEncoding , or WinAnsiEncoding ) or an encoding dictionary . An encoding dictionary contains the entries listed in Table 114.
Table 114 - Entries in an encoding dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Optional) The type of PDF object that this dictionary describes; if present, shall be Encoding for an encoding dictionary. |
| BaseEncoding | name | (Optional) The base encoding -that is, the encoding from which the Differences entry (if present) describes differences- shall be the name of one of the predefined encodings MacRomanEncoding , MacExpertEncoding , or WinAnsiEncoding (see Annex D). If this entry is absent, the Differences entry shall describe differences from an implicit base encoding. For a font program that is embedded in the PDF file, the implicit base encoding shall be the font program's built-in encoding, as described in 9.6.6, "Character Encoding" and further elaborated in the sub-clauses on specific font types. Otherwise, for a nonsymbolic font, it shall be StandardEncoding , and for a symbolic font, it shall be the font's built-in encoding. |
| Differences | array | (Optional; should not be used with TrueType fonts) An array describing the differences from the encoding specified by BaseEncoding or, if BaseEncoding is absent, from an implicit base encoding. The Differences array is described in subsequent sub-clauses. |
The value of the Differences entry shall be an array of character codes and character names organized as follows:
code 1 name 1,1 name 1,2 …
code 2 name 2,1 name 2,2 … … code n name n ,1 name n ,2 …
Each code shall be the first index in a sequence of character codes to be changed. The first character name after the code becomes the name corresponding to that code. Subsequent names replace consecutive code indices until the next code appears in the array or the array ends. These sequences may be specified in any order but shall not overlap.
EXAMPLE
In the encoding dictionary in this example, the name quotesingle ( ' ) is associated with character code 39, Adieresis (Ä) with code 128, Aring (Å) with 129, and trademark (™) with 170.
25 0 obj << /Type /Encoding /Differences [ 39 /quotesingle 96 /grave 128 /Adieresis /Aring /Ccedilla /Eacute /Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis /atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis /iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve /ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex /udieresis /dagger /degree /cent /sterling /section /bullet /paragraph /germandbls /registered /copyright /trademark /acute /dieresis 174 /AE /Oslash 177 /plusminus 180 /yen /mu 187 /ordfeminine /ordmasculine 190 /ae /oslash /questiondown /exclamdown /logicalnot 196 /florin 199 /guillemotleft /guillemotright /ellipsis 203 /Agrave /Atilde /Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright /quoteleft /quoteright /divide 216 /ydieresis /Ydieresis /fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl /periodcentered /quotesinglbase /quotedblbase /perthousand /Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute /Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex 241 /Ograve /Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron /breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron ] >> endobj
A Type 1 font program's glyph descriptions are keyed by glyph names , not by character codes . Glyph names are ordinary PDF name objects. Descriptions of Latin alphabetic characters are normally associated with names consisting of single letters, such as A or a . Other characters are associated with names composed of words, such as three, ampersand, or parenleft. A Type 1 font's built-in encoding shall be defined by an Encoding array that is part of the font program, not to be confused with the Encoding entry in the PDF font dictionary.
An Encoding entry may override a Type 1 font's mapping from character codes to character names. The Differences array may map a code to the name of any glyph description that exists in the font program, regardless of whether that glyph is referenced by the font's built-in encoding or by the encoding specified in the BaseEncoding entry.
All Type 1 font programs shall contain an actual glyph named . notdef. The effect produced by showing the . notdef glyph is at the discretion of the font designer. If an encoding maps to a character name that does not exist in the Type 1 font program, the . notdef glyph shall be substituted.
A Type 3 font, like a Type 1 font, contains glyph descriptions that are keyed by glyph names; in this case, they appear as explicit keys in the font's CharProcs dictionary. A Type 3 font's mapping from character codes to glyph names shall be entirely defined by its Encoding entry, which is required in this case.
A TrueType font program's built-in encoding maps directly from character codes to glyph descriptions by means of an internal data structure called a 'cmap' (not to be confused with the CMap described in 9.7.5, "CMaps"). This sub-clause describes how the PDF font dictionary's Encoding entry shall be used in conjunction with a 'cmap' to map from a character code in a string to a glyph description in a TrueType font program.
A 'cmap' table may contain one or more subtables that represent multiple encodings intended for use on different platforms (such as Mac OS and Windows). Each subtable shall be identified by the two numbers, such as (3, 1), that represent a combination of a platform ID and a platform-specific encoding ID , respectively.
Glyph names are not required in TrueType fonts, although some font programs have an optional 'post' table listing glyph names for the glyphs. If the conforming reader needs to select glyph descriptions by name, it translates from glyph names to codes in one of the encodings given in the font program's 'cmap' table. When there is no character code in the 'cmap' that corresponds to a glyph name, the 'post' table shall be used to select a glyph description directly from the glyph name.
Because some aspects of TrueType glyph selection are dependent on the conforming reader or the operating system, PDF files that use TrueType fonts should follow certain guidelines to ensure predictable behaviour across all conforming readers:
- The font program should be embedded.
- A nonsymbolic font should specify MacRomanEncoding or WinAnsiEncoding as the value of its Encoding entry, with no Differences array.
- A font that is used to display glyphs that do not use MacRomanEncoding or WinAnsiEncoding should not specify an Encoding entry. The font descriptor's Symbolic flag (see Table 123) should be set, and its font program's 'cmap' table should contain a (1, 0) subtable. It may also contain a (3, 0) subtable; if present, this subtable should map from character codes in the range 0xF000 to 0xF0FF by prepending the single-byte codes in the (1, 0) subtable with 0xF0 and mapping to the corresponding glyph descriptions.
- NOTE 1 Some popular TrueType font programs contain incorrect encoding information. Implementations of TrueType font interpreters have evolved heuristics for dealing with such problems; those heuristics are not described here. For maximum portability, only well-formed TrueType font programs should be used in PDF files. Therefore, a TrueType font program in a PDF file may need to be modified to conform to these guidelines.
The following paragraphs describe the treatment of TrueType font encodings beginning with PDF 1.3.
If the font has a named Encoding entry of either MacRomanEncoding or WinAnsiEncoding , or if the font descriptor's Nonsymbolic flag (see Table 123) is set, the conforming reader shall create a table that maps from character codes to glyph names:
-
If the Encoding entry is one of the names MacRomanEncoding or WinAnsiEncoding , the table shall be initialized with the mappings described in Annex D.
-
If the Encoding entry is a dictionary, the table shall be initialized with the entries from the dictionary's BaseEncoding entry (see Table 114). Any entries in the Differences array shall be used to update the table. Finally, any undefined entries in the table shall be filled using StandardEncoding .
If a (3, 1) 'cmap' subtable (Microsoft Unicode) is present:
- A character code shall be first mapped to a glyph name using the table described above.
- The glyph name shall then be mapped to a Unicode value by consulting the Adobe Glyph List (see the Bibliography).
- Finally, the Unicode value shall be mapped to a glyph description according to the (3, 1) subtable.
If no (3, 1) subtable is present but a (1, 0) subtable (Macintosh Roman) is present:
- A character code shall be first mapped to a glyph name using the table described above.
- The glyph name shall then be mapped back to a character code according to the standard Roman encoding used on Mac OS.
- Finally, the code shall be mapped to a glyph description according to the (1, 0) subtable.
In any of these cases, if the glyph name cannot be mapped as specified, the glyph name shall be looked up in the font program's 'post' table (if one is present) and the associated glyph description shall be used.
The standard Roman encoding that is used on Mac OS is the same as the MacRomanEncoding described in Annex D, with the addition of 15 entries and the replacement of the currency glyph with the Euro glyph, as shown in Table 115.
Table 115 - Differences between MacRomanEncoding and Mac OS Roman encoding
| Name | Code (Octal) | Code (DEcimal) |
|---|---|---|
| notequal | 255 | 173 |
| infinity | 260 | 176 |
| lessequal | 262 | 178 |
| greaterequal | 263 | 179 |
| partialdiff | 266 | 182 |
| summation | 267 | 183 |
| product | 270 | 184 |
| pi | 271 | 185 |
| integral | 272 | 186 |
| Omega | 275 | 189 |
| radical | 303 | 195 |
| approxequal | 305 | 197 |
| Delta | 306 | 198 |
Navigation: PDF-Spec-09-Text-Objects | PDF-Spec-Index | PDF-Spec-09-CIDFonts