PDF20 Spec 14 Accessibility

14.9 Accessibility Support

Part of: PDF20-Spec-14-Document

Navigation: PDF20-Spec-14-Tagged-PDF | PDF20-Spec-Index | Next →

14.9 Repurposing and accessibility support 14.9.1

General

PDF includes several facilities in support of accessibility of documents to users with disabilities. In particular, many computer users with visual impairments use screen readers to read documents aloud. To enable proper vocalisation, either through a screen reader or by some more direct invocation of a text-to-speech engine, PDF supports the following features: •

Specifying the natural language used for text in a PDF document — for example, as English or Spanish (see 14.9.2, "Natural language specification")

•

Providing textual descriptions for images or other items that do not translate naturally into text (14.9.3, "Alternate descriptions"), or replacement text for content that does translate into text but is represented in a nonstandard way (such as with a ligature or illuminated character; see 14.9.4, "Replacement text")

•

Specifying the expansion of abbreviations or acronyms (14.9.5, "Expansion of abbreviations and acronyms")

•

Specifying pronunciation (14.9.6, "Pronunciation hints")

14.9.2

Natural language specification

14.9.2.1

General

Natural language may be specified for content in a document. The natural language used for content in a document shall be determined in a hierarchical fashion, based on whether an optional Lang entry (PDF 1.4) is present in any of several possible locations. At the highest level, the document’s default language (which applies to both text strings and text within content streams) may be specified by a Lang entry in the document catalog dictionary (see 7.7.2, "Document catalog dictionary"). This applies to both content within content streams and any text strings, including text strings not included in the structure hierarchy such as, for example, entries in metadata, outline entries and names for optional content groups. Below this, the language may be specified for the following items: •

Structure elements of any type (see 14.7.2, "Structure hierarchy"), through a Lang entry in the structure element dictionary. The language specified by a Lang entry shall apply to any content within content streams enclosed or referenced by the respective structure elements, to any ActualText, Alt, or E properties of the respective structure elements.

•

Marked-content sequences that are not in the structure hierarchy (see 14.6, "Marked content"), through a Lang entry in a property list attached to the marked-content sequence with a Span tag.

NOTE 1

•

Text strings encoded in Unicode may include an escape sequence using a language tag indicating the language of the text and overriding the prevailing Lang entry (see 7.9.2.2.2 "Text string language escape sequences").

NOTE 2

796

Although Span is also a standard structure type, as described under 14.8.4.7, "Inline level structure types", a marked-content sequence whose tag is Span is entirely independent of logical structure.

The natural language used for optional content allows content to be hidden or revealed based on the Lang entry (PDF 1.5) in the Language dictionary of an optional content usage dictionary (see "Table 100 — Entries in an optional content usage dictionary"). © ISO 2020 – All rights reserved

ISO 32000-2:2020(E)

14.9.2.2

Language identifiers

Certain language-related dictionary entries are text strings that specify language identifiers. Such text strings may appear as Lang entries in the following structures or dictionaries: •

Document catalog dictionary, structure element dictionary, or property list.

•

In the optional content usage dictionary’s Language dictionary, the hierarchical issues described in 14.9.2.3, "Language specification hierarchy" shall not apply to this entry.

•

Font Descriptors for CIDFonts can have a Lang key (see "Table 122 — Additional font descriptor entries for CIDFonts").

UTF-16BE or UTF-8 text strings can also have language escape sequences (see 7.9.2.2.2 "Text string language escape sequences"). A language identifier shall either be the empty text string, to indicate that the language is unknown, or a Language-Tag as defined in BCP 47. Although language codes are commonly represented using lowercase letters and country codes are commonly represented using uppercase letters, all language tags shall be treated as case-insensitive. Non-linguistic content should be marked with language code "zxx" (as defined in BCP 47).

14.9.2.3

Language specification hierarchy

The Lang entry in the document catalog dictionary shall specify the default natural language for all text in the document. Language specifications may appear within structure elements, and they may appear within marked-content sequences that are not in the structure hierarchy. If present, such language specifications override the default. Language specifications within the structure hierarchy apply in this order: •

A structure element’s language specification. If a structure element does not have a Lang entry, the element shall inherit its language from any parent element that has one.

•

Within a structure element, a language specification for a nested structure element or markedcontent sequence

If only part of the page content is contained in the structure hierarchy, and the structured content is nested within non-structured content for which a different language specification applies, the structure element’s language specification shall take precedence. A language identifier attached to a marked-content sequence with the Span tag specifies the language for all text in the sequence except for nested marked-content that is contained in the structure hierarchy (in which case the structure element’s language applies) and except where overridden by language specifications for other nested marked-content. NOTE EXAMPLE 1

Examples in this subclause illustrate the hierarchical manner in which the language for text in a document is determined. This example shows how a language specified for the document as a whole could be overridden by one specified for a marked-content sequence within a page’s content stream, independent of any logical structure. In this case, the Lang entry in the document catalog dictionary (not shown) has the value en-US, meaning U.S. English, and it is overridden by the Lang property attached (with the Span tag) to the markedcontent sequence “Hasta la vista”. The Lang property identifies the language for this marked-content

797

ISO 32000-2:2020(E)

sequence with the value es-MX, meaning Mexican Spanish. 2 0 obj <</Type /Page /Contents 3 0 R …

endobj

%Page object %Content stream

3 0 obj %Page's content stream <</Length …>> stream BT (See you later, or as Arnold would say, ) Tj /Span <</Lang (es-MX)>> %Start of marked-content sequence BDC ("Hasta la vista.") Tj EMC %End of marked-content sequence ET endstream endobj

EXAMPLE 2

In the following example, the Lang entry in the structure element dictionary (specifying English) applies to the marked-content sequence having an MCID (marked-content identifier) value of 0 within the indicated page’s content stream. However, nested within that marked-content sequence is another one in which the Lang property attached with the Span tag (specifying Spanish) overrides the structure element’s language specification. This example omits required StructParents entries in the objects used as content items (see 14.7.5.4, "Finding structure elements from content items").

1 0 obj <</Type /StructElem /S /P /P … /K <</Type /MCR /Pg 2 0 R /MCID 0

/Lang (en-US)

endobj

%Structure element

2 0 obj <</Type /Page /Contents 3 0 R …

endobj

%Page object

%Structure type %Parent in structure hierarchy %Page containing marked-content sequence %Marked-content identifier %Language specification for this element

%Content stream

3 0 obj %Page's content stream <</Length …>> stream BT /P <</MCID 0 …>> %Start of marked-content sequence BDC (See you later, or in Spanish you would say, ) Tj /Span <</Lang (es-MX)>> %Start of nested marked-content sequence BDC (Hasta la vista.) Tj EMC %End of nested marked-content sequence EMC %End of marked-content sequence ET endstream endobj

798

ISO 32000-2:2020(E)

EXAMPLE 3

The page’s content stream consists of a marked-content sequence that specifies Spanish as its language by means of the Span tag with a Lang property. Nested within it is content that is part of a structure element (indicated by the MCID entry in that property list), and the language specification that applies to the latter content is that of the structure element, English. This example omits required StructParents entries in the objects used as content items (see 14.7.5.4, "Finding structure elements from content items").

1 0 obj <</Type /StructElem /S /P /P … /K <</Type /MCR /Pg 2 0 R /MCID 0

/Lang (en-US)

endobj

%Structure element

2 0 obj <</Type /Page /Contents 3 0 R …

endobj

%Page object

3 0 obj <</Length …>> stream /Span <</Lang (es-MX)>> BDC (Hasta la vista, ) Tj /P <</MCID 0 …>> sequence, BDC applies (as Arnold would say.) Tj EMC sequence EMC endstream endobj

%Page's content stream

14.9.2.4

%Structure type %Parent in structure hierarchy %Page containing marked-content sequence %Marked-content identifier %Language specification for this element

%Content stream

%Start of marked-content sequence

%Start of structured marked-content %to which structure element's language

%End of structured marked-content %End of marked-content sequence

Multi-language text arrays

A multi-language text array (PDF 1.5) allows multiple text strings to be specified, each in association with a language identifier (see the Alt entry in "Table 285 — Additional entries in a media clip data dictionary" and "Table 288 — Additional entries in a media clip section dictionary"). A multi-language text array shall contain pairs of strings. The first string in each pair shall be a language identifier 14.9.2.2, "Language identifiers"). A language identifier shall not appear more than once in the array; any unrecognised language identifier shall be ignored. An empty string specifies default text that may be used when no suitable language identifier is found in the array. The second string is text associated with the language. EXAMPLE

[(en-US) (My vacation) (fr) (mes vacances) () (default text)]

When a PDF processor searches a multi-language text array to find text for a given language, it shall look for an exact (though case-insensitive) match between the given language’s identifier and the language identifiers in the array. If no exact match is found, prefix matching shall be attempted in © ISO 2020 – All rights reserved 799

ISO 32000-2:2020(E)

increasing array order: a match shall be declared if the given identifier is a leading, case-insensitive, substring of an identifier in the array, and the first post-substring character in the array identifier is a hyphen. For example, given identifier en matches array identifier en-US, but given identifier en-US matches neither en nor en-GB. If no exact or prefix match can be found, the default text (if any) should be used.

14.9.3

Alternate descriptions

PDF documents may be enhanced by providing alternate descriptions for images, formulas, or other items that do not translate naturally into text. NOTE

Alternate descriptions are human-readable text that could, for example, be vocalised by a text-tospeech engine for the benefit of users with visual impairments.

An alternate description may be specified for the following items: •

A structure element (see 14.7.2, "Structure hierarchy"), through an Alt entry in the structure element dictionary

•

(PDF 1.5) A marked-content sequence (see 14.6, "Marked content"), through an Alt entry in a property list attached to the marked-content sequence with a Span tag.

•

Any type of annotation (see 12.5, "Annotations") that does not already have a text representation, through a Contents entry in the annotation dictionary

For annotation types that normally display text, the Contents entry of the annotation dictionary shall be used as the source for an alternate description. For annotation types that do not display text, a Contents entry may be included to specify an alternate description. An alternative name may be specified for an interactive form field (see 12.7, "Forms") which, if present, shall be used in place of the actual field name when an interactive PDF processor identifies the field in a user-interface. This alternative name, if provided, shall be specified using the TU entry of the field dictionary. When applied to structure elements, the alternate description text (see 7.9.2.2, "Text string type") is a complete (or whole) word or phrase substitution for the current element. If each of two (or more) elements in a sequence have an Alt entry in their dictionaries, they shall be treated as if a word break is present between them. The same applies to consecutive marked-content sequences. The Alt entry in property lists may be combined with other entries. EXAMPLE /Span

14.9.4

This example shows the Alt entry combined with a Lang entry. <</Lang (en-us) /Alt (six-point star)>> BDC (A) Tj EMC

Replacement text

Replacement text may be specified for the following items: •

A structure element (see 14.7.2, "Structure hierarchy"), by means of the optional ActualText entry (PDF 1.4) of the structure element dictionary.

•

(PDF 1.5) A marked-content sequence (see 14.6, "Marked content"), through an ActualText entry in a property list attached to the marked-content sequence with a Span tag.

800

ISO 32000-2:2020(E)

NOTE 1

Just as alternate descriptions can be provided for images and other items that do not translate naturally into text (as described in 14.9.3, “Alternate descriptions”), replacement text can be specified for content that does translate into text but is represented in a nonstandard way. These nonstandard representations can include, for example, glyphs for ligatures or custom characters, or inline graphics corresponding to letters in an illuminated manuscript.

The ActualText value shall be used as a replacement, not a description, for the content, providing text that is equivalent to what a person would see when viewing the content. The value of ActualText is a character substitution for the content enclosed by the structure element or marked-content sequence. If each of two (or more) consecutive structure or marked-content sequences has an ActualText entry, they shall be treated as if no word break is present between them. NOTE 2 EXAMPLE

The treatment of ActualText as a character replacement is different from the treatment of Alt, which is treated as a whole word or phrase substitution. This example shows the use of replacement text to indicate the correct character content in a case where hyphenation changes the spelling of a word (in German, up until spelling reforms, the word "Drucker" when hyphenated was rendered as "Druk-" and "ker").

