12. Interactive features

12.2 Viewer preferences

Change Table 147 as follows:

Table 147 - Entries in a viewer preferences dictionary
Key Type Value
NonFullScreenPageMode name

(Optional) The document’s page mode, specifying how to display the document on exiting full-screen mode:

  • UseNone Neither document outline nor thumbnail images visible
  • UseOutlines Document outline visible
  • UseThumbs Thumbnail images visible
  • UseOC Optional content group panel visible
  • UseAttachments (PDF 2.0) Attachments panel visible

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 7.7.3, "Page tree" "Table 31 - entries in a page object" and 14.11.2, "Page boundaries"). If the specified page boundary is not defined in the page object, its default value shall be used, as specified in "Table 31 - Entries in a page object".
Default value: CropBox CropBox
...
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 7.7.3, "Page tree" "Table 31 - entries in a page object" and 14.11.2, "Page boundaries"). If the specified page boundary is not defined in the page object, its default value shall be used, as specified in "Table 31 - Entries in a page object".
Default value: CropBox CropBox
...
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 7.7.3, "Page tree" "Table 31 - entries in a page object" and 14.11.2, "Page boundaries"). If the specified page boundary is not defined in the page object, its default value shall be used, as specified in "Table 31 - Entries in a page object".
Default value: CropBox CropBox
...
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 7.7.3, "Page tree" "Table 31 - entries in a page object" and 14.11.2, "Page boundaries"). If the specified page boundary is not defined in the page object, its default value shall be used, as specified in "Table 31 - Entries in a page object".
Default value: CropBox CropBox
...

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:

Table 151 - Entries in an outline item dictionary
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:

Table 161 - Entries in a page label dictionary
Key Type Value
S name

(Optional) The numbering style that shall be used for the numeric portion of each page label:

  • D - Decimal Arabic numerals
  • R - Uppercase Roman numerals
  • r - Lowercase Roman numerals
  • A - Uppercase letters (A to Z for the first 26 pages, AA to ZAZ for the next 26, and so on)
  • a - Lowercase letters (a to z for the first 26 pages, aa to zaz for the next 26, and so on)

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:

Table 164 - Entries in a transition dictionary
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 (upper case uppercase i)

O Outward from the centre of the page (upper case uppercase o)

Default value: I.

Di numberinteger or name

...

If the value is a numberan integer, it shall be one of:

...

...

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:

  1. 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.

  2. 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:

  1. 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.

  2. 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:

  1. The navigation node represented by PresSteps shall become the current node.

  2. 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.

  3. 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:

Table 166 - Entries common to all annotation dictionaries
Key Type Value
AP dictionary

(Optional; PDF 1.2 Required except for conditions listed below (PDF 2.0); optional in PDF 1.2 through PDF 1.7) An appearance dictionary specifying how the annotation shall be presented visually on the page. A PDF writer shall include an appearance dictionary when writing or updating the PDF file except for the two cases listed below.

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.

  • Annotations where the value of the Rect key consists of an array where the value at index 10 is equal to the value at index 32 and the value at index 21 is equal to the value at index 43.

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".

  • Annotations whose Subtype value is Popup, Projection or Link.
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. If an annotation dictionary includes the BS entry, then the Border entry is ignored.

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:

Table 176 - Additional entries specific to a link annotation
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:
x1 y1 x2 y2 x3 y3 x4 y4
specifying the four vertices of the quadrilateral in counterclockwise order. For orientation purposes, such as when applying an underline border style, the bottom of a quadrilateral is the line formed by (x1, y1) and (x2, y2).
If this entry is not present, or the PDF processor does not recognise it, or if any coordinates in the QuadPoints array lie outside the region specified by Rect then the activation region for the link annotation shall be defined by its Rect entry.

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 1.61.3)...

12.5.6.6 Free text annotations

Change Table 177 as follows:

Table 177 - Additional entries specific to a free text annotation
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 , if present, shall take precedence over the DA entry (see "Table 170 - Entries in an appearance dictionary" and 12.5.5, "Appearance streams").

BS dictionary (Optional; PDF 1.61.3)...

12.5.6.9 Polygon and polyline annotations

Change Table 181 as follows:

Table 181 - Additional entries specific to a polygon or polyline annotation
Key Type Value
Vertices array (Required unless a Path key is present, in which case it shall be ignored) Shall be ignored if Path is present. An array of numbers specifying the alternating horizontal and vertical coordinates, respectively, of each vertex, in default user space.
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 not be present be ignored.

...

12.5.6.13 Ink annotations

Change Table 185 as follows:

Table 185 - Additional entries specific to an ink annotation
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:

Table 202 - Additional entries specific to a go-to action
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:

Table 205 - Entries specific to a target dictionary
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.16 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:

Table 220 - Additional entries specific to a go-to-3D-view action
Key Type Value
S name

(Required) The type of action that this dictionary describes; shall be GoTo3DView for a transition Go-To-3D-View action.

V (various)

