Interactive features
12. Interactive features
12.2 Viewer preferences
Change Table 147 as follows:
Key | Type | Value |
---|---|---|
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, as defined in "Table 202 — Additional entries specific to a 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. |
...
Change the title of clause 12.4.2 as follows:
12.4.2 Page labels and indices
...
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.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".
|
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.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).
...
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). |
12.5.6.6 Free text annotations
Change Table 177 as follows:
Key | Type | Value |
---|---|---|
DA | 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 |
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"). |
Forms
12.7.4 Field dictionaries
12.7.4.1 General
Change Table 226 as follows:
Key | Type | Value |
---|---|---|
T | text string |
( |
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:
Key | Type | Value |
---|---|---|
MaxLen | integer |
(Optional; inheritable) An integer value greater than or equal to zero that is the
|
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 |
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
12.7.8.1 General
...
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
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.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.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: 14 Oct 2022