(Dru) Tj /Span <</Actual Text (c)>> BDC (k-) Tj EMC (ker) '

Like alternate descriptions (and other text strings), replacement text, if encoded in Unicode, may include an escape sequence for indicating the language of the text. Such a sequence shall override the prevailing Lang entry (see 7.9.2.2, "Text string type").

14.9.5

Expansion of abbreviations and acronyms

The expansion of an abbreviation or acronym may be specified for the following items: •

Marked-content sequences, through an E property in a property list attached to the markedcontent sequence with a Span tag.

•

Structure elements, through an E entry in the structure element dictionary. (See "Table 355 — Entries in a structure element dictionary".)

NOTE 1

Abbreviations and acronyms can pose a problem for text-to-speech engines. Sometimes the full pronunciation for an abbreviation can be divined without aid. For example, a dictionary search will probably reveal that "Blvd." is pronounced "boulevard" and that "Ave." is pronounced "avenue." However, some abbreviations are difficult to resolve, as in the sentence "Dr. Healwell works at 123 Industrial Dr.".

EXAMPLE BT /Span <</E (Doctor)>> BDC (Dr.) Tj EMC (Healwell works at 123 Industrial ) Tj /Span <</E (Drive)>> BDC (Dr.) Tj EMC ET

801

ISO 32000-2:2020(E)

The E value (a text string) is a word or phrase substitution for the tagged text and therefore shall be treated as if a word break separates it from any surrounding text. The expansion text, if encoded in Unicode, may include an escape sequence for indicating the language of the text (see 7.9.2.2, "Text string type"). Such a sequence shall override the prevailing Lang entry. NOTE 2

14.9.6

Some abbreviations or acronyms are conventionally not expanded into words. For the text "XYZ", for example, either no expansion would be supplied (leaving its pronunciation up to the text-tospeech engine) or, to be safe, the expansion "X Y Z" would be specified.

Pronunciation hints

Content in a tagged PDF may be accompanied by hints for its correct pronunciation, for example for use by a text to speech function. Such pronunciation hints may be provided through the structure element entries PhoneticAlphabet and Phoneme (see "Table 355 — Entries in a structure element dictionary") and the structure tree root entry PronunciationLexicons (see "Table 354 — Entries in the structure tree root"). A PDF processor is not required to process pronunciation hints. NOTE

Usually text-to-speech functions support pronunciation reasonably well based on text provided in Unicode encoding combined with an indication of the language that applies to that text. For uncommon words or special cases though it can be useful, to provide explicit instructions for the pronunciation of a given text.

14.10

Web capture

14.10.1

General

The features described in this clause are deprecated with PDF 2.0. The information in the Web Capture data structures enables PDF processors to perform the following operations: •

Save locally and preserve the visual appearance of material from the Web

•

Retrieve additional material from the Web and add it to an existing PDF file

•

Update or modify existing material previously captured from the Web

•

Find source information for material captured from the Web, such as the URL (if any) from which it was captured

•

Find all material in a PDF file that was generated from a given URL

•

Find all material in a PDF file that matches a given digital identifier (MD5 hash)

The information needed to perform these operations shall be recorded in two data structures in the PDF file: •

The Web Capture information dictionary, which shall hold document-level information related to Web Capture.

•

The Web Capture content database, which shall hold a complete registry of the source content resources retrieved by Web Capture and where it came from.

NOTE

802

The Web Capture content database enables the capturing process to avoid downloading material that is already present in the PDF file.

ISO 32000-2:2020(E)

14.10.2

Web capture information dictionary

The optional SpiderInfo entry in the document catalog dictionary (see 7.7.2, "Document catalog dictionary"), if present, shall hold Web Capture information dictionary. “Table 386 — Entries in the Web Capture information dictionary” shows the entries in a web capture information dictionary. Table 386 — Entries in the Web Capture information dictionary Key

Type

Value

V

number

(Required) The Web Capture version number. The version number shall be 1.0 in a conforming PDF file. This value shall be a single real number, not a major and minor version number. EXAMPLE

C

array

A version number of 1.2 would be considered greater than 1.15.

(Optional) An array of indirect references to Web Capture command dictionaries (see 14.10.5.3, "Command dictionaries") describing commands that were used in building the PDF file. The commands shall appear in the array in the order in which they were executed in building the PDF file.

14.10.3

Content database

14.10.3.1

General

When a PDF file, or part of a PDF file, is built from a content resource stored in another format, such as an HTML page, the resulting PDF file (or portion thereof) may contain content from more than the single content resources. Conversely, since many content formats do not have static pagination, a single content resource may give rise to multiple PDF pages. To keep track of the correspondence between PDF content and the resources from which the content was derived, a PDF file may contain a content database that maps URLs and digital identifiers to PDF objects such as pages and XObjects. NOTE

By looking up digital identifiers in the database, Web Capture can determine whether newly downloaded content is identical to content already retrieved from a different URL. Thus, it can perform optimisations such as storing only one copy of an image that is referenced by multiple HTML pages.

Web Capture’s content database shall be organised into content sets. Each content set shall be a dictionary holding information about a group of related PDF objects generated from the same source data. A content set shall have for the value of its S (subtype) entry either the value SPS, for a page set, or SIS, for an image set. The mapping from a source content resource to a content set in a PDF document may be saved in the PDF file. The mapping may be an association from the resource's URL to the content set, stored in the PDF document's URLS name tree. The mapping may also be an association from a digital identifier (14.10.3.3, "Digital identifiers") generated from resource's data to the content set, stored in the PDF document's IDS name tree. Both associations may be present in the PDF file. © ISO 2020 – All rights reserved

803

ISO 32000-2:2020(E)

"Figure 114 — Simple Web Capture file structure" shows a simple web capture PDF file structure.

Figure 114 — Simple Web Capture file structure Entries in the URLS and IDS name trees may refer to an array of content sets or a single content set. If the entry is an array, the content sets need not have the same subtype; the array may include both page sets and image sets. "Figure 115 — Complex Web Capture file structure" shows a complex web capture PDF file structure.

804

ISO 32000-2:2020(E)

Figure 115 — Complex Web Capture file structure

14.10.3.2

URL strings

URLs associated with Web Capture content sets shall be reduced to a predictable, canonical form before being used as keys in the URLS name tree. The following steps describe how to perform this reduction, using terminology from Internet RFC 3986. This algorithm shall be applied for HTTP, FTP, and file URLs: Algorithm: URL strings a) If the URL is relative, it shall be converted into an absolute URL. b) If the URL contains one or more NUMBER SIGN (02h3) characters, it shall be truncated before the first NUMBER SIGN. c) Any uppercase ASCII characters within the scheme section of the URL shall be replaced with the corresponding lowercase ASCII characters. d) If there is a host section, any uppercase ASCII characters therein shall be converted to lowercase ASCII. © ISO 2020 – All rights reserved

805

ISO 32000-2:2020(E)

e) If the scheme is file and the host is localhost, the host section shall be removed. f) If there is a port section and the port is the default port for the given protocol (80 for HTTP or 21 for FTP), the port section shall be removed. g) If the path section contains PERIOD (2Eh) ( . ) or DOUBLE PERIOD ( .. ) subsequences, transform the path as described in section 5.2 of Internet RFC 3986. NOTE

Because the PERCENT SIGN (25h) is unsafe according to Internet RFC 3986 and is also the escape character for encoded characters, a URL with unencoded characters cannot be distinguished from one with encoded characters. For example, it is impossible to decide whether the sequence %00 represents a single encoded null character or a sequence of three unencoded characters. Hence, no number of encoding or decoding passes on a URL can ever cause it to reach a stable state. Empirically, URLs embedded in HTML files have unsafe characters encoded with one encoding pass, and Web servers perform one decoding pass on received paths (though CGI scripts can make their own decisions).

Canonical URLs are thus assumed to have undergone one and only one encoding pass. A URL whose initial encoding state is known can be safely transformed into a URL that has undergone only one encoding pass.

14.10.3.3

Digital identifiers

Digital identifiers, used to associate source content resources with content sets by the IDS name tree, shall be generated using the MD5 message-digest algorithm (Internet RFC 1321). NOTE 1

The exact data passed to the algorithm depends on the type of content set and the nature of the identifier being calculated.

For a page set, the source data shall be passed to the MD5 algorithm first, followed by strings representing the digital identifiers of any auxiliary data files (such as images) referenced in the source data, in the order in which they are first referenced. If an auxiliary file is referenced more than once, its identifier shall be passed only the first time. The resulting string shall be used as the digital identifier for the source content resource. NOTE 2

This sequence produces a composite identifier representing the visual appearance of the pages in the page set.

NOTE 3

Two HTML source files that are identical, but for which the referenced images contain different data — for example, if they have been generated by a script or are pointed to by relative URLs — do not produce the same identifier.

When the source data is a PDF file, the identifier shall be generated solely from the contents of that file; there shall be no auxiliary data. A page set may also have a text identifier, calculated by applying the MD5 algorithm to just the text present in the source data. EXAMPLE 1

For an HTML file the text identifier is based solely on the text between markup tags; no images are used in the calculation.

For an image set, the digital identifier shall be calculated by passing the source data for the original image to the MD5 algorithm.

806

ISO 32000-2:2020(E)

EXAMPLE 2

The identifier for an image set created from a GIF image is calculated from the contents of the GIF.

14.10.3.4

Unique name generation

In generating PDF pages from a data source, items such as hypertext links and HTML form fields are converted into corresponding named destinations and interactive form fields. These items shall be given names that do not conflict with those of other such items in the PDF file. NOTE

As used here, the term name refers to a string, not a PDF name object.

Furthermore, when updating an existing PDF file, a PDF processor shall ensure that each destination or field is given a unique name that shall be derived from its original name but constructed so that it avoids conflicts with similarly named items elsewhere. The unique name shall be formed by appending an encoded form of the page set’s digital identifier string to the original name of the destination or field. The identifier string shall be encoded to remove characters that have special meaning in destinations and fields. The characters listed in the first column of "Table 387 — Characters with special meaning in destinations and fields and their byte values" have special meaning and shall be encoded using the corresponding byte values from the second column of "Table 387 — Characters with special meaning in destinations and fields and their byte values". Table 387 — Characters with special meaning in destinations and fields and their byte values Character

EXAMPLE

Byte value

Escape sequence

(nul)

0x00

\0 (0x5c 0x30)

.

(PERIOD)

0x2e

\p (0x5c 0x70)

\

(backslash)

0x5c

\ (0x5c 0x5c)

Since the PERIOD character (2Eh) is used as the field separator in interactive form field names, it does not appear in the identifier portion of the unique name.

If the name is used for an interactive form field, there is an additional encoding to ensure uniqueness and compatibility with interactive forms. Each byte in the source string, encoded as described previously, shall be replaced by two bytes in the destination string. The first byte in each pair is 65 (corresponding to the ASCII character A) plus the high-order 4 bits of the source byte; the second byte is 65 plus the low-order 4 bits of the source byte.

14.10.4

Content sets

14.10.4.1

General

A Web Capture content set is a dictionary describing a set of PDF objects generated from the same source data. It may include information common to all the objects in the set as well as about the set itself. "Table 388 — Entries common to all Web Capture content sets" defines the contents of this type of dictionary.

807

ISO 32000-2:2020(E)

14.10.4.2

Page sets

A page set is a content set containing a group of PDF page objects generated from a common source, such as an HTML file. The pages shall be listed in the O array of the page set dictionary (see "Table 388 — Entries common to all Web Capture content sets") in the same order in which they were initially added to the PDF file. A single page object shall not belong to more than one page set. "Table 389 — Additional entries specific to a Web Capture page set" defines the content set dictionary entries specific to Page Sets. The TID (text identifier) entry may be used to store an identifier generated from the text of the pages belonging to the page set (see 14.10.3.3, "Digital identifiers"). A text identifier may not be appropriate for some page sets (such as those with no text) and may be omitted in these cases. EXAMPLE

This identifier can be used to determine whether the text of a document has changed.

Table 388 — Entries common to all Web Capture content sets Key

Type

Value

Type name

(Optional) The type of PDF object that this dictionary describes; if present, shall be SpiderContentSet for a Web Capture content set.

