9. Text

9.3.4 Horizontal scaling

Change the first paragraph as follows:

The horizontal scaling parameter, 𝑇h, adjusts the width of glyphs by stretching or compressing them in the horizontal direction. Its value is the normalized value of the operand to the Tz operator which shall be specified as a percentage of the normal width of the glyphs, with 100 being the normal width of 100%, representing a scaling value of 1.0 for 𝑇h. The scaling shall apply to the horizontal coordinate in text space, independently of the writing mode. It shall affect both the glyph’s shape and its horizontal displacement (that is, its displacement vector). If the writing mode is horizontal, it shall also affect the spacing parameters 𝑇c and 𝑇w, as well as any positioning adjustments performed by the TJ operator. "Figure 58 — Horizontal scaling" shows the effect of horizontal scaling.

Update Figure 58 as follows:

100 Tz

𝑇h = 100 1.0 (default)

Word

50 Tz

𝑇h = 50 0.5

WordWord

Figure 58 — Horizontal scaling

9.3 Text state parameters and operators

9.3.6 Text rendering mode

Change NOTE 3 as follows:

NOTE 3 Certain degenerate glyph sub-paths that are not visible when filled can become apparent when stroking, e.g., a zero-length line with round end caps will paint a circle according to the current stroke width.

Change the paragraph below NOTE 3 as follows:

The e and f components of Tm𝑇m shall be updated for each glyph drawn when using text rendering mode 3 or 7 in exactly the same way as would be done for other text rendering modes.

9.4 Text objects

9.4.1 General

Append the following paragraph to this sub-clause as follows:

Within a text object, the graphics state stack operators q and Q (see 8.4.2, "Graphics state stack") shall additionally push and pop 𝑇m and 𝑇lm as part of the graphics state stack.

9.4.2 Text-positioning operators

Change Table 106 as follows:

Table 106 - Text-positioning operators
Operands Operator Description
T*

Move to the start of the next line. This operator has the same effect as the code

0 -𝑇l TDTd

where 𝑇l denotes the current leading parameter in the text state. The negative of 𝑇l is used here because 𝑇l is the text leading expressed as a positive number. Going to the next line entails decreasing the y coordinate.

9.4.3 Text-showing operators

Change 4th paragraph below Figure 61 as follows:

The strings shall conform to the syntax for string objects (see 7.3.4.2, "Literal strings"). When a string is written by enclosing the data in parentheses, bytes whose values are equal to those of the ASCII characters CARRIAGE RETURN (0Dh), LEFT PARENTHESIS (28h), RIGHT PARENTHESIS (29h), and REVERSE SOLIDUS (5Ch) (backslash) shall be preceded by a REVERSE SOLIDUS) character. All other byte values between 0 and 255 may be used in a string object. These rules apply to each individual byte in a string object, whether the string is interpreted by the text-showing operators as single-byte or multiple-byte character codes.

...

9.4.4 Text space details

Change NOTE 2 into normative text as follows:

NOTE 2 Conceptually, the entire transformation from text space to device space can be represented by a text rendering matrix, 𝑇𝑟𝑚:

T rm = [ T fs × T h 0 0 0 T fs 0 0 T rise 1 ] × T m × CTM

𝑇𝑟𝑚 is a temporary matrix; conceptually, it is recomputed before each glyph is painted during a text-showing operation.

9.6.2 Type 1 fonts

9.6.2.1 General

Change Table 109 as follows:

Table 109 - Entries in a Type 1 font dictionary
Key Type Value
FontDescriptor dictionary

