Interactive features
12. Interactive features
12.2 Viewer preferences
Change Table 147 as follows:
| Key | Type | Value |
|---|---|---|
| NonFullScreenPageMode | name |
(Optional) The document’s page mode, specifying how to display the document on exiting full-screen mode:
This entry is meaningful only if the value of the PageMode entry in the catalog dictionary (see 7.7.2, "Document catalog dictionary") is FullScreen; it shall be ignored otherwise. Default value: UseNone. |
| ViewArea | name |
(Optional; PDF 1.4; deprecated in PDF 2.0) The name of the page boundary representing the area of a page that shall be
displayed when viewing the document on the screen. The value is the key designating the relevant page boundary in the page object
(see Default value: ... |
| ViewClip | name |
(Optional; PDF 1.4; deprecated in PDF 2.0) The name of the page boundary representing the area of a page that shall be
displayed to which the contents of a page shall be clipped when viewing the document on the screen. The value is the key designating
the relevant page boundary in the page object
(see Default value: ... |
| PrintArea | name |
(Optional; PDF 1.4; deprecated in PDF 2.0) The name of the page boundary representing the area of a page that shall be
rendered when printing the document. The value is the key designating the relevant page boundary in the page object
(see Default value: ... |
| PrintClip | name |
(Optional; PDF 1.4; deprecated in PDF 2.0) The name of the page boundary to which the contents of the page shall be clipped
when printing the document. The value is the key designating the relevant page boundary in the page object
(see Default value: ... |
12.3 Document-level navigation
12.3.2 Destinations
12.3.2.4 Named destinations
Change paragraph below NOTE 1 as follows:
In PDF 1.1, the correspondence between name objects and destinations shall be defined by the Dests entry in the document
catalog dictionary (see 7.7.2, "Document catalog dictionary"). The value of this entry shall be a dictionary in which each key
is a destination name and the corresponding value is eitheran array defining the destination, using the syntax shown in
"Table 149 — Destination syntax", or a dictionary with a D entry whose value is such an array and may optionally contain
an SD entry as defined in "Table 201 — Action types".:
- an array defining the destination, using the syntax shown in "Table 149 — Destination syntax", or
- a dictionary with a D entry whose value is such an array. In PDF 2.0, this dictionary may also optionally contain an SD entry. See "Table 202 — Additional entries specific to a go-to action", "Table 203 - Additional entries specific to a remote go-to action" and "Table 204 - Additional entries specific to an embedded go-to action".
12.3.3 Document outline
Change Table 151 as follows:
| Key | Type | Value |
|---|---|---|
| Prev | dictionary |
(Required for all but the first item at each level; shall not be present on the first item at each level; shall be an indirect reference) The previous item at this outline level. |
| Next | dictionary |
(Required for all but the last item at each level; shall not be present on the last item at each level; shall be an indirect reference) The next item at this outline level. |
...
12.3.5 Collections
12.3.5.3 Collection navigators
EDITOR NOTE: (Issue #477) all of subclause 12.3.6 Navigators was moved and demoted one level to subclause 12.3.5.3 Collection navigators.
12.3.6 Navigators
EDITOR NOTE: (Issue #477) move all of subclause 12.3.6 Navigators to subclause 12.3.5.3 Collection navigators.
Change the title of clause 12.4.2 as follows:
12.4.2 Page labels and indices
...
Change Table 161 as follows:
| Key | Type | Value |
|---|---|---|
| S | name |
(Optional) The numbering style that shall be used for the numeric portion of each page label:
There is no default numbering style; if no S entry is present, page labels shall consist solely of a label prefix with no numeric portion. NOTE If the P entry (next) specifies the label prefix Contents, each page is simply labelled Contents with no page number. (If the P entry is also missing or empty, the page label is an empty string.) |
12.4.3 Articles
...
Change the paragraph before Table 162 as follows:
The optional Threads entry in the document catalog dictionary (see 7.7.2, "Document catalog dictionary") holds an array of thread dictionaries ("Table 162 — Entries in a thread dictionary") defining the document’s articles. Each individual bead within a thread shall be represented by a bead dictionary ("Table 163 — Entries in a bead dictionary"). The thread dictionary’s F entry shall refer to the first bead in the thread; the beads shall be chained together sequentially in a doubly linked list through their N (next) and V (previous) entries. In addition, for each page on which article beads appear, the page object (see 7.7.3, "Page tree") shall contain a B entry whose value is an array of indirect references to the beads on the page,
in drawingreading order.
12.4.4 Presentations
12.4.4.1 General
Change Table 164 as follows:
| Key | Type | Value |
|---|---|---|
| M | name |
(Optional; Split, Box and Fly transition styles only) The direction of motion for the specified transition effect: I Inward from the edges of the page ( O Outward from the centre of the page ( Default value: I. |
| Di |
... If the value is ... |
...
12.4.4.2 Sub-page navigation
...
Change the bullets below Table 165 as follows:
An interactive PDF processor shall maintain a current navigation node. When a user navigates to a page, if the page dictionary has a PresSteps entry, the node specified by that entry shall become the current node. (Otherwise, there is no current node.) If the user requests to navigate forward (such as an arrow key press) and there is a current navigation node, the following shall occur:
-
The sequence of actions specified by NA (if present) shall be executed.
If NA specifies an action that navigates to another page, the following actions for navigating to another page take place, and Next should not be present.
-
The node specified by Next (if present) shall become the new current navigation node.
If there is no node specified by Next then navigate to the next page. If the current page is the last page, then the current navigation node remains unchanged.
Similarly, if the user requests to navigate backward and there is a current navigation node, the following shall occur:
-
The sequence of actions specified by PA (if present) shall be executed.
If PA specifies an action that navigates to another page, the following actions for navigating to another page take place, and Prev should not be present.
-
The node specified by Prev (if present) shall become the new current navigation node.
If there is no node specified by Prev then navigate to the previous page. If the current page is the first page, then the current navigation node remains unchanged.
Transition effects, similar to the page transitions described earlier, may be specified as transition actions that are part of the NA or PA sequence; see 12.6.4.15, "Transition actions".
If the user requests to navigate to another page (regardless of whether there is a current node) and that page’s dictionary contains a PresSteps entry, the following shall occur:
-
The navigation node represented by PresSteps shall become the current node.
-
If the navigation request was forward, or if the navigation request was for random access (such as by clicking on a link), the actions specified by NA shall be executed and the node specified by Next shall become the new current node, as described previously.
If the navigation request was backward, the actions specified by PA shall be executed and the node specified by Prev shall become the new current node, as described previously.
-
The interactive PDF processor shall make the new page the current page and shall display it. Any page transitions specified by the Trans entry of the page dictionary shall be performed.
12.5 Annotations
12.5.1 General
Change the last paragraph as follows:
These descriptions assume the page is being viewed in the orientation specified by the Rotate entry. Conceptually, the behaviour of each annotation type may be
implemented by a software module called an annotation handler. A PDF processor shall provide annotation handlers for all of the conforming annotation types.
The set of annotation types is extensible. An interactive PDF processor shall provide certain expected behaviour for all annotation types that it does not
recognise, as documented in 12.5.2, "Annotation dictionaries"
12.5.5, "Appearance streams" and "Table 167 - Annotation flags" (bit positions 1 and 2)
.
12.5.2 Annotation dictionaries
Change Table 166 as follows:
| Key | Type | Value |
|---|---|---|
| AP | dictionary |
( Every annotation (including those whose Subtype value is Widget, as used for form fields), except for the two cases listed below, shall have at least one appearance dictionary.
NOTE (2020) The bullet point above was changed from "or" to "and" in this document to match requirements in other published ISO PDF standards (such as PDF/A). Array indices were also corrected to be zero-based as described in 3.2 "array object".
|
| Border | array |
... If an annotation dictionary includes the BS entry, then the Border entry shall be ignored.
NOTE (PDF 1.2) The dictionaries for some annotation types (such as free text and polygon annotations) can include the BS entry. That entry specifies a border style dictionary that has more
settings than the array specified for the Border entry. |
Change the paragraph and NOTEs below Table 166 as follows:
A PDF reader shall render the appearance dictionary without regard to any other keys and values in the annotation dictionary and
When rendering the appearance dictionary, a PDF reader
shall ignore the values of the C, IC, Border, BS, BE,
BM,
CA, ca, H, DA, Q, DS, LE, LL, LLE,
MK,
and Sy keys.
NOTE 1 Some of these keys are only relevant to certain annotation subtypes as described in the following subclauses.
NOTE 2 Requiring an appearance dictionary for each annotation ensures the reliable rendering of the annotations. When an appearance dictionary is not present, the rendered appearance will be implementation dependent.
12.5.5 Appearance streams
...
Change the paragraph below the EXAMPLE as follows:
where fformXObject1 and fformXObject2 define the check box’s normal appearance in its checked and unchecked states, and formXObject3 and formXObject4 provide visual feedback, such as emboldening its outline, when the user clicks it. (No R entry is defined because no special appearance is needed when the user moves the cursor over the check box without pressing the mouse button.) The choice between the checked and unchecked appearance states is determined by the AS entry in the annotation dictionary (see "Table 166 — Entries common to all annotation dictionaries").
...
12.5.6 Annotation types
12.5.6.2 Markup annotations
Change the paragraph below NOTE 1 as follows:
When providing the Contents key, if separating text into paragraphs, a CARRIAGE RETURN (0Dh) shall be used and not, for example, a LINE FEED character (0Ah).
...
Change the paragraph below Table 172 as follows:
In PDF 1.6PDF 1.5, a set
of annotations may be grouped so that they function as a single unit when a user interacts with them.
The group consists of a primary annotation, which shall not have an IRT entry, and one or more subordinate annotations, which shall have
an IRT entry that refers to the primary annotation and an RT (PDF 1.6) entry whose value is Group.
12.5.6.3 Annotation states
Correct the first paragraph as follows:
Beginning with PDF 1.5, annotations may have an author-specific state associated with them. The state is not specified in the annotation itself but in a separate text annotation that refers to the original annotation by means of its IRT ("in reply to") entry (see "Table 176 — Additional entries specific to a link annotation""Table 172 - Additional entries in an annotation dictionary specific to markup annotations"). States shall be grouped into a number of state models, as shown in "Table 174 — Annotation states".
...
Correct the second bullet as follows:
State changes made by a user shall be indicated in a text annotation with the following entries:
- ...
- The IRT entry (see
"Table 176 — Additional entries specific to a link annotation""Table 172 - Additional entries in an annotation dictionary specific to markup annotations") shall refer to the original annotation. - ...
...
12.5.6.5 Link annotations
Change Table 176 as follows:
| Key | Type | Value |
|---|---|---|
| QuadPoints | array |
(Optional; PDF 1.6) An array of 8 × n numbers specifying the coordinates of n quadrilaterals in default user space that comprise
the region in which the link should be activated. The coordinates for each quadrilateral are given in the order: NOTE 1 When QuadPoints is used, the activation area and the visual appearance (including border) of the link annotation are not required to be the same. NOTE 2 The last paragraph above was clarified in this document (2020). |
| BS | dictionary |
(Optional; PDF |
12.5.6.6 Free text annotations
Change Table 177 as follows:
| Key | Type | Value |
|---|---|---|
| DA | byte string |
(Required) The default appearance string that shall be used in formatting the text (see 12.7.4.3, "Variable text"). The annotation dictionary's AP entry |
| RD |
|
... |
| BS | dictionary |
(Optional; PDF |
12.5.6.7 Line annotations
Change Table 179 as follows:
| Name | Appearance | Description |
|---|---|---|
| OpenArrow | ... |
EDITOR NOTE: (Issue #513) The row height in the ISO PDF file obscures the end of the sentence. The text is unchanged but noted here for clarity. Two short lines meeting in an acute angle to form an open arrowhead. |
| RClosedArrow | ... | (PDF 1.5) A triangular closed arrowhead in the reverse direction from ClosedArrow filled with the annotation’s interior colour, if any. |
12.5.6.8 Square and circle annotations
Change Table 180 as follows:
| Key | Type | Value |
|---|---|---|
| RD |
|
... |
12.5.6.9 Polygon and polyline annotations
Change Table 181 as follows:
| Key | Type | Value |
|---|---|---|
| Vertices | array |
(Required |
| Path | array |
(Optional; PDF 2.0) An array of n arrays, each supplying the operands for a path building operator (m, l or c). If this key is present the Vertices key shall
... |
12.5.6.11 Caret annotations
Change Table 183 as follows:
| Key | Type | Value |
|---|---|---|
| RD |
|
... |
12.5.6.13 Ink annotations
Change Table 185 as follows:
| Key | Type | Value |
|---|---|---|
| InkList | array | (Required) Shall be ignored if Path is present. An array of n arrays, each representing a stroked path. Each array shall be a series of alternating horizontal and vertical coordinates in default user space, specifying points along the path. When drawn, the points shall be connected by straight lines or curves in an implementation-dependent way. |
12.5.6.18 Screen annotations
Change the last bullet below Table 190 as follows:
- ...
-
The AP entry refers to an appearance dictionary (see "Table 170 - Entries in an appearance dictionary") whose normal appearance provides the visual
appearance for a screen annotation that shall be used for printing and default display when a media clip is not being played.
If AP is not present, the screen annotation shall not have a default visual appearance and shall not be printed.
12.5.6.24 Projection annotations
Change the first paragraph as follows:
A projection annotation (PDF 2.0) is a markup annotation subtype (see 12.5.6.2, "Markup annotations") that has much of the functionality of other markup annotations. However, a projection annotation is only valid within the context of an associated run-time environment, such as an activated 3D model, and thus an AP dictionary is not required.
...
Delete the last paragraph as follows:
A projection annotation with a Rect entry that has zero height or zero width shall not have an AP dictionary.
12.6 Actions
12.6.4 Action types
12.6.4.2 Go-To actions
Change Table 202 as follows:
| Key | Type | Value |
|---|---|---|
| D | name, byte string, or array |
(Required) The explicit destination or named destination to jump to (see 12.3.2, "Destinations"). |
12.6.4.4 Embedded Go-To actions
Change Table 205 as follows:
| Key | Type | Value |
|---|---|---|
| P | integer or byte string |
... NOTE: Although normally named destinations can also be specified by the use of a name object, that particular usage of them is not provided for in this case. |
12.6.4.8 URI actions
Note the following Editor Note that is inserted below Example 2:
EDITOR NOTE: The remaining text in subclause 12.6.4.16 about Base and the URI dictionary (including Table 211 and NOTE) applies to all relative URIs in a PDF document and is not limited to only URI actions as is currently implied. A future edition of ISO 32000 will move this text into a new subclause and update many other locations throughout ISO 32000 so this is entirely clear. See details described in Errata #256.
12.6.4.16 Go-To-3D-View actions
Change the first paragraph as follows:
A go-to-3D-view action (PDF 1.6) identifies a 3D or RichMedia annotation and specifies a view for the annotation to use (see 13.6, "3D Artwork"). "Table 220 — Additional entries specific to a go-to-3D-view action" shows the entries in a go-to-3D-view action dictionary.
Change Table 220 as follows:
| Key | Type | Value |
|---|---|---|
| S | name |
(Required) The type of action that this dictionary describes; shall be GoTo3DView for a
|
| V | (various) |
(Required) The view to use. It may be one of the following types:
|
...
12.7 Forms
12.7.3 Interactive form dictionary
Change Table 224 as follows:
| Key | Type | Value |
|---|---|---|
| DA | byte string | (Optional) A document-wide default value for the DA attribute of variable text fields (see 12.7.4.3, "Variable text"). |
12.7.4 Field dictionaries
12.7.4.1 General
Change Table 226 as follows:
| Key | Type | Value |
|---|---|---|
| T | text string |
( |
| AA | dictionary |
(Optional; PDF 1.2) An additional-actions dictionary defining the field’s behaviour in response to various trigger events (see 12.6.3, "Trigger events"). This entry has exactly the same meaning as the AA entry in
|
12.7.4.3 Variable text
Change Table 228 as follows:
| Key | Type | Value |
|---|---|---|
| DA | byte string | (Required; inheritable) The default appearance string containing a sequence of valid page-content graphics or text state operators that define such properties as the field’s text size and colour. |
...
Change the first two paragraphs below the EXAMPLE as follows:
The default appearance byte string (DA) contains any graphics state or text state operators needed to establish the graphics state parameters, such as text size and colour, for displaying the field’s variable text. Only operators that are allowed within text objects shall occur in this byte string (see "Figure 9 — Graphics objects"). At a minimum, the byte string shall include a Tf (text font) operator along with its two operands, font and size. The specified font value shall match a resource name in the Font entry of the default resource dictionary (referenced from the DR entry of the interactive form dictionary; see "Table 224 — Entries in the interactive form dictionary"). A zero value for size means that the font shall be auto-sized: its size shall be computed as an implementation dependent function.
The default appearance byte string shall contain at most one Tm (text matrix) operator. If this operator is present, the interactive PDF processor shall replace the horizontal and vertical translation components with positioning values it determines to be appropriate, based on the field value, the quadding (Q) attribute, and any layout rules it employs. If the default appearance byte string contains no Tm operator, the viewer shall insert one in the appearance stream (with appropriate horizontal and vertical translation components) after the default appearance string and before the text-positioning and text-showing operators for the variable text.
Change the last paragraph as follows:
To update an existing appearance stream to reflect a new field value, the interactive PDF processor shall first copy any needed resources from the
document’s DR dictionary (see "Table 224 — Entries in the interactive form dictionary") into the stream’s Resources dictionary.
(If the DR and Resources dictionaries contain resources with the same name, the one already in the Resources dictionary shall be left intact,
not replaced with the corresponding value from the DR dictionary.) The interactive PDF processor shall then replace the existing contents of the
appearance stream from /Tx BMC to the matching EMC with the corresponding new contents as shown in
Example 1 in 12.7.5.2.3, "Check boxes", 12.7.5, "Field types"
Example above
(If the existing appearance stream contains no marked-content with tag Tx, the new contents shall be appended to the end of the original stream.)
12.7.5 Field types
12.7.5.2 Button fields
12.7.5.2.2 Push-fields
Change the first and only paragraph as follows:
A push-button field shall have a field type of Btn and the Pushbutton flag (see "Table 229 — Field flags specific to button fields") set to one.
Because this type of retains no permanent value, it shall not use the V and DV entries in the field dictionary (see "Table 226 — Entries common to all field dictionaries").
12.7.5.2.4 Radio buttons
...
Change the third paragraph as follows:
The Kids entry in the radio button field’s field dictionary (see "Table 226 — Entries common to all field dictionaries") holds an array of widget annotations representing the individual buttons in the set. The parent field’s V entry holds a name object corresponding to the appearance state of whichever child field is currently in the on state; the default value for this entry is Off. The appearance for the off state is optional but, if present, shall be stored in the appearance dictionary under the name Off. The value of the V key shall also be the value of the AS key. If they are not equal, then the value of the AS key shall be used instead of the V key to determine which appearance to use.
12.7.5.3 Text fields
Change the paragraph below Table 231 as follows:
If the field has a value other than null,
The
the
field’s text shall be held in a text string (or, beginning with PDF 1.5, a stream) in the V (value) entry of the field dictionary.
The contents of this text string or stream shall be used to construct an appearance stream for displaying the field, as described under 12.7.4.3,
"Variable text" The text shall be presented in a single style (font, size, colour, and so forth), as specified by the DA (default
appearance) string.
...
Change Table 232 as follows:
| Key | Type | Value |
|---|---|---|
| MaxLen | integer |
(Optional; inheritable) An integer value greater than or equal to zero that is the
|
12.7.5.4 Choice fields
Change Table 234 as follows:
| Key | Type | Value |
|---|---|---|
| I | array |
(Sometimes required, otherwise optional; PDF 1.4) For choice fields
|
12.7.5.5 Signature fields
Change Table 236 as follows:
| Key | Type | Value |
|---|---|---|
| P | number |
(Optional; PDF 2.0) The access permissions granted for this document. Changes to a PDF that are incremental updates which include only the data necessary to add DSS’s 12.8.4.3, "Document Security Store (DSS)" and/or document timestamps 12.8.5, "Document timestamp (DTS) dictionary" to the document shall not be considered as changes to the document as defined in the choices below. ... |
...
Change Table 237 as follows:
| Key | Type | Value |
|---|---|---|
| DigestMethod | array |
(Optional; PDF 1.7) An unordered array of names indicating acceptable digest
algorithms to use while signing.
|
| AddRevInfo | boolean |
NOTE 3 |
...
Change Table 238 as follows:
| Key | Type | Value | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| KeyUsage | array of ASCII strings |
... 1 digitalSignature 4 dataEncipherment 7
... |
...
12.7.6 Form actions
12.7.6.2 Submit-form action
Change Table 239 as follows:
| Key | Type | Value |
|---|---|---|
| Flags | integer |
(Optional |
| CharSet | string |
(Optional |
12.7.6.3 Reset-form action
Change Table 242 as follows:
| Bit position | Name | Meaning |
|---|---|---|
| 1 | Include/Exclude |
If clear, the Fields array (see "Table 241 — Additional entries specific to a reset-form action") specifies which fields to reset. (All descendants of the specified fields in the field hierarchy are reset as well.) If set, the Fields array indicates which fields to exclude from resetting; that is, all fields in the document’s interactive form shall be reset except those listed in the Fields array. (All descendants of the specified fields in the field hierarchy are also exempt from being reset.) |
12.7.8 Forms data format
...
Change the last paragraph as follows:
FDF shall use the MIME media type application/fdf, or the deprecated alias application/vnd.fdf.
On the Microsoft Windows™ and UNIX platforms, FDF files shall have the extension .fdf; on Mac OS, they shall have file type 'FDF'.
Add the following NOTE after the last paragraph:
NOTE See https://www.iana.org/assignments/media-types/application/fdf for more information.
12.7.8.3 FDF catalog
12.7.8.3.1 General
Change the paragraph below Table 246 as follows:
Although deprecated in PDF 2.0
Although FDF file encryption is deprecated in PDF 2.0,
embedded FDF files specified in the FDF dictionary’s EmbeddedFDFs entry may be encrypted.
Besides the usual entries for an embedded file stream, the stream dictionary representing such an encrypted FDF file shall contain the
additional entry shown in "Table 247 — Additional entry in an embedded file stream dictionary for an encrypted FDF file" to identify
the revision number of the FDF encryption algorithm used to encrypt the file. Although the FDF encryption mechanism is separate from
the one for PDF file encryption described in 7.6, "Encryption",
revision 1 (the only one defined) uses a similar RC4 encryption
algorithm based on a 40-bit encryption key. The key shall be computed by means of an MD5 hash, using a padded user-supplied password
as input. The computation shall be identical to steps (a) and (b) of the
"Algorithm 2: Computing a file encryption key in order to encrypt a document (revision 4 and earlier)" in 7.6.4.3,
"File encryption key algorithm"; the first 5 bytes of the result shall be the file encryption key for the embedded FDF file.
12.7.9 Non-interactive forms
Change the first paragraph as follows:
Unlike interactive forms, non-interactive forms do not use widget annotations but are represented with page content. Non-interactive forms are defined by the
PrintField attrib0ute (14.8.5.6, "PrintField attributes") for repurposing and accessibility purposes.
12.8.1 General
...
12.8.1 General
...
Add a new informative NOTE 2 after the bullet in the bulleted list below NOTE 1 as follows (NOTES to be renumbered):
A byte range digest shall be computed over a range of bytes in the PDF file, that shall be indicated by the ByteRange entry in the signature dictionary. This range should be the entire PDF file, including the signature dictionary but excluding the signature value itself (the Contents entry). In case of multiple digital signatures this range shall be the sequence of bytes starting from the
"%PDF-"comment at the beginning of the PDF document to the end of the"%%EOF"comment, possibly followed by an optional EOL marker, terminating the incremental update that adds the digital signature dictionary to the document. When a byte range digest is present, all values in the signature dictionary shall be direct objects.NOTE 2: due to the above requirement for direct objects, Metadata streams (see 14.3.2, "Metadata streams") and Associated Files (see 14.13, "Associated Files") cannot be included when a byte range digest is present.
- ...
...
Change the list item below NOTE 2 as follows:
A PDF document may contain the following standard types of signatures:
...
- Any number of document timestamp signatures, see 12.8.5, "Document timestamp (DTS) dictionary". The timestamp signature dictionary of a document timestamp signature shall be the value of a signature field and shall contain a ByteRange entry. These shall follow the certification signature if one is present.
A signature dictionary is used by all of these types of signatures.
Change Table 255 as follows:
| Key | Type | Value |
|---|---|---|
| Filter | name |
(Required |
| SubFilter | name |
...
... |
| Cert | byte string or array |
... NOTE adbe.x509.rsa_sha1 and adbe.pkcs7.sha1 are deprecated in PDF 2.0. |
...
Change Table 256 as follows:
| Key | Type | Value |
|---|---|---|
| DigestMethod | name |
( |
12.8.2 Transform methods
12.8.2.2 DocMDP
12.8.2.2.2 Validating signatures that use the DocMDP transform method
Change Table 257 as follows:
| Key | Type | Value |
|---|---|---|
| P |
... |
12.8.2.4 FieldMDP
Change Table 259 as follows:
| Key | Type | Value |
|---|---|---|
| Fields | array | (Required if Action is Include or Exclude) An array of text strings containing fully qualified field names (see 12.7.4.2 "Field names"). |
12.8.3 Signature interoperability
12.8.3.1 General
Change Table 260 as follows:
| SubFilter values | adbe.pkcs7.detached, ETSI.CAdES.detached or ETSI.RFC3161 |
adbe.pkcs7.sha1 c | adbe.x509.rsa_sha1 a c |
|---|---|---|---|
| ... | ... | ... | ... |
|
... c The values adbe.x509.rsa_sha1 and adbe.pkcs7.sha1 have been deprecated with PDF 2.0. ... |
|||
EDITOR NOTE: Table 260 italic formatting of PDF versions (such as "(PDF 1.5)") is inconsistently applied and needs to be corrected.
12.8.4 Long term validation of signatures
12.8.4.1 General
Change the first paragraph as follows:
Long term validation (LTV) of signatures was added in PDF 2.0 and is achieved by using two types of dictionaries:
- document security store (DSS) dictionaries, and
- document timestamp dictionaries (DTS) (see 12.8.5, "Document timestamp (DTS) dictionary").
12.8.4.3 Document Security Store (DSS)
EDITOR NOTE: as a result of Errata #448, all keys in Table 261 need to be indicated that they were introduced in PDF 2.0.
12.8.4.4 Validation-related information (VRI)
EDITOR NOTE: as a result of Errata #448, all keys in Table 262 need to be indicated that they were introduced in PDF 2.0.
12.8.5 Document timestamp (DTS) dictionary
12.8.5.1 General
Change the first paragraph as follows:
A document timestamp dictionary was added in PDF 2.0 and establishes the exact contents of the complete PDF file at the time indicated in the timestamp token.
12.8.6 Permissions
Change Table 263 as follows:
| Key | Type | Value |
|---|---|---|
| DocMDP | dictionary |
(Optional) An indirect reference to a signature dictionary (see "Table 255 — Entries in a signature dictionary"). This dictionary shall contain a Reference entry that shall be an array with at least one entry, exactly one of which is a signature reference dictionary (see "Table 255 — Entries in a signature dictionary") that has a DocMDP transform method (see 12.8.2.2, "DocMDP") and corresponding transform parameters. ... |
12.10 Geospatial features
12.10.2 Geospatial measure dictionary
Change Table 269 as follows:
| Key | Type | Value |
|---|---|---|
| PCSM | array |
(Optional; PDF 2.0) A 12-element transformation matrix of
PCSM only applies when GCS is a projected coordinate system. If GCS is a geographic coordinate system dictionary then PCSM should be ignored and GTPS used instead. If PCSM is present, it has priority over GPTS, and GPTS values may be ignored. This priority provides backward compatibility. NOTE 3 PCSM is an acronym for "Projected Coordinate System Matrix". |
| LPTS | array |
( |
12.10.3 Geographic coordinate system dictionary
Change the first paragraph as follows:
A geographic coordinate system (GEOGCS) specifies an ellipsoidal object in geographic coordinates: angular units of latitude and longitude. The geographic coordinate
systems
shall be described in
either or both
any
of two well-established standards: as a numeric EPSG reference code, or as a Well Known Text (WKT) string, which contains a description of algorithms and parameters needed for transformations.
...
Change the URL in the last paragraph as follows:
The EPSG reference codes are described in a database available through
http://www.epsg.org
https://epsg.org
as administered by the International Association of Oil and Gas Producers (OGP). The WKT (Well Known Text) format is specified in ISO 19162.
12.11 Document requirements
12.11.1 General
Change Table 273 as follows:
| Key | Type | Value |
|---|---|---|
| S | name |
(Required) The type of requirement that this dictionary describes.
See |
Change the paragraph after Table 273 as follows:
There are two additional keys that may appear in a requirements dictionary that are specific to certain types of requirements (i.e., value of the S key). These are described in "Table 274 — Entries for specific types of requirements".
In addition to the keys in "Table 273 - Entries common to all requirement dictionaries", there are two additional keys that may appear in a requirements dictionary that are specific to certain types of requirements as specified by the value of the S key. These are described in "Table 274 — Additional entries for specific types of requirements".
Re-caption Table 274 as follows:
| Key | Type | Value |
|---|---|---|
| ... | ... | ... |
12.11.2 Requirement types
Change Table 275 as follows:
| Type | Description |
|---|---|
| U3D |
Requires support for 3D data streams conforming to the U3D specification. This ... |
| PRC |
Requires support for 3D data streams conforming to the PRC specification. This ... |
Last modified: 29 April 2025