S

name

(Required) The subtype of content set that this dictionary describes. The value shall be one of: SPS ("Spider page set") A page set SIS ("Spider image set") An image set

ID

byte string (Required) The digital identifier of the content set (see Digital identifiers").

O

array

(Required) An array of indirect references to the objects belonging to the content set. The order of objects in the array is restricted when the content set subtype (S entry) is SPS (see 14.10.4.2, "Page sets").

SI

dictionary or array

(Required) A source information dictionary (see 14.10.5, "Source information") or an array of such dictionaries, describing the sources from which the objects belonging to the content set were created.

CT

ASCII string

(Optional) The content type, an ASCII string characterising the source from which the objects belonging to the content set were created. The string shall conform to the content type specification described in Internet RFC 2045. EXAMPLE

TS

date

For a page set consisting of a group of PDF pages created from an HTML file, the content type would be text/html.

(Optional) A timestamp giving the date and time at which the content set was created.

Table 389 — Additional entries specific to a Web Capture page set

808

Key

Type

Value

S

name

ISO 32000-2:2020(E)

Key

Type

Value

T

text string

(Optional) The title of the page set, a human-readable text string.

TID

byte string

(Optional) A text identifier generated from the text of the page set, as described in 14.10.3.3, "Digital identifiers".

14.10.4.3

Image sets

An image set is a content set containing a group of image XObjects generated from a common source, such as multiple frames of an animated GIF image. A single XObject shall not belong to more than one image set. "Table 390 — Additional entries specific to a Web Capture image set" shows the content set dictionary entries specific to Image Sets. Table 390 — Additional entries specific to a Web Capture image set Key

Type

Value

S

name

(Required) The subtype of content set that this dictionary describes; shall be SIS.

R

integer or array

(Required) The reference counts for the image XObjects belonging to the image set. For an image set containing a single XObject, the value shall be the integer reference count for that XObject. For an image set containing multiple XObjects, the value shall be an array of reference counts parallel to the O array (see "Table 388 — Entries common to all Web Capture content sets"); that is, each element in the R array shall hold the reference count for the image XObject at the corresponding position in the O array.

Each image XObject in an image set has a reference count indicating the number of PDF pages referring to that XObject. The reference count shall be incremented whenever Web Capture creates a new page referring to the XObject (including copies of already existing pages) and decremented whenever such a page is destroyed. The reference count shall be incremented or decremented only once per page, regardless of the number of times the XObject may be referenced by that page. If the reference count reaches 0, it shall be assumed that there are no remaining pages referring to the XObject and that the XObject can be removed from the image set’s O array. When removing an XObject from the O array of an image set, the corresponding entry in the R array shall be removed also.

14.10.5

Source information

14.10.5.1

General

The SI entry in a content set dictionary (see "Table 388 — Entries common to all Web Capture content sets") shall contain one or more source information dictionaries, (see "Table 391 — Entries in a source information dictionary") each containing information about the locations from which the source data for the content set was retrieved.

809

ISO 32000-2:2020(E)

Table 391 — Entries in a source information dictionary Key

Type

Value

AU

ASCII string or dictionary

(Required) An ASCII string or URL alias dictionary (see 14.10.5.2, "URL alias dictionaries") which shall identify the URLs from which the source data were retrieved.

TS

date

(Optional) A timestamp which, if present, shall contain the most recent date and time at which the content set’s contents were known to be up to date with the source data.

E

date

(Optional) An expiration stamp which, if present, shall contain the date and time at which the content set’s contents is out of date with the source data.

S

integer

(Optional) A code which, if present, shall indicate the type of form submission, if any, by which the source data were accessed (see 12.7.6.2, "Submit-form action"). If present, the value of the S entry shall be 0, 1, or 2, in accordance with the following meanings: 0 Not accessed by means of a form submission 1 Accessed by means of an HTTP GET request 2 Accessed by means of an HTTP POST request This entry may be present only in source information dictionaries associated with page sets. Default value: 0.

C

dictionary

(Optional; if present, shall be an indirect reference) A command dictionary (see 14.10.5.3, "Command dictionaries") describing the command that caused the source data to be retrieved. This entry may be present only in source information dictionaries associated with page sets.

A content set's SI entry may contain a single source information dictionary. However, a PDF processor may attempt to detect situations in which the same source data has been located via two or more distinct URLs. If a processor detects such a situation, it may generate a single content set from the source data, containing a single copy of the relevant PDF pages or image XObjects. In this case, the SI entry shall be an array containing one source information dictionary for each distinct URL from which the original source content was found. The determination that distinct URLs produce the same source data shall be made by comparing digital identifiers for the source data. A source information dictionary’s AU (aliased URLs) entry shall identify the URLs from which the source data were retrieved. If there is only one such URL, the v value of this entry may be a string. If multiple URLs map to the same location through redirection, the AU value shall be a URL alias dictionary (see 14.10.5.2, "URL alias dictionaries"). NOTE 1

For PDF file size efficiency, the entire URL alias dictionary (excluding the URL strings) can be represented as a direct object because its internal structure is never shared or externally referenced.

The TS (timestamp) entry allows each source location associated with a content set to have its own timestamp.

810

ISO 32000-2:2020(E)

NOTE 2

This is necessary because the timestamp in the content set dictionary (see "Table 388 — Entries common to all Web Capture content sets") merely refers to the creation date of the content set. A hypothetical "Update Content Set" command could reset the timestamp in the source information dictionary to the current time if it found that the source data had not changed since the timestamp was last set.

The E (expiration) entry specifies an expiration date for each source location associated with a content set. If the current date and time are later than those specified, the contents of the content set is out of date with respect to the original source.

14.10.5.2

URL alias dictionaries

When a URL is accessed via HTTP, a response header may be returned indicating that the requested data are at a different URL. This redirection process may be repeated in turn at the new URL and can potentially continue indefinitely. It is not uncommon to find multiple URLs that all lead eventually to the same destination through one or more redirections. A URL alias dictionary represents such a set of URL chains leading to a common destination. "Table 392 — Entries in a URL alias dictionary" shows the contents of this type of dictionary. Table 392 — Entries in a URL alias dictionary Key

Type

Value

U

ASCII string

(Required) The destination URL to which all of the chains specified by the C entry lead.

C

array

(Optional) An array of one or more arrays of strings, each representing a chain of URLs leading to the common destination specified by U.

The C (chains) entry may be omitted if the URL alias dictionary contains only one URL. If C is present, its value shall be an array of arrays, each representing a chain of URLs leading to the common destination. Within each chain, the URLs shall be stored as ASCII strings in the order in which they occur in the redirection sequence. The common destination (the last URL in a chain) may be omitted, since it is already identified by the U entry.

14.10.5.3

Command dictionaries

A Web Capture command dictionary represents a command executed by Web Capture to retrieve one or more pieces of source data that were used to create new pages or modify existing pages. The entries in this dictionary represent parameters that were originally specified interactively by the user who requested that the Web content be captured. This information is recorded so that the command can subsequently be repeated to update the captured content. "Table 393 — Entries in a Web Capture command dictionary" shows the contents of this type of dictionary. Table 393 — Entries in a Web Capture command dictionary Key

Type

Value

URL

ASCII string

(Required) The initial URL from which source data were requested.

811

ISO 32000-2:2020(E)

Key

Type

Value

L

integer

(Optional) The number of levels of pages retrieved from the initial URL. Default value: 1.

F

integer

(Optional) A set of flags specifying various characteristics of the command (see "Table 393 — Entries in a Web Capture command dictionary"). Default value: 0.

P

string or stream (Optional) Data that was posted to the URL.

CT

ASCII string

(Optional) A content type describing the data posted to the URL. Default value: application/x-www-form-urlencoded.

H

string

(Optional) Additional HTTP request headers sent to the URL.

S

dictionary

(Optional) A command settings dictionary containing settings used in the conversion process (see 14.10.5.4, "Command settings").

The URL entry shall contain the initial URL for the retrieval command. The L (levels) entry shall contain the number of levels of the hyperlinked URL hierarchy to follow from this URL, creating PDF pages from the retrieved material. If the L entry is omitted, its value shall be assumed to be 1, denoting retrieval of the initial URL only. The value of the command dictionary’s F entry shall be an integer that shall be interpreted as an array of flags specifying various characteristics of the command. The flags shall be interpreted as defined in "Table 394 — Web Capture command flags". Only those flags defined in "Table 394 — Web Capture command flags" may be set to 1; all other flags shall be 0. Flags not defined in "Table 394 — Web Capture command flags" are reserved for future use, and shall not be used by a PDF processor. NOTE 1

The low-order bit of the flags value is referred to as being at bit-position 1.

Table 394 — Web Capture command flags Bit position

Name

Meaning

1

SameSite

If set, pages were retrieved only from the host specified in the initial URL.

2

SamePath

If set, pages were retrieved only from the path specified in the initial URL.

3

Submit

If set, the command represents a form submission.

The SamePath flag shall be set if the retrieval of source content was restricted to source content in the same path as specified in the initial URL. Source content is in the same path if its scheme and network location components (as defined in Internet RFC 3986) match those of the initial URL and its path component matches up to and including the last forward slash (/) character in the initial URL. EXAMPLE 1

812

the URL http://www.iso.org/fiddle/faddle/foo.html is considered to be in the same path as the initial URL

ISO 32000-2:2020(E)

http://www.iso.org/fiddle/initial.html.

The comparison shall be case-insensitive for the scheme and network location components and casesensitive for the path component. The Submit flag shall be set when the command represents a form submission. If no P (posted data) entry is present, the submitted data shall be encoded in the URL (an HTTP GET request). If P is present, the command shall be an HTTP POST request. In this case, the value of the Submit flag shall be ignored. NOTE 2

If the posted data are small enough, they can be represented by a string. For large amounts of data, a stream needs to be used because it can be compressed.

The CT (content type) entry shall only be present for POST requests. It shall describe the content type of the posted data, as described in Internet RFC 2045. The H (headers) entry, if present, shall specify additional HTTP request headers that were sent in the request for the URL. Each header line in the string shall be terminated with a CARRIAGE RETURN and a LINE FEED, as in this example: EXAMPLE 2

(Referer: http://frumble.com\015\012From:veeble@frotz.com\015\012)

The HTTP request header format is specified in Internet RFC 7231. The S (settings) entry specifies a command settings dictionary (see 14.10.5.4, "Command settings"). Holding settings specific to the conversion engines.

14.10.5.4

Command settings

The S (settings) entry in a command dictionary, if present, shall contain a command settings dictionary, which holds settings for conversion engines that shall be used in converting the results of the command to PDF. "Table 395 — Entries in a Web Capture command settings dictionary" shows the contents of this type of dictionary. If this entry is omitted, default values are assumed. Command settings dictionaries may be shared by any command dictionaries that use the same settings. Table 395 — Entries in a Web Capture command settings dictionary Key

Type

Value

G

dictionary

(Optional) A dictionary containing global conversion engine settings relevant to all conversion engines. If this entry is absent, default settings shall be used.

C

dictionary

(Optional) Settings for specific conversion engines. Each key in this dictionary is the internal name of a conversion engine. The associated value is a dictionary containing the settings associated with that conversion engine. If the settings for a particular conversion engine are not found in the dictionary, default settings shall be used.

Each key in the C dictionary represents the internal name of a conversion engine, which shall be a name object of the following form (without any spaces): /company:product:version:contentType

813

ISO 32000-2:2020(E)

•

company denotes the name (or abbreviation) of the company that created the conversion engine.

•

product denotes the name of the conversion engine. This field may be left blank, but the trailing COLON character (3Ah) is still required.

•

version denotes the version of the conversion engine.

•

contentType denotes an identifier for the content type the associated settings. shall be used because some converters may handle multiple content types.

EXAMPLE

/ADBE:H2PDF:1.0:HTML

All fields in the internal name are case-sensitive. The company field shall conform to the naming guidelines described in Annex E, "Extending PDF". The values of the other fields shall be unrestricted, except that they shall not contain a COLON. The directed graph of PDF objects rooted by the command settings dictionary shall be entirely selfcontained; that is, it shall not contain any object referred to from elsewhere in the PDF file. NOTE

14.10.6

This facilitates the operation of making a deep copy of a command settings dictionary without explicit knowledge of the settings it can contain.

Object attributes related to web capture

A given page object or image XObject may belong to at most one Web Capture content set, called its parent content set. However, the object shall not have direct pointer to its parent content set. Such a pointer may present problems for an application that traces all pointers from an object to determine what resources the object depends on. Instead, the object’s ID entry (see "Table 31 — Entries in a page object" and "Table 87 — Additional entries specific to an image dictionary") contains the digital identifier of the parent content set, which shall be used to locate the parent content set using the IDS name tree in the document’s name dictionary. (If the IDS entry for the identifier contains an array of content sets, the parent may be found by searching the array for the content set whose O entry includes the child object.) In the course of creating PDF pages from HTML files, Web Capture frequently scales the contents down to fit on fixed-sized pages. The PZ (preferred zoom) entry in a page object (see 7.7.3.3, "Page objects") specifies a magnification factor by which the page may be scaled to undo the downscaling and view the page at its original size. That is, when the page is viewed at the preferred magnification factor, one unit in default user space corresponds to one original source pixel.

14.11

Prepress support

14.11.1

General

This subclause describes features of PDF that support prepress production workflows: •

The specification of page boundaries governing various aspects of the prepress process, such as cropping, bleed, and trimming (14.11.2, "Page boundaries")

•

Facilities for including printer’s marks, such as registration targets, gray ramps, colour bars, and cut marks to assist in the production process (14.11.3, "Printer’s marks")

814

ISO 32000-2:2020(E)

•

Information for generating colour separations for pages in a document (14.11.4, "Separation dictionaries")

•

Output intents for matching the colour characteristics of a document with those of a target output device or production environment in which it will be printed (14.11.5, "Output intents")

•

Support for the generation of traps to minimise the visual effects of misregistration between multiple colourants (14.11.6, "Trapping support")

•

The Open Prepress Interface (OPI) for creating low-resolution proxies for high-resolution images (14.11.7, "Open prepress interface (OPI)"). This feature is deprecated with PDF 2.0.

•

When overprinting (see 8.6.7, "Overprint control") is enabled, and the device is a subtractive colour device, "rendering for separations" may be implemented (see 10.8.2, "Separations"). In addition, a PDF processor may optionally support "separation simulation" for any device (see 10.8.3, "Separation simulation").

14.11.2

Page boundaries

14.11.2.1

General

A PDF page may be prepared either for a finished medium, such as a sheet of paper, or as part of a prepress process in which the content of the page is placed on an intermediate medium, such as film or an imposed reproduction plate. In the latter case, it is important to distinguish between the intermediate page and the finished page. The intermediate page may often include additional production-related content, such as bleeds or printer marks, that falls outside the boundaries of the finished page. To handle such cases, a PDF page may define as many as five separate boundaries to control various aspects of the imaging process: •

The media box defines the boundaries of the physical medium on which the page is to be printed. It may include any extended area surrounding the finished page for bleed, printing marks, or other such purposes. It may also include areas close to the edges of the medium that cannot be marked because of physical limitations of the output device. Content falling outside this boundary may safely be discarded without affecting the meaning of the PDF file.

•

The crop box defines the region to which the contents of the page shall be clipped (cropped) when displayed or printed. Unlike the other boxes, the crop box has no defined meaning in terms of physical page geometry or intended use; it merely imposes clipping on the page contents. However, in the absence of additional information (such as imposition instructions specified in a JDF job ticket), the crop box determines how the page’s contents shall be positioned on the output medium. The default value is the page’s media box.

•

The bleed box (PDF 1.3) defines the region to which the contents of the page shall be clipped when output in a production environment. This may include any extra bleed area needed to accommodate the physical limitations of cutting, folding, and trimming equipment. The actual printed page may include printing marks that fall outside the bleed box. The default value is the page’s crop box.

•

The trim box (PDF 1.3) defines the intended dimensions of the finished page after trimming. It may be smaller than the media box to allow for production-related content, such as printing instructions, cut marks, or colour bars. The default value is the page’s crop box.

•

The art box (PDF 1.3) defines the extent of the page’s meaningful content (including potential white-space) as intended by the page’s creator. The default value is the page’s crop box.

The page object dictionary specifies these boundaries in the MediaBox, CropBox, BleedBox, TrimBox, and ArtBox entries, respectively (see "Table 31 — Entries in a page object"). All of them are rectangles expressed in default user space units. The crop, bleed, trim, and art boxes should not ordinarily extend © ISO 2020 – All rights reserved 815

ISO 32000-2:2020(E)

beyond the boundaries of the media box. If the bounds of the crop, trim, bleed or art box extends outside of the bounds of the media box, a processor shall treat the box as its intersection with the media box. "Figure 116 — Page boundaries" illustrates the relationships among these boundaries. (The crop box is not shown in the figure because it has no defined relationship with any of the other boundaries.)

Figure 116 — Page boundaries NOTE

816

How the various boundaries are used depends on the purpose to which the page is being put. The following are typical purposes: o

Placing the content of a page in another application. The art box determines the boundary of the content that is to be placed in the application. Depending on the applicable usage conventions, the placed content can be clipped to either the art box or the bleed box. For example, a quarter-page advertisement to be placed on a magazine page might be clipped to the art box on the two sides of the ad that face into the middle of the page and to the bleed box on the two sides that bleed over the edge of the page. The media box and trim box are ignored.

o

ISO 32000-2:2020(E)

box and bleed box are ignored. The media box can be used as advice for selecting media of the appropriate size. The crop box and trim box, if present, needs to be the same as the media box.

14.11.2.2

o

Printing an intermediate page for use in a prepress process. The art box is ignored. The bleed box defines the boundary of the content to be imaged. The trim box specifies the positioning of the content on the medium; it can also be used to generate cut or fold marks outside the bleed box. Content falling within the media box but outside the bleed box might or might not be imaged, depending on the specific production process being used.

o

Building an imposition of multiple pages on a press sheet. The art box is ignored. The bleed box defines the clipping boundary of the content to be imaged; content outside the bleed box is ignored. The trim box specifies the positioning of the page’s content within the imposition. Cut and fold marks are typically generated for the imposition as a whole.

Display of page boundaries

Interactive PDF processors may offer the ability to display guidelines on the screen for the various page boundaries. The optional BoxColorInfo entry in a page object (see 7.7.3.3, "Page objects") holds a box colour information dictionary (PDF 1.4) specifying the colours and other visual characteristics to be used for such display. interactive PDF processors typically provide a user interface to allow the user to set these characteristics interactively. NOTE

This information is page-specific and can vary from one page to another.

As shown in "Table 396 — Entries in a box colour information dictionary", the box colour information dictionary may contain an optional entry for each of the possible page boundaries other than the media box. The value of each entry is a box style dictionary, whose contents are shown in "Table 397 — Entries in a box style dictionary". If a given entry is absent, the interactive PDF processor shall use its own current default settings instead. Table 396 — Entries in a box colour information dictionary Key

Type

Value

CropBox

dictionary

(Optional) A box style dictionary (see "Table 397 — Entries in a box style dictionary") specifying the visual characteristics for displaying guidelines for the page’s crop box. This entry shall be ignored if no crop box is defined in the page object.

BleedBox dictionary

(Optional) A box style dictionary (see "Table 397 — Entries in a box style dictionary") specifying the visual characteristics for displaying guidelines for the page’s bleed box. This entry shall be ignored if no bleed box is defined in the page object.

TrimBox dictionary

(Optional) A box style dictionary (see "Table 397 — Entries in a box style dictionary") specifying the visual characteristics for displaying guidelines for the page’s trim box. This entry shall be ignored if no trim box is defined in the page object.

ArtBox

(Optional) A box style dictionary (see "Table 397 — Entries in a box style dictionary") specifying the visual characteristics for displaying guidelines for the page’s art box. This entry shall be ignored if no art box is defined in the page object.

dictionary

817

ISO 32000-2:2020(E)

Table 397 — Entries in a box style dictionary Key

Type

Value

C

array

(Optional) An array of three numbers in the range 0.0 to 1.0, representing the components in the DeviceRGB colour space of the colour that shall be used for displaying the guidelines. Default value: [0.0 0.0 0.0].

W

number

(Optional) The guideline width in default user space units. Default value: 1.

S

name

(Optional) The guideline style: S (Solid) A solid rectangle. D (Dashed) A dashed rectangle. The dash pattern shall be specified by the D entry. Other guideline styles may be defined in the future. Default value: S.

D

array

(Optional) A dash array defining a pattern of dashes and gaps that shall be used in drawing dashed guidelines (guideline style D). The dash array shall be specified in default user space units, in the same format as in the line dash pattern parameter of the graphics state (see 8.4.3.6, "Line dash pattern"). The dash phase shall not be specified and shall be assumed to be 0. EXAMPLE

A D entry of [3 2] specifies guidelines drawn with 3-unit dashes alternating with 2-unit gaps.

Default value: [3].

14.11.3

Printer’s marks

Printer’s marks are graphic symbols or text added to a page to assist production personnel in identifying components of a multiple-plate job and maintaining consistent output during production. Examples commonly used in the printing industry include: •

Registration targets for aligning plates

•

Gray ramps and colour bars for measuring colours and ink densities

•

Cut marks showing where the output medium is to be trimmed

Although PDF writers traditionally include such marks in the content stream of a document, they are logically separate from the content of the page itself and typically appear outside the boundaries (the crop box, trim box, and art box) defining the extent of that content (see 14.11.2, "Page boundaries"). Printer’s mark annotations (PDF 1.4) provide a mechanism for incorporating printer’s marks into the PDF representation of a page, while keeping them separate from the actual page content. Each page in a PDF document may contain any number of such annotations, each of which represents a single printer’s mark. The annotation rectangle should not intersect the TrimBox. NOTE 1

818

Because printer’s marks typically fall outside the page’s content boundaries, each mark is represented as a separate annotation. Otherwise — if, for example, the cut marks at the four corners of the page were defined in a single annotation — the annotation rectangle would encompass the entire contents of the page and could interfere with the user’s ability to select content or interact with other annotations on the page. Defining printer’s marks in separate annotations also facilitates the implementation of a drag-and-drop user interface for specifying them. © ISO 2020 – All rights reserved

ISO 32000-2:2020(E)

The visual presentation of a printer’s mark shall be defined by a form XObject specified as an appearance stream in the N (normal) entry of the printer’s mark annotation’s appearance dictionary (see 12.5.5, "Appearance streams"). More than one appearance may be defined for the same printer’s mark to meet the requirements of different regions or production facilities. In this case, the appearance dictionary’s N entry holds a subdictionary containing the alternative appearances, each identified by an arbitrary key. The AS (appearance state) entry in the annotation dictionary designates one of them to be displayed or printed. NOTE 2

The printer’s mark annotation’s appearance dictionary can include R (rollover) or D (down) entries, but appearances defined in either of these entries are never displayed or printed.

Like all annotations, a printer’s mark annotation shall be defined by an annotation dictionary (see 12.5.2, "Annotation dictionaries"); its annotation type is PrinterMark. The AP (appearances) and F (flags) entries (which is ordinarily optional) shall be present, as shall the AS (appearance state) entry if the appearance dictionary AP contains more than one appearance stream. The Print and ReadOnly flags in the F entry shall be set and all others clear (see 12.5.3, "Annotation flags"). "Table 398 — Additional entries specific to a printer’s mark annotation" shows an additional annotation dictionary entry specific to this type of annotation. Table 398 — Additional entries specific to a printer’s mark annotation Key

Type

Value

Subtype

name

(Required) The type of annotation that this dictionary describes; shall be PrinterMark for a printer’s mark annotation.

MN

name

(Optional) An arbitrary name identifying the type of printer’s mark, such as ColorBar or RegistrationTarget.

The form dictionary defining a printer’s mark may contain the optional entries shown in "Table 399 — Additional entries specific to a printer’s mark form dictionary" in addition to the entries common to all form dictionaries (see 8.10.2, "Form dictionaries"). Table 399 — Additional entries specific to a printer’s mark form dictionary Key

Type

Value

MarkStyle

text string

(Optional; PDF 1.4) A text string representing the printer’s mark in humanreadable form and suitable for presentation to the user.

Colorants

dictionary

(Optional; PDF 1.4) A dictionary identifying the individual colourants associated with a printer’s mark, such as a colour bar. For each entry in this dictionary, the key is a colourant name and the value is an array defining a Separation colour space for that colourant (see 8.6.6.4, "Separation colour spaces"). The key shall match the colourant name given in that colour space.

14.11.4

Separation dictionaries

819

ISO 32000-2:2020(E)

In high-end printing workflows, pages are ultimately produced as sets of separations, one per colourant (see 8.6.6.4, "Separation colour spaces"). Ordinarily, each page in a PDF file shall be treated as a composite page that paints graphics objects using all the process colourants and perhaps some spot colourants as well. In other words, all separations for a page shall be generated from a single PDF description of that page. In some workflows, however, pages are preseparated before generating the PDF file. In a preseparated PDF file, the separations for a page shall be described as separate page objects, each painting only a single colourant (usually specified in the DeviceGray colour space). In this case, additional information is needed to identify the actual colourant associated with each separation and to group together the page objects representing all the separations for a given page. This information shall be contained in a separation dictionary (PDF 1.3) in the SeparationInfo entry of each page object (see 7.7.3.3, "Page objects"). "Table 400 — Entries in a separation dictionary" shows the contents of this type of dictionary. Table 400 — Entries in a separation dictionary Key

Type

Value

Pages

array

(Required) An array of indirect references to page objects representing separations of the same document page. One of the page objects in the array shall be the one with which this separation dictionary is associated, and all of them shall have separation dictionaries (SeparationInfo entries) containing Pages arrays identical to this one.

DeviceColorant name or (Required) The name of the device colourant that shall be used in rendering string this separation, such as Cyan or PANTONE 35 CV. ColorSpace

14.11.5

array

(Optional) An array defining a Separation or DeviceN colour space (see 8.6.6.4, "Separation colour spaces" and 8.6.6.5, "DeviceN colour spaces"). It provides additional information about the colour specified by DeviceColorant — in particular, the alternate colour space and tint transformation function that shall be used to represent the colourant as a process colour. This information enables an interactive PDF processor to preview the separation in a colour that approximates the device colourant. The value of DeviceColorant shall match the space’s colourant name (if it is a Separation space) or be one of the space’s colourant names (if it is a DeviceN space).

Output intents

Output intents (PDF 1.4) provide a means for matching the colour characteristics of page content in a PDF document with those of a target output device. The optional OutputIntents entry in the document catalog dictionary (see 7.7.2, "Document catalog dictionary") or a Page dictionary (see 7.7.3.3, "Page objects") holds an array of output intent dictionaries, each describing the colour reproduction characteristics of a possible output device. The contents of these dictionaries will often vary for different devices. The dictionary’s S entry specifies an output intent subtype that determines the format and meaning of the remaining entries. NOTE 1

820

This use of multiple output intents allows the output to be customised to the expected workflow and the specific tools available. For example, one processor can process PDF files conforming to a © ISO 2020 – All rights reserved

ISO 32000-2:2020(E)

recognised standard such as PDF/X-1a which is based upon CMYK processing, while another uses the PDF/A (ISO 19005) standard to produce RGB output for document distribution on the Web. Each of these workflows can require different sets of output intent information. Multiple output intents also allow the same PDF file to be distributed unmodified to multiple destinations. The choice of which output intent to use in a given workflow is outside the scope of ISO 32000-2 and therefore PDF intentionally does not include a selector for choosing a particular output intent from within the PDF file. It nevertheless does offer a provision for specifying a default output intent to be use if no other provisions are in effect.

At the time of publication, three output intent subtypes in the document catalog dictionary have been defined: GTS_PDFX, GTS_PDFA1, and ISO_PDFE1. "Table 401 — Entries in an output intent dictionary" lists the keys used in these subtypes of output intent dictionaries. Other subtypes may be added in the future; the names of any such additional subtypes shall conform to the naming guidelines described in Annex E, "Extending PDF". NOTE 2

GTS_PDFX corresponds to the PDF/X format standards (ISO 15930, all parts), GTS_PDFA1 corresponds to the PDF/A standards (ISO 19005, all parts), and ISO_PDFE1 corresponds to the PDF/E standards (ISO 24517, all parts). Use of one of these subtypes is assumed to imply semantics for the content of the output intent dictionary that are specified by those standards.

Table 401 — Entries in an output intent dictionary Key

Type

Value

Type

name

(Optional) The type of PDF object that this dictionary describes; if present, shall be OutputIntent for an output intent dictionary.

S

name

(Required) The output intent subtype. The value may be GTS_PDFX, GTS_PDFA1, ISO_PDFE1 or a key defined by an ISO 32000 extension.

OutputCondition

text string (Optional) A text string concisely identifying the intended output device or production condition in human-readable form. This is the preferred method of defining such a string for presentation to the user.

OutputConditionIdentifier text string (Required) A text string identifying the intended output device or production condition in human- or machine-readable form. If human-readable, this string may be used in lieu of an OutputCondition string for presentation to the user. A typical value for this entry may be the name of a production condition maintained in an industry-standard registry such as the ICC Characterization Data Registry. If the designated condition matches that in effect at production time, the production software is responsible for providing the corresponding ICC profile as defined in the registry. If the intended production condition is not a recognised standard, the value of this entry may be Custom or an application-specific, machine-readable name. The DestOutputProfile entry defines the ICC profile, and the Info entry shall be used for further humanreadable identification. RegistryName

text string (Optional) A text string (conventionally a uniform resource identifier, or URI) identifying the registry in which the condition designated by OutputConditionIdentifier is defined.

821

ISO 32000-2:2020(E)

Key

Type

Value

Info

text string (Required if OutputConditionIdentifier does not specify a standard production condition; optional otherwise) A human-readable text string containing additional information or comments about the intended target device or production condition.

DestOutputProfile

stream

DestOutputProfileRef

dictionary (Optional; PDF 2.0) A dictionary containing information about one or more referenced ICC profiles. See "Table 402 — Entries in a DestOutputProfileRef dictionary".

MixingHints

dictionary (Optional, PDF 2.0) A DeviceN Mixing Hints dictionary ("Table 72 — Entries in a DeviceN mixing hints dictionary") which shall not contain a DotGain key.

(Required if OutputConditionIdentifier does not specify a standard production condition; optional otherwise) An ICC profile stream defining the transformation from the PDF document’s source colours to output device colourants. The format of the profile stream is the same as that used in specifying an ICCBased colour space (see 8.6.5.5, "ICCBased colour spaces"). The output transformation uses the profile’s "from CIE" information (BToA in ICC terminology); the "to CIE" (AToB) information may optionally be used to remap source colour values to some other destination colour space, such as for screen preview or hardcopy proofing.

NOTE 1 This is because dot gain information is better handled according to ISO 17972-4.

In addition, each key in the Solidities dictionary referenced from the MixingHints dictionary shall not also be present in the SpectralData dictionary within the same output intent. NOTE 2 This is because it would not be clear which one is to be used, so only allowing one place where such data are present avoids the conflict.

This document intentionally does not specify how a PDF processor may make use of the data provided in the MixingHints dictionary, and a PDF processor may ignore such data altogether. EXAMPLE 1 The data in the MixingHints dictionary could be used in the process of rendering or color converting the colourants specified in the Solidities dictionary referenced from the MixingHints dictionary.

822

ISO 32000-2:2020(E)

Key

Type

Value

SpectralData

dictionary (Optional, PDF 2.0) A dictionary where each key represents a colourant name as defined in 8.6.6.4, "Separation colour spaces" and where the value of each key shall be a stream whose contents shall represent CxF/X-4 spot colour characterisation data that conform to ISO 17972-4. This stream shall contain exactly one SpotInkCharacterisation element whose SpotInkName matches the colourant name (see 7.3.5, "Name objects"). In addition, this stream may contain zero or more further SpotInkCharacterisation elements, and/or other data. NOTE 3 This facilitates referencing the same CxF/X-4 data stream from more than one entry in the SpectralData dictionary, as long as for each such entry there is a matching SpotInkCharacterisation entry in the CxF/X-4 data stream.

In addition, each key in this dictionary shall not also be present in the Solidities dictionary referenced from the MixingHints dictionary within the same output intent. NOTE 4 This is because it would not be clear which one is to be used, so by only allowing one place where such data are present it avoids the conflict.

This document intentionally does not specify how a PDF processor may make use of the data provided in the SpectralData dictionary, and a PDF processor may ignore such data altogether. EXAMPLE 2 The data in the SpectralData dictionary could be used in the process of rendering or colour converting the colourants specified in the SpectralData dictionary.

Table 402 — Entries in a DestOutputProfileRef dictionary Key

Type

Value

CheckSum

string

(Optional, PDF 2.0) An MD5 hash consisting of a 16 byte string that shall be computed as described in "7.11.4, "Embedded file streams" for the uncompressed ICC profile file. NOTE 1 Any MD5 embedded within the ICC profile itself is computed differently and is inappropriate for use as the value of the CheckSum key. NOTE 2 This is strictly a checksum, and is not used for security purposes.

ColorantTable array

(Optional, PDF 2.0) An array of colourant names, each of which shall be encoded as a name object. The order and names of the colourants in ColorantTable shall be identical to those in the ICC colorantTableTag in the ICC profile.

ICCVersion

string

(Optional, PDF 2.0) The value of bytes 8 to 11, ICC profile version number, from the header of the ICC profile.

ProfileCS

string

(Optional, PDF 2.0) The four-byte colour space signature of the ICC profile, including any space characters.

ProfileName

text string

(Optional, PDF 2.0) The value of the ICC profileDescriptionTag from the ICC profile.

823

ISO 32000-2:2020(E)

Key

Type

Value

URLs

array

(Optional, PDF 2.0) An array, containing at least one element, where each element shall be an embedded file specification (7.11.4, "Embedded file streams") or a URL file specification (7.11.5, "URL specifications"). NOTE: ICC profiles referenced via the URLs array do not have to conform to the ICCBased requirements of "Table 67 — ICC profile types" and thus can also support Ncomponent output profiles.

In addition to the output intent subtype being different in PDF/X, PDF/A and PDF/E, these standards also impose additional requirements on the presence (or absence) of the various keys in the output intent dictionary and the values thereof. The ICC profile information in an output intent dictionary should supplement rather than replace that in an ICCBased or default colour space (see 8.6.5.5, "ICCBased colour spaces" and 8.6.5.6, "Default colour spaces"). Those mechanisms are specifically intended for describing the characteristics of source colour component values. An output intent may be used in conjunction with them to convert source colours to those required for the intended output device. The data in an output intent dictionary shall be for informational purposes only, and PDF processors are free to disregard it. If a PDF processor chooses to respect output intents, then when processing a page that has an associated (page-level) output intent, that page-level output intent shall be used. NOTE 3

EXAMPLE 1

<<

There is no expectation that PDF production tools automatically convert colours expressed in the same source colour space to the specified target space before generating output. In some workflows, such conversion is undesirable. This Example shows a PDF/X output intent dictionary based on an industry-standard production condition (CGATS TR 001) from the ICC Characterization Data Registry. Example 2 shows one for a custom production condition. /Type /OutputIntent /S /GTS_PDFX /OutputCondition (CGATS TR 001 (SWOP)) /OutputConditionIdentifier (CGATS TR 001) /RegistryName (http://www.color.org) /DestOutputProfile 100 0 R

%Output intent dictionary

100 0 obj <</N 4 /Length 1605 /Filter /ASCIIHexDecode

stream 00 00 02 0C 61 70 … > endstream endobj

%ICC profile stream

EXAMPLE 2 <<

/Type /OutputIntent /S /GTS_PDFX /OutputCondition (Coated) /OutputConditionIdentifier (Custom) /Info (Coated 150lpi) /DestOutputProfile 100 0 R

%Output intent dictionary

824

ISO 32000-2:2020(E)

100 0 obj << /N 4 /Length 1605 /Filter /ASCIIHexDecode

stream 00 00 02 0C 61 70…> endstream endobj

14.11.6

Trapping support

14.11.6.1

General

%ICC profile stream

The features described in this clause are deprecated with PDF 2.0. On devices such as offset printing presses, which mark multiple colourants on a single sheet of physical medium, mechanical limitations of the device can cause imprecise alignment, or misregistration, between colourants. This can produce unwanted visual artifacts such as brightly coloured gaps or bands around the edges of printed objects. In high-quality reproduction of colour documents, such artifacts are commonly avoided by creating an overlap, called a trap, between areas of adjacent colour. NOTE

"Figure 117 — Trapping example" shows an example of trapping. The light and medium grays represent two different colourants, which are used to paint the background and the glyph denoting the letter A. The first figure shows the intended result, with the two colourants properly registered. The second figure shows what happens when the colourants are misregistered. In the third figure, traps have been overprinted along the boundaries, obscuring the artifacts caused by the misregistration. (For emphasis, the traps are shown here in dark gray; in actual practice, their colour will be similar to one of the adjoining colours.)

Figure 117 — Trapping example Trapping may be implemented by the application generating a PDF file, by some intermediate application that adds traps to a PDF document, or by the raster image processor (RIP) that produces final output. In the last two cases, the trapping process is controlled by a set of trapping instructions, which define two kinds of information: •

Trapping zones within which traps should be created

•

Trapping parameters specifying the nature of the traps within each zone

Trapping zones and trapping parameters are discussed fully in 6.3.2 and 6.3.3, respectively, of the PostScript Language Reference, Third Edition. Trapping instructions are not directly specified in a PDF © ISO 2020 – All rights reserved

825

ISO 32000-2:2020(E)

file (as they are in a PostScript file). Instead, they shall be specified in a job ticket that accompanies the PDF file or is embedded within it. NOTE

The primary format of job tickets is JDF (Job Definition Format) described in the CIP4 document JDF Specification.

When trapping is performed before the production of final output, the resulting traps shall be placed in the PDF file for subsequent use. The traps themselves shall be described as a content stream in a trap network annotation (see 14.11.6.2, "Trap network annotations"). The stream dictionary may include additional entries describing the method that was used to produce the traps and other information about their appearance.

14.11.6.2

Trap network annotations

The features described in this subclause are deprecated with PDF 2.0. A complete set of traps generated for a given page under a specified set of trapping instructions is called a trap network (PDF 1.3). It is a form XObject containing graphics objects for painting the required traps on the page. A page may have more than one trap network based on different trapping instructions, presumably intended for different output devices. All of the trap networks for a given page shall be contained in a single trap network annotation (see 12.5, "Annotations"). There may be at most one trap network annotation per page, which shall be the last element in the page’s Annots array (see 7.7.3.3, "Page objects"). This ensures that the trap network shall be printed after all of the page’s other contents. The form XObject defining a trap network shall be specified as an appearance stream in the N (normal) entry of the trap network annotation’s appearance dictionary (12.5.5, "Appearance streams"). If more than one trap network is defined for the same page, the N entry holds a subdictionary containing the alternate trap networks, each identified by an arbitrary key. The AS (appearance state) entry in the annotation dictionary designates one of them as the current trap network to be displayed or printed. NOTE 1

The trap network annotation’s appearance dictionary can include R (rollover) or D (down) entries, but appearances defined in either of these entries are never printed.

Like all annotations, a trap network annotation shall be defined by an annotation dictionary (see 12.5.2, "Annotation dictionaries"); its annotation type is TrapNet. The AP (appearances), AS (appearance state), and F (flags) entries (which ordinarily are optional) shall be present, with the Print and ReadOnly flags set and all others clear (see 12.5.3, "Annotation flags"). "Table 403 — Additional entries specific to a trap network annotation" shows the additional annotation dictionary entries specific to this type of annotation. The Version and AnnotStates entries, if present, shall be used to detect changes in the content of a page that might require regenerating its trap networks. The Version array identifies elements of the page’s content that might be changed by an editing application and thus invalidate its trap networks. Because there is at most one Version array per trap network annotation (and thus per page), any PDF writer that generates a new trap network shall also verify the validity of existing trap networks by enumerating the objects identified in the array and verifying that the results exactly match the array’s current contents. Any trap networks found to be invalid shall be regenerated. The LastModified entry may be used in place of the Version array to track changes to a page’s trap network. (The trap network annotation shall include either a LastModified entry or the combination 826 © ISO 2020 – All rights reserved

ISO 32000-2:2020(E)

of Version and AnnotStates, but not all three.) If the modification date in the LastModified entry of the page object (see 7.7.3.3, "Page objects") is more recent than the one in the trap network annotation dictionary, the page’s trap networks are invalid and shall be regenerated. NOTE 2

Not all editing applications correctly maintain these modification dates.

This method of tracking trap network modifications may be used reliably only in a controlled workflow environment where the integrity of the modification dates is assured. Table 403 — Additional entries specific to a trap network annotation Key

Type

Value

Subtype

name

(Required) The type of annotation that this dictionary describes; shall be TrapNet for a trap network annotation.

LastModified

date

(Required if Version and AnnotStates are absent; shall be absent if Version and AnnotStates are present; PDF 1.4) The date and time (see 7.9.4, "Dates") when the trap network was most recently modified.

Version

array

(Required if AnnotStates is present; shall be absent if LastModified is present) An unordered array of all objects present in the page description at the time the trap networks were generated and that, if changed, could affect the appearance of the page. If present, the array shall include the following objects: •

All content streams identified in the page object’s Contents entry (see 7.7.3.3, "Page objects")

•

All resource objects (other than procedure sets) in the page’s resource dictionary (see 7.8.3, "Resource dictionaries")

•

All resource objects (other than procedure sets) in the resource dictionaries of any form XObjects on the page (see 8.10, "Form XObjects")

•

All OPI dictionaries associated with XObjects on the page (see 14.11.7, "Open prepress interface (OPI)"). This entry is deprecated in PDF 2.0.

AnnotStates

array

(Required if Version is present; shall be absent if LastModified is present) An array of name objects representing the appearance states (value of the AS entry) for annotations associated with the page. The appearance states shall be listed in the same order as the annotations in the page’s Annots array (see 7.7.3.3, "Page objects"). For an annotation with no AS entry, the corresponding array element should be null. No appearance state shall be included for the trap network annotation itself.

FontFauxing

array

(Optional) An array of font dictionaries representing fonts that were fauxed (replaced by substitute fonts) during the generation of trap networks for the page.

14.11.6.3

Trap network appearances

The features described in this subclause are deprecated with PDF 2.0. Each entry in the N (normal) subdictionary of a trap network annotation’s appearance dictionary holds an appearance stream defining a trap network associated with the given page. Like all appearances, a trap network is a stream object defining a form XObject (see 8.10, "Form XObjects"). The body of the stream contains the graphics objects needed to paint the traps making up the trap network. Its © ISO 2020 – All rights reserved

827

ISO 32000-2:2020(E)

dictionary entries include, besides the standard entries for a form dictionary, the additional entries shown in "Table 404 — Additional entries specific to a trap network appearance stream". Table 404 — Additional entries specific to a trap network appearance stream Key

Type

Value

PCM

name

(Required) The name of the process colour model that was assumed when this trap network was created; equivalent to the PostScript language page device parameter ProcessColorModel (see clause 6.2.5 of the PostScript Language Reference, Third Edition). Valid values are DeviceGray, DeviceRGB, DeviceCMYK, DeviceCMY, DeviceRGBK, and DeviceN.

SeparationColorNames array

(Optional) An array of names identifying the colourants that were assumed when this network was created; equivalent to the PostScript language page device parameter of the same name (see clause 6.2.5 of the PostScript Language Reference, Third Edition). Colourants implied by the process colour model PCM are available automatically and need not be explicitly declared. If this entry is absent, the colourants implied by PCM shall be assumed.

TrapRegions

array

(Optional; deprecated in PDF 2.0) An array of indirect references to TrapRegion objects defining the page’s trapping zones and the associated trapping parameters, as described in Adobe Technical Note #5620, Portable Job Ticket Format. These references refer to objects comprising portions of a PJTF job ticket that shall be embedded in the PDF file. When the trapping zones and parameters are defined by an external job ticket (or by some other means, such as JDF), this entry shall be absent.

TrapStyles

text string

(Optional) A human-readable text string that applications may use to describe this trap network to the user. EXAMPLE

To allow switching between trap networks.

A PDF writer that supports preseparation shall perform that operation after trapping, and not before. It is also responsible for calculating new Version arrays for the separation trap networks. NOTE

14.11.7

Preseparated PDF pages in preseparated PDF files (see 14.11.4, "Separation dictionaries") cannot be trapped because traps are defined along the borders between different colours and a preseparated PDF file uses only one colour.

Open prepress interface (OPI)

The features described in this subclause are deprecated with PDF 2.0. The workflow in a prepress environment often involves multiple applications in areas such as graphic design, page layout, word processing, photo manipulation, and document construction. As pieces of the final document are moved from one application to another, it is useful to separate the data of highresolution images, which can be quite large — in some cases, many times the size of the rest of the document combined — from that of the document itself. The Open Prepress Interface (OPI) is a mechanism, originally developed by Aldus Corporation, for creating low-resolution placeholders, or proxies, for such high-resolution images. The proxy typically consists of a downsampled version of the full-resolution image, to be used for screen display and proofing. Before the document is printed, it

828

ISO 32000-2:2020(E)

passes through a filter known as an OPI server, which replaces the proxies with the original fullresolution images. NOTE 1

In PostScript programs, OPI proxies are defined by PostScript language code surrounded by special OPI comments, which specify such information as the placement and cropping of the image and adjustments to its size, rotation, colour, and other attributes.

In PDF, proxies shall be embedded in a document as image or form XObjects with an associated OPI dictionary (PDF 1.2). This dictionary contains the same information that the OPI comments convey in PostScript language. Two versions of OPI shall be supported, versions 1.3 and 2.0. In OPI 1.3, a proxy consisting of a single image, with no changes in the graphics state, may be represented as an image XObject; otherwise it shall be a form XObject. In OPI 2.0, the proxy always entails changes in the graphics state and hence shall be represented as a form XObject. An XObject representing an OPI proxy shall contain an OPI entry in its image or form dictionary (see "Table 87 — Additional entries specific to an image dictionary" and "Table 93 — Additional entries specific to a Type 1 form dictionary"). The value of this entry is an OPI version dictionary ("Table 405 — Entry in an OPI version dictionary") identifying the version of OPI to which the proxy corresponds. This dictionary consists of a single entry, whose key is the name 1.3 or 2.0 and whose value is the OPI dictionary defining the proxy’s OPI attributes. Table 405 — Entry in an OPI version dictionary Key

Type

Value

version number

dictionary

(Required; PDF 1.2) An OPI dictionary specifying the attributes of this proxy (see "Table 406 — Entries in a version 1.3 OPI dictionary" and "Table 407 — Entries in a version 2.0 OPI dictionary"). The key for this entry shall be the name 1.3 or 2.0, identifying the version of OPI to which the proxy corresponds.

NOTE 2

As in any other PDF dictionary, the key in an OPI version dictionary is a name object. The OPI version dictionary would thus be written in the PDF file in either the form

<</1.3 d 0 R>>

%OPI 1.3 dictionary

<</2.0 d 0 R>>

%OPI 2.0 dictionary

or

where d is the object number of the corresponding OPI dictionary. "Table 406 — Entries in a version 1.3 OPI dictionary" and "Table 407 — Entries in a version 2.0 OPI dictionary") describe the contents of the OPI dictionaries for OPI 1.3 and OPI 2.0, respectively, along with the corresponding PostScript language OPI comments. The dictionary entries shall be listed in the order in which the corresponding OPI comments appear in a PostScript program. OPI: Open Prepress Interface Specification 1.3 and Adobe Technical Note #5660, Open Prepress Interface (OPI) Specification, Version 2.0 shall define the complete details on the meanings of these entries and their effects on OPI servers.

829

ISO 32000-2:2020(E)

Table 406 — Entries in a version 1.3 OPI dictionary Key

Type

OPI Comment

Value

Type

name

(Optional) The type of PDF object that this dictionary describes; if present, shall be OPI for an OPI dictionary.

Version

number

(Required) The version of OPI to which this dictionary refers; shall be the number 1.3 (not the name 1.3, as in an OPI version dictionary).

F

file %ALDImageFilename specification

(Required) The external file containing the image corresponding to this proxy.

ID

byte string

%ALDImageID

(Optional) An identifying string denoting the image.

Comments

text string

%ALDObjectComments

(Optional) A human-readable comment, typically containing instructions or suggestions to the operator of the OPI server on how to handle the image.

Size

array

%ALDImageDimensions

(Required) An array of two integers of the form [pixelsWide pixelsHigh]

specifying the dimensions of the image in pixels. CropRect

rectangle

%ALDImageCropRect

(Required) An array of four integers of the form [left top right bottom]

specifying the portion of the image that shall be used. CropFixed

830

array

%ALDImageCropFixed

(Optional) An array with the same form and meaning as CropRect, but expressed in real numbers instead of integers. Default value: the value of CropRect.

ISO 32000-2:2020(E)

Key

Type

OPI Comment

Value

Position

array

%ALDImagePosition

(Required) An array of eight numbers of the form [llx lly ulx uly urx ury lrx lry]

specifying the location on the page of the cropped image, where (llx, lly ) are the user space coordinates of the lower-left corner, (ulx, uly ) are those of the upper-left corner, (urx, ury ) are those of the upper-right corner, and (lrx, lry ) are those of the lower-right corner. The specified coordinates shall define a parallelogram; that is, they shall satisfy the conditions 𝑢𝑙𝑥 − 𝑙𝑙𝑥 = 𝑢𝑟𝑥 − 𝑙𝑟𝑥 and 𝑢𝑙𝑦 − 𝑙𝑙𝑦 = 𝑢𝑟𝑦 − 𝑙𝑟𝑦 The combination of Position and CropRect determines the image’s scaling, rotation, reflection, and skew. Resolution

array

%ALDImageResolution

(Optional) An array of two numbers of the form [horizRes vertRes]

specifying the resolution of the image in samples per inch. ColorType

name

%ALDImageColorType

(Optional) The type of colour specified by the Color entry. Valid values are Process, Spot, and Separation. Default value: Spot.

Color

array

%ALDImageColor

(Optional) An array of four numbers and a byte string of the form [C M Y K colorName]

specifying the value and name of the colour in which the image is to be rendered. The values of C, M, Y, and K shall all be in the range 0.0 to 1.0. Default value: [0.0 0.0 0.0 1.0 ( Black )]. Tint

number

%ALDImageTint

(Optional) A number in the range 0.0 to 1.0 specifying the concentration of the colour specified by Color in which the image is to be rendered. Default value: 1.0.

Overprint

boolean

%ALDImageOverprint

(Optional) A flag specifying whether the image is to overprint (true) or knock out (false) underlying marks on other separations. Default value: false.

831

ISO 32000-2:2020(E)

Key

Type

OPI Comment

Value

ImageType

array

%ALDImageType

(Optional) An array of two integers of the form [samples bits]

specifying the number of samples per pixel and bits per sample in the image. GrayMap

array

%ALDImageGrayMap

(Optional) An array of 2n integers in the range 0 to 65,535 (where n is the number of bits per sample) recording changes made to the brightness or contrast of the image.

Transparency boolean

%ALDImageTransparency

(Optional) A flag specifying whether white pixels in the image shall be treated as transparent. Default value: true.

Tags

array

%%TIFFASCIITag

(Optional) An array of pairs of the form [tagNum1 tagText1…tagNumn tagTextn]

where each tagNum is an integer representing a TIFF tag number and each tagText is an ASCII string or an array of ASCII strings representing the corresponding ASCII tag value. Size

array

%%ImageDimensions

(Optional) An array of two numbers of the form [width height]

specifying the dimensions of the image in pixels. CropRect

rectangle

%%ImageCropRect

(Optional) An array of four numbers of the form [left top right bottom]

specifying the portion of the image that shall be used. The Size and CropRect entries shall either both be present or both be absent. If present, they shall satisfy the conditions 0 ≤ left <right ≤ width

and 0 ≤ top <bottom ≤ height

In this coordinate space, the positive y axis extends vertically downward; hence, the requirement that top < bottom. Overprint

boolean

%%ImageOverprint

(Optional) A flag specifying whether the image is to overprint (true) or knock out (false) underlying marks on other separations. Default value: false.

833

ISO 32000-2:2020(E)

Key

Type

OPI Comment

Value

Inks

name or array

%%ImageInks

(Optional) A name object or array specifying the colourants to be applied to the image. The value may be the name full_color or registration or an array of the form [/monochrome name1 tint1…namen tintn]

where each name is a string representing the name of a colourant and each tint is a real number in the range 0.0 to 1.0 specifying the concentration of that colourant to be applied. IncludedImageDimensions array

%%IncludedImageDim (Optional) An array of two integers of the ensions form [pixelsWide pixelsHigh]

specifying the dimensions of the included image in pixels. IncludedImageQuality

number

14.12

Document parts

14.12.1

General

%%IncludedImageQua (Optional) A number indicating the quality of the included image. Valid values are 1, 2, lity and 3.

Many PDF documents are often comprised of multiple sub-documents, or document parts, where each document part may have a varying number of pages. Examples include subdocuments for different recipients in transactional or variable data printing, document parts which have different requirements when processed (such as the cover sheet and pages of a booklet), or simply a collation of multiple documents. When a PDF file is produced, a PDF application will need to define a specific ordering of all pages from all document parts, but any such ordering may not meet all future usage requirements. Such PDF files are usually optimised to a particular workflow or to specific capabilities of a target printing device setup and thus are not portable across different production workflows or digital printing devices once they are created. As a structured page description format, PDF encodes the many pages of documents in a manner that allows a PDF processor efficient random access to pages. The random access efficiency of PDF provides an ideal page content resource format for job ticket-based workflow where the order of page processing may be different from the order presented in the PDF data. This re-ordering may be specified in a separate data file such as a JDF job ticket or be viewed using a PDF processor. The use of a separate job ticket file for specifying page ordering and processing requirements allows for an exchanged PDF 2.0 document to be more easily late stage targeted or re-targeted to a production workflow, digital printing device, or other messaging channel. Re-targeting or reprinting is then possible without the need to recreate or modify the PDF 2.0 document. Such workflows may need to 834 © ISO 2020 – All rights reserved

ISO 32000-2:2020(E)

identify specific page ranges in a PDF file in order to associate them with specific parts of the job ticket. Document parts provide the metadata required to make that identification. NOTE

14.12.2

The document part tree structure specified in this clause is based on, and compatible with, the structure specified in ISO 16612-2. Changes are to make it less prescriptive.

DPart tree structure

The pages of a sequence of independent document parts are defined in a PDF file using a hierarchy of DPart dictionaries referred to as document part dictionaries. The root node of this hierarchy of dictionaries is identified by the DPartRoot dictionary referenced from the catalog dictionary. The document part hierarchy is a data structure that defines the sequence of pages in the PDF file, including any documents and/or document parts of which it is composed. DPart dictionaries that are leaf nodes of this hierarchy may refer to a specific range of one or more PDF page objects as identified by their Start and End keys. The ranges of PDF page objects referenced from the various DPart dictionary leaf nodes shall not overlap and therefore shall not share the same PDF page objects. Each page object defined in the PDF file shall be included in the page range defined by one and only one DPart dictionary. The various DPart dictionary nodes of the hierarchy are fully connected by explicit references to the immediate descendant DPart nodes and to the parent node. NOTE 1

Although ISO 32000 also defines structured access to page objects via the pages tree, a PDF processor can also access page object entries indirectly from the DPart leaf nodes of the document part hierarchy for structured presentation of pages.

The value of the optional DPartRoot key in the catalog dictionary shall be an indirect object reference to a DPartRootNode dictionary. A child DPart dictionary shall not be referenced by more than one parent DPart dictionary. NOTE 2

14.12.3

A DPart dictionary is not permitted to have more than one parent and can have any number of children because DPart dictionaries are part of a tree structure.

Connecting the DPart tree structure to pages

A page object shall only be referenced in the range of pages specified by the Start and End keys of a single DPart dictionary entry. Each page object that is contained within the page range specified by the Start and End keys of a single DPart entry shall have a DPart key that has a value that is an indirect reference to the leaf node DPart dictionary whose range of pages includes this page object. NOTE 1

The DPart key in a page object allows a PDF processor to directly retrieve the section of the document part hierarchy that applies to this page object. For example, for certain implementation approaches to cut and stack imposition, this allows for efficient retrieval of DPM based on page indices. This also allows for ready access of DPM data in PDF processors.

If more than one page object is included in the range of pages referenced by the Start and End keys of a DPart dictionary entry, the page number of each page object referenced within that range shall be monotonically increasing, as defined by the document’s page tree, beginning with the page object referenced by the Start key. The order of page objects as defined by the page tree shall be in the same © ISO 2020 – All rights reserved

835

ISO 32000-2:2020(E)

order in which page objects are referenced from leaf node DPart dictionaries in a depth-first traversal of the document part hierarchy. NOTE 2

By ordering the PDF pages as referenced from the DPart tree structure to be respective of the order they are referenced from the normal page tree, the pages will be enumerated the same using either mechanism.

14.12.4

Data structures

14.12.4.1

General

"Table 408 — Entries in a DPartRoot dictionary" defines entries in a DPartRoot dictionary. Table 408 — Entries in a DPartRoot dictionary Key

Type

Value

Type

name

(Optional; PDF 2.0) If present, it shall have the value DPartRoot to identify the dictionary as a DPartRoot dictionary.

DPartRootNode dictionary (Required; PDF 2.0) Shall be an indirect reference to the DPart dictionary that is the root node of the document part tree structure. RecordLevel

integer

(Optional; PDF 2.0) This attribute may be used when a single PDF file encodes multiple documents. It identifies the zero based level of the document part hierarchy where each DPart node of that level corresponds to a component or hierarchy of components.

NodeNameList

array

(Optional; PDF 2.0) An array of names where each name entry shall correspond to a DPart node level of the document part hierarchy beginning with the DPart dictionary identified by the value of the DPartRoot dictionary's DPartRootNode key. If present, the number of entries present in this array shall be equal to the number of DPart node levels in the document part hierarchy. Each name in this array shall conform to the rules for an XML Name token.

"Table 409 — Entries in a DPart dictionary" defines entries in a DPart dictionary. Table 409 — Entries in a DPart dictionary Key

Type

Value

Type

name

(Optional; PDF 2.0) If present, it shall have the value DPart to identify the dictionary as a DPart dictionary.

Parent

dictionary

(Required; PDF 2.0) If this DPart dictionary is referenced from the DPartRootNode key of the DPartRoot dictionary, then the value of this Parent key shall be an indirect reference to the DPartRoot dictionary. In all other cases the value of this Parent key shall be an indirect reference to the DPart dictionary that is its immediate ancestor in the hierarchy.

DParts

array

(Shall not be present if a Start key is present; PDF 2.0) An array of arrays. Each element in the array is an array of indirect references to immediate descendant DPart dictionaries. The array shall not be empty.

836

ISO 32000-2:2020(E)

Key

Type

Value

Start

dictionary

(Shall not be present if a DParts key is present; shall be an indirect reference; PDF 2.0) If present, the Start key shall be an indirect reference to the page object that defines the first page of the range of pages belonging to this DPart dictionary.

End

dictionary

(Required if there is a Start key and the page range has more than one page, not present otherwise; shall be an indirect reference; PDF 2.0) If present, the End key shall be an indirect reference to the page object that defines the last PDF page of the range of pages belonging to this DPart dictionary.

DPM

dictionary

(Optional; PDF 2.0) If present shall specify a document part metadata dictionary. NOTE

AF

array of (Optional; PDF 2.0) An array of one or more file specification dictionaries (7.11.3, dictionaries "File specification dictionaries") which denote the associated files for this document part (DPart). See 14.13, "Associated files" and 14.13.8, "Associated files linked to DParts".

Metadata stream

NOTE

See 14.12.4.2, "Document part metadata" for a description of the use of DPM dictionaries for specifying DPM.

(Optional; PDF 2.0; shall be an indirect reference) A metadata stream that shall contain metadata for this document part (see 14.3.2, "Metadata streams").

The use of the DParts key, to refer to a descendant DPart dictionary, and the use of the Start and End keys, to refer to a range of pages, are exclusive. The restrictions on the use of the Start and End keys only permit DPart dictionary leaf nodes to refer to a range of one or more PDF pages. Non-leaf DPart dictionary nodes of the hierarchy cannot refer to a range of PDF pages, only to descendent DPart dictionaries.

14.12.4.2

Document part metadata

Document Part Metadata (DPM) is a means by which PDF writers, such as PDF authoring applications, communicate information about the various document parts to a downstream production workflow. NOTE 1

Job ticket formats such as JDF have specific constructs designed for use with structured page description language formats that contain metadata in their document part structure. In support of that, PDF provides document part metadata (DPM) that can occur as a DPM dictionary entry in any DPart dictionary of the document part hierarchy.

DPM is application-specific information communicated between the creator of PDF data and a receiving system, and may be used to classify the PDF file and its various document parts. The receiving system may, for example, use this information in the purposing of page content to print or to some other messaging channel. The DPM may also be referenced in a job definition, such as a JDF job ticket, to vary processing control as necessary for print production. The DPM specified within a DPM dictionary shall only apply to the DPart node in which it is defined. The name of all keys present in the DPM dictionary or any other dictionaries contained within a DPM dictionary shall conform to the rules of an XML name token as well as the rules for PDF name objects. NOTE 2

This ensures that the representative XML name for the PDF key is a sequence of XML characters where all PDF name # escape sequences present in the PDF key name are expanded. For more information on # escape sequences refer to 7.3.5, "Name objects".

837

ISO 32000-2:2020(E)

The values of keys present in the DPM dictionary, or of any dictionary or array object present in the DPM dictionary, shall only be of type text string, date string, array, dictionary, boolean, integer or real as defined in 7.3, "Objects". Other PDF value types shall not be used.

14.13

Associated files

14.13.1

General

Associated files provide a means to associate content in other formats with objects of a PDF file and to identify the relationship between them. Such associated files are designated using file specification dictionaries (see 7.11.3, "File specification dictionaries"), and AF keys are used in object dictionaries to connect the associated file’s specification dictionaries with those objects. Some PDF objects that can provide the AF keys are: •

the PDF document catalog dictionary (14.13.3, "Associated files linked to the PDF document’s catalog")

•

a page dictionary (14.13.4, "Associated files linked to a page dictionary")

•

a graphics object (using a marked-content property list dictionary, 14.13.5, "Associated files linked to graphics objects")

•

a structure element dictionary (14.13.6, "Associated files linked to structure elements")

•

an XObject dictionary (14.13.7, "Associated files linked to XObjects")

•

a DParts dictionary (14.13.8, "Associated files linked to DParts")

•

an annotation dictionary (14.13.9, "Associated files linked to an annotation dictionary")

•

a metadata stream dictionary (14.3.2, "Metadata streams")

For associated files, their associated file specification dictionaries should include the AFRelationship key indicating one of several possible relationships that the file has to the associated PDF object (See 7.11.3, "File specification dictionaries"). NOTE

14.13.2

This document clarified the above paragraph (2020).

Embedded associated files

The file specification for an associated file represents either a file external to the PDF file or an embedded file stream (see 7.11.4, "Embedded file streams") within the PDF file. NOTE 1

A file specification dictionary allows for both embedded data (via the EF key) and referenced/external data (via the F and UF keys). Both types are allowed for associated files but the embedded form is recommended.

When using an embedded file stream as an associated file, its dictionary should contain a Params key whose value shall be a dictionary containing at least a ModDate key whose value shall be the latest modification date of the source file. (See "Table 44 — Additional entries in an embedded file stream dictionary" and "Table 45 — Entries in an embedded file parameter dictionary"). The embedded file stream dictionary shall include a valid MIME type value for the Subtype key. If the MIME type is not known, the value "application/octet-stream" shall be used. NOTE 2

838

ISO 32000-2:2020(E)

In addition, an embedded file stream may be referenced from the document’s EmbeddedFiles names tree (see the EmbeddedFiles key in 7.7.4, "Name dictionary"). NOTE 3 EXAMPLE

14.13.3

Doing so will enable a user to extract the file directly as any other attachment to the document and also allow it to be considered when doing an "attachments only" encryption. A PDF document is to be created from a text processing application file that contains textual content, a mathematical equation, and a chart derived from a spreadsheet application. In this case the resulting PDF document might contain the following embedded files: ▪

Text processing application file embedded with an AFRelationship value Source and associated with the document catalog

▪

MathML version of the equation embedded with an AFRelationship value Supplement, and associated using a structure element or a form XObject depending on how the equation is rendered in the page’s content stream.

▪

Spreadsheet application file embedded with a AFRelationship value Source and associated with the Image or form XObject presenting the chart.

▪

CSV file embedded with a AFRelationship value Data and associated with the Image or form XObject for presenting the chart.

Associated files linked to the PDF document’s catalog

One or more files may be associated with the PDF document as a whole by including a file specification dictionary (7.11.3, "File specification dictionaries") for each file as one of the members of the array value of the AF key in the document catalog (7.7.2, "Document catalog dictionary"). The relationship that the associated files have to the PDF document is supplied by the AFRelationship key in each file specification dictionary.

14.13.4

Associated files linked to a page dictionary

One or more files may be associated with any PDF page by including a file specification dictionary (7.11.3, "File specification dictionaries") for each file as one of the members of the array value of the AF key in the appropriate page dictionary (7.7.3.3, "Page objects"). The relationship that the associated files have to the page is supplied by the AFRelationship key in each file specification dictionary. NOTE

14.13.5

Associated files serve not only as alternative to PieceInfo (which is vendor specific) but also enable richer semantic content when doing page/document merging or conversion of simple page-based elements (e.g., images).

Associated files linked to graphics objects

One or more files may be associated with sections of content in a content stream by enclosing those sections between the marked-content operators BDC and EMC (see 14.6, "Marked content") with a marked-content tag of AF. NOTE 1

This applies to a page’s content stream, a form or pattern’s content stream, glyph descriptions in a Type 3 font as specified by its CharProcs entry, or an annotation’s appearance (AP).

NOTE 2

The BMC operator does not take properties and therefore cannot be used with the AF key.

Unlike other types of marked-content tags, the DP or MP marked-content operators shall not be used with the AF tag when that tag is used to refer to a file specification dictionary.

839

ISO 32000-2:2020(E)

NOTE 3

The combination of a DP or MP operator with an AF tag (when used to refer to a file specification dictionary) is forbidden, as these operators only mark a single point and thus don’t enable connections between any specific sequence of content operators and their associated file.

The property list associated with the marked-content shall specify an array of file specification dictionaries to which the content is associated. The named resource in the Property List (see 14.6.2, "Property lists") shall specify an array of file specification dictionaries to which the content is associated. The relationship that the associated files have to the PDF content is supplied by the AFRelationship key in each file specification dictionary. Although the marked-content tag shall be AF, other applications of marked-content are not precluded from using AF as a tag. The marked-content is connected with associated files only if the tag is AF and the property list is defined as a valid array of file specification dictionaries. To avoid conflict with other features that use marked-content, such as 14.7, "Logical structure", where content is to be tagged with source content markers as well as other markers, the other markers should be nested inside the source content markers. When writing a PDF, the use of structure and associating the AF with the structure element (see 14.13.6, "Associated files linked to structure elements") is preferred instead of the use of explicit marked-content.

14.13.6

Associated files linked to structure elements

One or more files may be associated with structure elements (see 14.7.2, "Structure hierarchy") to accommodate content that spans pages such as in an article, section or table, in which cases logical structural elements should be used to make an association with files. This entry represents the associated files for the entire structure element. To associate files with structure elements, the structure element dictionary shall contain an AF entry which represents the associated files for that structure element. The relationship that the associated files have to the structure element is supplied by the AFRelationship key in each file specification dictionary.

14.13.7

Associated files linked to XObjects

One or more files may be associated with Type 1 form XObjects and image XObjects (see 8.8, "External objects"). To associate files with XObjects, the XObject stream dictionary shall contain an AF entry whose value is an array of file specification dictionaries. This entry represents the associated files for the entire XObject. The relationship that the associated files have to the XObject is supplied by the AFRelationship key in each file specification dictionary.

14.13.8

Associated files linked to DParts

One or more files may be associated with any DPart (see 14.12, "Document parts"). To associate files with a DPart, the appropriate DPart dictionary shall contain an AF entry whose value is an array of file specification dictionaries. This entry represents the associated files for the entire DPart. The relationship that the associated files have to the DPart is supplied by the AFRelationship key in each file specification dictionary. NOTE

840

ISO 32000-2:2020(E)

14.13.9

Associated files linked to an annotation dictionary

One or more files may be associated with annotations. NOTE

For some annotation types (such as 13.7.2, "RichMedia annotations") it is useful to have the data used for dynamic rendering be easily identifiable by a reader.

To associate files with annotations, the annotation dictionary shall contain an AF entry which represents the associated files for that annotation. The relationship that the associated files have to the annotation is supplied by the AFRelationship key in each file specification dictionary.

14.13.10

Associated file examples

EXAMPLE 1

Associated file linked to the PDF document as a whole

19 0 obj << /Type /Catalog /Pages 6 0 R /Names 30 0 R /Metadata 11 0 R /AF [20 0 R]

%Document Catalog

20 0 obj <<

%File Specification Dictionary /Type /Filespec /F (My Presentation.ppt) /UF (My Presentation.ppt) /AFRelationship /Source /EF <</F 21 0 R>>

endobj 21 0 obj <<

%embedded file stream /Filter /FlateDecode /Length 1975 /Type /EmbeddedFile /Subtype /application#2Fvnd.ms-powerpoint /Params << /CheckSum /Size 3979 /CreationDate (D:20010727133719) /ModDate (D:20010727133720)

stream … endstream endobj

EXAMPLE 2

Associated file linked to a Content Stream

10 0 obj << /Type /Page /Resources << % This dictionary maps the name AF1 to an /Properties <</NamedAF [12 0 R]>> % embedded file specification (object 12) …

% End of Resources dictionary

841

ISO 32000-2:2020(E)

/Contents 11 0 R …

endobj

% End of Page dictionary

11 0 obj << /Length 165 >> stream … /AF /NamedAF BDC BT /F1 1 Tf 12 0 0 12 100 600 Tm (Hello) Tj ET EMC … endstream endobj

% Content stream object

12 0 obj << /Type /Filespec /F (datatable.doc) /UF (datatable.doc) /AFRelationship /Data /EF <</F 5 0 R>>

endobj

% File specification dictionary

% Within a content stream % Begin content marked with an associated file

% End of associated content

5 0 obj % Embedded file stream << /Filter /FlateDecode /Length 20000 /Type /EmbeddedFile /Subtype /application#2Fvnd.ms-word /Params << /CheckSum /Size 32000 /CreationDate (D:200504 16133719) /ModDate (D:20050908133720)

stream … endstream endobj

EXAMPLE 3

842

Associated file linked to an XObject

19 0 obj << /Type /XObject /Subtype /Form … /AF [20 0 R]

%some XObject

20 0 obj << /Type /Filespec /F (equation.mathml) /UF (equation.mathml) /AFRelationship /Supplement /EF <</F 21 0 R>>

%File Specification Dictionary

ISO 32000-2:2020(E)

endobj 21 0 obj %embedded file stream << /Filter /FlateDecode /Length 1975 /Type /EmbeddedFile /Subtype /application#2Fxhtml+xml /Params << /CheckSum /Size 3979 /CreationDate (D:20010727133719) /ModDate (D:20010727133720)

stream … endstream endobj

843

ISO 32000-2:2020(E)

Navigation: PDF20-Spec-14-Tagged-PDF | PDF20-Spec-Index | Next →

PDF20 Spec 14 Accessibility

14.9 Accessibility Support

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!