(Required) The view to use. It may be one of the following types:

  • A 3D view dictionary (see 13.6.4, "3D views").
  • An integer specifying an index into the VA array in the 3D stream (see "Table 311 — Entries in a 3D stream dictionary") , or the Views array of the RichMediaContent dictionary (see "Table 341 - Entries in a RichMediaContent dictionary"), as appropriate for the specified annotation.
  • A text string matching the IN entry in one of the views in the VA array (see "Table 315 — Entries in a 3D view dictionary") , or the Views array of the RichMediaContent dictionary (see "Table 341 - Entries in a RichMediaContent dictionary"), as appropriate for the specified annotation.
  • A name that indicates the first (F), last (L), next (N), previous (P), or default (D) entries in the VA or Views array; see discussion following this Table.

...

12.7 Forms

12.7.3 Interactive form dictionary

Change Table 224 as follows:

Table 224 - Entries in the interactive form dictionary
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:

Table 226 - Entries common to all field dictionaries
Key Type Value
T text string (Required Optional) The partial field name (see 12.7.4.2, "Field names").
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 an annotation dictionary (see 12.5.2, "Annotation dictionaries") a Widget annotation dictionary (see 12.5.6.19, "Widget annotations").

12.7.4.3 Variable text

Change Table 228 as follows:

Table 228 - Additional entries common to all fields containing variable text
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.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 Table 232 as follows:

Table 232 - Additional entry specific to a text field
Key Type Value
MaxLen integer

(Optional; inheritable) An integer value greater than or equal to zero that is the The maximum length of the field’s text, in characters.

12.7.5.5 Signature fields

Change Table 236 as follows:

Table 236 - Entries in a signature field lock dictionary
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:

Table 237 - Entries in a signature field seed value dictionary
Key Type Value
DigestMethod array

(Optional; PDF 1.7) An unordered array of names indicating acceptable digest algorithms to use while signing. The value Array values shall be SHA1 (deprecated with PDF 2.0), SHA256, SHA384, SHA512 and or RIPEMD160. The default value is implementation-specific.

This property is only applicable if the digital credential signing contains RSA public/private keys. If it contains DSA public/private keys, the digest algorithm is always SHA-1 and this attribute shall be ignored. Some signature mechanisms require a specific digest function to be used. In such cases, the value of this entry shall be ignored.

AddRevInfo boolean

NOTE 3 adbe.pkcs7.detached adbe.x509.rsa_sha1 and adbe.pkcs7.sha1 are deprecated in PDF 2.0.

...

Change Table 238 as follows:

Table 238 - Entries in a certificate seed value dictionary
Key Type Value
KeyUsage array of ASCII strings

...

1 digitalSignature 4 dataEncipherment 7
cRLSign
2 non-Repudiation 5 keyAgreement 8
encipherOnly
3 keyEncipherment 6 keyCertSign 9
decipherOnly

1 digitalSignature 4 dataEncipherment 7 cRLSign
2 non-Repudiation 5 keyAgreement 8 encipherOnly
3 keyEncipherment 6 keyCertSign 9 decipherOnly

...

...

12.7.6 Form actions

12.7.6.2 Submit-form action

Change Table 239 as follows:

Table 239 - Additional entries specific to a submit-form action
Key Type Value
Flags integer

(Optional; inheritable) ...

CharSet string

(Optional; inheritable) ...

12.7.6.3 Reset-form action

Change Table 242 as follows:

Table 242 - Flag for reset-form actions
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:

Table 255 - Entries in a signature dictionary
Key Type Value
Filter name

(Required; inheritable) ...

SubFilter name

...

(PDF 1.6) The following values for public-key cryptographic signatures should be used: adbe.x509.rsa_sha1 (PDF 1.3), adbe.pkcs7.detached (PDF 1.3), adbe.pkcs7.sha1 (PDF 1.4), ETSI.CAdES.detached (PDF 2.0) and ETSI.RFC3161 (PDF 2.0).

...

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:

Table 256 - Entries in a signature reference dictionary
Key Type Value
DigestMethod name

(RequiredOptional; deprecated in PDF 2.0) ...

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:

Table 257 - Entries in the DocMDP transform parameters dictionary
Key Type Value
P numberinteger

...

12.8.2.4 FieldMDP

Change Table 259 as follows:

Table 259 - Entries in the FieldMDP transform parameters dictionary
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:

Table 260 - SubFilter value algorithm support
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:

Table 263 - Entries in a permissions dictionary
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:

Table 269 - Additional entries in a geospatial measure dictionary
Key Type Value
PCSM array

(Optional; PDF 2.0) A 12-element transformation matrix of real numbers, defining the transformation from XObject position coordinates to 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".

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:

Table 273 - Entries common to all requirement dictionaries
Key Type Value
S name

(Required) The type of requirement that this dictionary describes. See "Table 276 — Entries in a requirement handler dictionary""Table 275 — Requirement types" for valid values.

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:

Table 274 - EntriesAdditional entries for specific types of requirements
Key Type Value
... ... ...

12.11.2 Requirement types

Change Table 275 as follows:

Table 275 - Requirement types
Type Description
U3D

Requires support for 3D data streams conforming to the U3D specification. This shall apply applies to the use of U3D in either 3D (13.6.3, "3D streams") or RichMedia annotations (13.7.2.2, "RichMediaSettings dictionary"). This also includes support for associated ECMAScripts.

...

PRC

Requires support for 3D data streams conforming to the PRC specification. This shall apply applies to the use of PRC in either 3D (13.6.3, "3D streams") or RichMedia annotations (13.7.2.2, "RichMediaSettings dictionary"). This also includes support for associated ECMAScripts.

...


Last modified: 25 October 2024