(Required; optional in PDF 1.0-1.7 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 See also 9.6.2.2, "Standard Type 1 fonts (standard 14 fonts) (PDF 1.0-1.7)".

Change the paragraph below Table 109 as follows:

PDF versions 1.0 to 1.7 did not require Type 1 font dictionaries to include FirstChar, LastChar, Widths and FontDescriptor entries as described in 9.6.2.2, "Standard Type 1 fonts (standard 14 fonts) (PDF 1.0-1.7)". For compatibility reasons PDF processors shall provide glyph widths and font descriptor data for those standard fonts for use in processing PDF files when the entries are absent. See also 9.6.2.2, "Standard Type 1 fonts (standard 14 fonts) (PDF 1.0-1.7)".

...

9.6.2.2 Standard Type 1 fonts (standard 14 fonts) (PDF 1.0-1.7)

Change the second paragraph to a NOTE and modify as follows:

NOTE: In PDF 1.0 to PDF 1.7, the FirstChar, LastChar, Widths and FontDescriptor (see "Table 109 - Entries in a Type 1 font dictionary") were optional in Type 1 font dictionaries for the standard 14 fonts. PDF processors supporting PDF 1.0 to PDF 1.7 files shall are required to have these fonts, or their font metrics and suitable substitution fonts available.

Delete the last paragraph as follows:

These fonts, or their font metrics and suitable substitution fonts, shall be available to the PDF processor.

9.6.4 Type 3 fonts

Change the first paragraph as follows:

Type 3 fonts differ from the other fonts supported by PDF. Font dictionaries for other fonts simply contain information about the font and refer to a separate font program for the actual glyph descriptions; a Type 3 font dictionary contains the glyph descriptions. In Type 3 fonts, glyphs shall be defined by streams of PDF graphics operatorsobjects. 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 can contain arbitrary PDF graphics operators. However, Type 3 fonts have no hinting mechanism for improving output at small sizes or low resolutions.

Insert a new NOTE 2 and a new paragraph below NOTE 1 as follows:

NOTE 2 Type 3 glyphs can use any PDF operator from any operator category (see "Table 50 - Operator categories" and "Figure 9 - Graphics objects") subject to additional restrictions described in this clause.

Implementations also need to avoid potential infinite recursion if a Type 3 glyph description refers to itself directly or indirectly. The result in all such cases is implementation-dependent.

EDITOR NOTE: remaining NOTEs in this clause will be renumbered appropriately.

...

Change Table 110 as follows:

Table 110 - Entries in a Type 3 font dictionary
Key Type Value
FontDescriptor dictionary

(Required in Tagged PDF documents; shall be an indirect reference) ...

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.
(Optional; PDF 1.2) Named resources, such as fonts and images, directly required by the glyph description content streams of this Type 3 font (see 7.8.3, "Resource dictionaries").

Change bullet (d) in the list below Table 110 as follows:

  1. If any glyph descriptions refer to named resources they shall be looked up in the Resources entry of the Type 3 font dictionary. 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.
    If a glyph description content stream refers to named resources they shall be looked up in the designated resource dictionary as described in subclause 7.8.3 "Resource dictionaries".

...

Change Table 111 as follows:

Table 111 - Type 3 font operators
Operands Operator Description
wx wy d0

...

The number wx denotes the horizontal displacement in the glyph coordinate system; it shall be consistent with the corresponding width in the font's Widths array. The number wy shall be 0 (see 9.2.4, "Glyph positioning and metrics").

...

wx wy llx lly urx ury d1

...

The number wx denotes the horizontal displacement in the glyph coordinate system; it shall be consistent with the corresponding width in the font's Widths array. The number wy shall be 0 (see 9.2.4, "Glyph positioning and metrics").

The numbers llx and lly denote the coordinates of the lower-left corner, and The numbers urx and ury denote the upper-right corner, of the glyph bounding box. ...

...

Change the EXAMPLE below Table 111 as follows:

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. at positions 97 and 98 of the font's Encoding (corresponding to 'a' and 'b' in PDFDocEncoding) in the Tj string operand. "Figure 62 - Output from the example" shows the result of showing the string ( ababab ) using this font.

... %Type 3 font definition encoding two glyphs, 'a' and 'b' %Type 3 font definition encoding the two glyphs square and triangle 4 0 obj << /Type /Font /Subtype /Type3 /FontBBox [-36 -36 786 786] /FontMatrix [0.001 0 0 0.001 0 0] /CharProcs 10 0 R /Encoding 9 0 R /FirstChar 97 /LastChar 14498 /Widths [1000 1000] >> endobj ...

9.7 Composite fonts

9.7.4 CIDFonts

9.7.4.1 General

Change Table 115 as follows:

Table 115 - Entries in a CIDFont dictionary
Key Type Value
FontDescriptor dictionary

(Required; shall be an indirect reference) ...

9.7.5 CMaps

9.7.5.2 Predefined CMaps

Change the paragraph after Table 117 as follows:

A PDF processor shall support Adobe-CNS1-7, Adobe-GB1-5, Adobe-Japan1-7 and Adobe-KR-9 character collections. ". Adobe-Japan2-0 and Adobe-Korea1-2 are deprecated in this document (2020). As noted in 9.7.3, "CIDSystemInfo dictionaries", a character collection is identified by registry, ordering, and supplement number, and supplements are cumulative; that is, a higher-numbered supplement includes the CIDs contained in lower-numbered supplements, as well as some additional CIDs. Consequently, text encoded according to the predefined CMaps for a given PDF version shall be valid when interpreted by a PDF processor supporting the same or a later PDF version. When interpreted by a PDF processor supporting an earlier PDF version, such text causes an error if a CMap is encountered that is not predefined for that PDF version. If character codes are encountered that were added in a higher-numbered supplement than the one corresponding to the supported PDF version, no characters are displayed for those codes; see 9.7.6.3, "Handling undefined characters".

9.7.6 Type 0 font dictionaries

9.7.6.1 General

Change Table 119 as follows:

Table 119 - Entries in a Type 0 font dictionary
Key Type Value
ToUnicode stream (Optional) A stream containing a CMap file that maps character codes to Unicode values (see 9.9.2, "Font subsets" 9.10, "Extraction of Text Content" ).

9.8 Font descriptors

9.8.1 General

Change Table 120 as follows:

Table 120 - Entries common to all font descriptors
Key Type Value
FontName name (Required for non-Type 3 fonts) The PostScript name of the font. This name shall be the same as the value of BaseFont in the font or CIDFont dictionary that refers to this font descriptor. For Type 3 fonts that include a Name entry in the Type 3 font dictionary, this name shall match the value of that key. For all fonts other than Type 3 this name shall be the same as the value of BaseFont in the font or CIDFont dictionary that refers to this font descriptor.
FontWeight number integer

...

NOTE The definition of FontWeight in PDF matches the CSS font-weight property, but may be more constrained than font weights used by various font formats.

Descent number

(Required, except for Type 3 fonts) The maximum depth below the baseline reached by glyphs in this font. The value shall be a negative number less than or equal to zero.

NOTE While different font programs may define descender metrics using either positive or negative numbers (e.g. OpenType usWinDescent), PDF always expects negative values.

...

Add a new NOTE to the very end of clause 9.8.1 as follows:

NOTE: if the font descriptor is for an embedded font, then all fields of the descriptor are for that specific embedded (full or subset) font program. If it is for a referenced (non-embedded) font, then it applies to the source material found by the PDF Writer at the time of PDF creation.

9.8.3.3 FD

Change the second paragraph below EXAMPLE 1 as follows:

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 be a subset of the keys defined in "Table 120 - Entries common to all font descriptors" that override the font-wide attributes for that class only. This font descriptor shall contain contains entries for metric information only; it shall not include FontFile, FontFile2, FontFile3, or any of the entries listed in "Table 120 - Entries common to all font descriptors" "Table 122 - Additional font descriptor entries for CIDFonts".

9.10.3 ToUnicode CMaps

Change the last paragraph in EXAMPLE 2 as follows:

EXAMPLE 2

...

Finally, the character code <3A 51> is mapped to the Unicode value UNICODE HAN CHARACTER 'U+2003E' CJK UNIFIED IDEOGRAPH-2003E (U+2003E), which is expressed by the byte sequence <D840DC3E> in UTF-16BE encoding.

Add the following note below the third paragraph below EXAMPLE 2 as follows:

...

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.

NOTE the above requirements are specific to PDF and are not described in Adobe Technical Note #5411 "ToUnicode Mapping File Tutorial".


Last modified: 18 February 2024