Syntax
7. Syntax
7.2 Lexical conventions
7.2.2 Representation
Change the first paragraph and the 3rd (last) bullet in the subsequent list as follows:
A non-encrypted PDF file can be entirely represented using byte values corresponding to the visible
printable subset of the ASCII character set defined in INCITS 4-1986 (R2017), plus white-space characters.
However, a
A PDF file is not restricted to the ASCII character set; it may contain arbitrary bytes, subject to the following considerations:
- ...
- ...
- A PDF file
containing binary datashall be transported as a binary file rather than as a text file to ensure that all bytes of the file are faithfully preserved.
...
Change Table 2 and add the footnote below Table 2 as follows:
| Glyph | Decimal | Hexadecimal | Octal | Name |
|---|---|---|---|---|
| { | 123 | 7B | 173 | LEFT CURLY BRACKET a |
| } | 125 | 7D | 175 | RIGHT CURLY BRACKET a |
(a) The delimiter characters { and } (LEFT CURLY BRACE (7Bh) and RIGHT CURLY BRACE (7Dh)) are additional delimiter characters only within Type 4 PostScript calculator functions (see 7.10.5 "Type 4 (PostScript calculator) functions").
7.3 Objects
7.3.3 Numeric objects
Add the following EBNF figure and embedded attachment above EXAMPLE 1:
📎
Change EXAMPLE 1 as follows:
EXAMPLE 1 Integer objects
123 43445 +17 -98 0 00987
...
Add the following EBNF figure and embedded attachment above EXAMPLE 2:
📎
Change EXAMPLE 2 as follows:
EXAMPLE 2 Real objects
34.5 -3.62 +123.6 4. -.002 0 009.87
...
7.3.4 String objects
7.3.4.2 Literal strings
Change first paragraph as follows:
A literal string shall be written as an arbitrary number of characters enclosed in parentheses (LEFT PARENTHESIS (28h) and RIGHT PARENTHESIS (29h)). Any characters may appear in a string except unbalanced parentheses and the backslash (REVERSE SOLIDUS (5Ch)), which shall be treated specially as described in this subclause. Balanced pairs of parentheses within a string require no special treatment.
...
7.3.8.2 Stream extent
Insert a new NOTE immediately after the first paragraph and before the EXAMPLE as follows:
NOTE: The 'encoded data' of a stream encompasses all enveloping markers of the encoding, e.g. end-of-data markers, if the encoding scheme uses them.
Change Table 5 as follows:
| Key | Type | Value |
|---|---|---|
| F | file specification |
(Optional; PDF 1.2) The file containing the stream data. If this entry is present, the bytes between stream and endstream
shall be ignored. However, the Length entry |
7.4.3 ASCII85Decode filter
Change the second paragraph as follows:
The ASCII base-85 encoding shall use the ASCII characters ! through u ((21h) - (75h)) and the character z (7Ah), with the 2-character sequence ~> (7Eh)(3Eh) as its EOD marker. The ASCII85Decode filter shall ignore all white-space characters (see 7.2, "Lexical conventions"). If the ASCII85Decode filter encounters the character ~ in its input, the next character shall be > and the filter will reach EOD. Any other characters shall cause an error. Any other characters, and any character sequences that represent impossible combinations in the ASCII base-85 encoding, shall cause an error.
Insert a new NOTE below the second paragraph as follows:
NOTE: the Adobe PostScript Language Reference Manual (PLRM), Third Edition, clause 3.13.3 defines the above parsing and error requirements for the ASCII base-85 EOD ~> marker.
Change last bulleted list as follows:
The following conditions shall never occur in a correctly encoded byte sequence:
- The value represented by a group of 5 characters is greater than
232232 - 1. - A z character occurs in the middle of a group.
- A final partial group contains only one character.
7.4.9 JPXDecode filter
Change paragraph below NOTE 5 as follows:
Data used in PDF image XObjects shall be limited to the JPX baseline set of features,
except for
excluding
enumerated colour space 19 (CIEJab).
In addition, enumerated colour space 12 (CMYK), which is part of JPX but not JPX baseline, shall be supported in a PDF file. JPX file
structures used in PDF files shall conform to the JPEG 2000 specification.
...
7.5 File structure
7.5.2 File header
Change the last paragraph as follows:
If a PDF file contains binary data, as most do (see 7.2, "Lexical conventions"), the header line shall be immediately followed by a
comment line containing line containing only a comment that starts with
at least four binary characters–that is, characters whose codes are 128 or greater.
This ensures proper behaviour of file transfer applications that inspect data near the beginning of a file to determine whether to treat the file’s contents as text or as binary.
7.5.4 Cross reference table
Change the first paragraph as follows:
The cross-reference table contains information that permits random access to indirect objects within the PDF file so that the entire PDF file need not be read to locate any particular object. The table shall containcomprises a one-line entry for each indirect object, specifying the byte offset of that object within the body of the PDF file. Beginning with PDF 1.5, some or all of the cross-reference information may alternatively be contained in cross-reference streams; see 7.5.8, "Cross-reference streams".
Change NOTE 1 as follows and move NOTE 1 below the second paragraph:
NOTE 1 The cross-reference table isCross-reference sections are the only part of a PDF file with a fixed format, which permits entries in the tablesections to be accessed randomly.
Change NOTE 3 as follows:
NOTE 3 The subsection structure is useful for incremental updates, since it allows a new cross-reference section to be added to the PDF file, containing entries only for objects that have been added, modified or deleted. This also means that cross reference subsections of incremental updates can never have an object number of zero.
Change paragraph below NOTE 3 as follows:
Each cross-reference subsection shall contain entries for a contiguous range of object numbers.
Each cross-reference subsection shall contain entries for a contiguous range of object numbers.
The subsection shall begin with a line containing only two non-negative integers separated by a single SPACE (20h) and terminated by an end-of-line marker (see 7.2.3, "Character set"). The two non-negative integers denote (respectively) the object number of the first object in this subsection and the number of entries in the subsection.
Change various paragraphs below EXAMPLE 1 as follows:
...
where:
nnnnnnnnnn shall be a 10-digit byte offset in the decoded stream PDF file
...
The byte offset in the decoded stream PDF file shall be a 10-digit number, padded with leading zeros if necessary, giving the number of bytes from the beginning of the PDF file to the beginning of the object. ...
Change EXAMPLE 2 as follows:
EXAMPLE 2 The cross-reference table sub-section line requires a single SPACE between "0" and "6".
Change EXAMPLE 3 as follows:
EXAMPLE 3 The cross-reference table first sub-section line requires a single SPACE between "0" and "1".
EDITOR NOTE: The typeface of Example 3 should be all monospaced and with single SPACEs between all cross-reference fields, and thus all cross-reference data fields vertically aligned.
7.5.5 File trailer
Change first paragraph as follows:
The trailer of a PDF file enables a PDF processor to quickly find the cross-reference table and certain
special objects. PDF processors should read a PDF file from its end. The last line of the file shall contain
only the end-of-file marker, %%EOF. The two preceding lines shall contain, one per line and in order,
the keyword startxref and the byte offset
in the decoded stream from the beginning of the PDF file to
the beginning of the xref keyword in the last cross-reference section
or the beginning of the previous cross-reference stream
(see 7.5.8, "Cross-reference streams"). The startxref line shall be
preceded by the trailer dictionary, consisting of the keyword trailer followed by a series of key-value
pairs enclosed in double angle brackets (<<...>>) (using LESS-THAN SIGNs (3Ch) and GREATER-THAN
SIGNs (3Eh)). Thus, the trailer has the following overall structure:
Change Table 15 as follows:
| Key | Type | Value |
|---|---|---|
| Size | integer |
(Required; shall not be an indirect reference)
NOTE 1: this is equivalent to the total number of entries in the PDF file’s cross-reference table, as defined by the combination of the original section and all update sections (see 7.5.4 "Cross-reference table"). Any object in a cross-reference section whose number is greater than this value shall be ignored and defined to be missing by a PDF reader. |
| Prev | integer |
(Optional; present only if the file has more than one cross-reference section; shall be a direct object)
The byte offset from the beginning of the PDF file to the beginning of the previous cross-reference
|
| Info | dictionary |
(Optional |
7.5.6 Incremental updates
...
Change NOTE 1 as follows:
NOTE 1 The main advantage to updating a PDF file in this way is that small changes to a large document can be saved quickly
. There are additional advantages such as when editing a document across an HTTP connection or using OLE embedding (a Microsoft WindowsTM specific technology)
, or when
a PDF processor cannot overwrite the contents of the original PDF file.
Incremental updates are used to save changes to documents in these contexts.
...
7.5.7 Object streams
Append the following paragraph after the bulleted list as follows:
The following objects shall not be stored in an object stream:
- ...
Any entry's value in an ObjStm dictionary shall be either a direct object or an indirect uncompressed object.
NOTE 3 Indirect references to objects inside object streams use the normal syntax: for example, 14 0 R. Access to these objects requires a different way of storing cross-reference information; see 7.5.8, "Cross-reference streams". Use of compressed objects requires a PDF 1.5 PDF reader. However, compressed objects can be stored in a manner that a PDF 1.4 PDF reader can ignore.
Insert the following new NOTE 4 after NOTE 3 as follows:
NOTE 4: Including the document catalog in an object stream has interoperability implications, particularly for encrypted documents. If the catalog dictionary is part of an object stream, a PDF processor reading the document must first process that object stream before it can access potentially relevant document metadata, including the declared PDF version, developer extensions and XMP metadata.
...
7.5.8 Cross-reference streams
7.5.8.2 Cross-reference stream dictionary
...
Change the first bullet point as follows:
-
The values of all entries shown in "Table 17 - Additional entries specific to a cross-reference
stream dictionary" shall be direct objects; indirect references shall not be permitted. For arrays
(the Index and W entries), all of their elements shall be direct objects as well.
If the stream is encoded, the Filter and DecodeParms entries in "Table 5 - Entries common to all stream dictionaries" shall also be direct objects.The values of all entries shown in "Table 5 - Entries common to all stream dictionaries" shall also be direct objects. For arrays, all array elements shall be direct objects and for dictionaries, all key values shall be direct objects as well. The F entry defined in Table 5 shall not be used. - ...
7.5.8.4 Compatibility with applications that do not support compressed reference streams
Change Table 19 as follows:
| Key | Type | Value |
|---|---|---|
| XRefStm | integer |
(Optional) The byte offset
|
...
7.6.2 Application of encryption
7.6.3 General encryption algorithm
Add new NOTE 1 after the 4th bullet in the first bulleted list below the first paragraph as follows:
Encryption applies to all strings and streams in the document's PDF file, with the following exceptions:
- ...
- Any hexadecimal strings representing the value of the Contents key in a Signature dictionary
NOTE 1 For the signature schemes enumerated in ISO 32000-1 and in this document, the value of the Contents key in a Signature dictionary is always a hexadecimal string (see "Table 255 — Entries in a signature dictionary").
Encryption is not applied to other object types such as integers and boolean values, which are used primarily to convey information about the document's structure rather than its contents. ...
...
7.6.3.1 General
Change NOTE 1 as follows:
NOTE 1 The name RC4™ is a registered trademark of RSA Security Inc. and cannot be used by third parties creating implementations of the algorithm. Proprietary implementations of the RC4 encryption algorithm are available under license from RSA Security Inc. For licensing information, contact: RSA Security Inc. 2955 Campus Drive, Suite 400, San Mateo, CA 94403-2507, USA, or http://www.rsasecurity.com/.
...
7.6.4 Standard security handler
7.6.4.1 General
Change the second paragraph above NOTE 2 as follows:
If a security handler of revision 4 or 5 is specified, the standard security handler shall support crypt filters (see 7.6.6, "Crypt filters").
The support shall be limited to the Identity crypt filter (see "Table 26 - Standard crypt filter names") and
crypt filters
a crypt filter
named StdCF whose dictionaries contain an AuthEvent value of DocOpen. For revision 4, the filter CFM value shall be V2 (RC4) or AESV2 (AES-128). For revision 6, the filter CFM value shall be AESV3 (AES-256). Public-Key security handlers in this case shall use
crypt filters
a crypt filter
named DefaultCryptFilter when all document content is encrypted, and shall use
crypt filters
a crypt filter
named DefEmbeddedFile when file attachments only are encrypted in place of StdCF name. This nomenclature shall not be used as an indicator of the type of the security handler or encryption. Use of security handler revisions 1, 2, 3, 4 and 5 is deprecated in PDF 2.0.
...
7.6.4.3.2 Algorithm 2: Computing a file encryption key in order to encrypt a document (revision 4 and earlier)
Change NOTE 2 as follows:
NOTE 2 The first element of the ID array, as used in 7.6.4.3.2, "Algorithm 2: Computing a file encryption key in order to encrypt a document (revision 4 and earlier)", step e, generally remains unchanged across revisions of a given document. However, since this is not guaranteed, use of the ID in computation of the file encryption key, as required when using 7.6.4.3.3, "Algorithm 2.A: Retrieving the file encryption key from an encrypted document in order to decrypt it (revision 6 and later)Algorithm 2: Computing a file encryption key in order to encrypt a document (revision 4 and earlier)", can complicate updates to the document. For this reason, security handlers are encouraged to use Algorithm 2.A or higher, which do not use the ID in file encryption key computation. This algorithm, when applied to the user password string, produces the file encryption key used to encrypt or decrypt string and stream data according to 7.6.3.2, "Algorithm 1: Encryption of data using the RC4 or AES algorithms". Parts of this algorithm are also used in the algorithms described below.
Insert new NOTE 3 immediately below NOTE 2 as follows:
NOTE 3 This algorithm, when applied to the user password string, produces the file encryption key used to encrypt or decrypt string and stream data according to 7.6.3.2, "Algorithm 1: Encryption of data using the RC4 or AES algorithms". Parts of this algorithm are also used in the algorithms described in 7.6.4.4, "Password algorithms".
7.6.4.3.3 Algorithm 2.A: Retrieving the file encryption key from an encrypted document in order to decrypt it (revision 6 and later)
Insert new NOTE below bullet (f) as follows:
-
Decrypt the 16-byte Perms string using AES-256 in ECB mode
with an initialization vector of zeroand the file encryption key as the key. ...
NOTE This algorithm, when applied to the user password string, produces the file encryption key used to encrypt or decrypt string and stream data according to 7.6.3.3, "Algorithm 1.A: Encryption of data using the AES algorithms". Parts of this algorithm are also used in the algorithms described in 7.6.4.4, "Password algorithms".
7.6.4.4.9 Algorithm 10: Computing the encryption dictionary's Perms (permissions) value (Security handlers of revision 6)
Change bullet (f) as follows:
-
Encrypt the 16-byte block using AES-256 in ECB mode
with an initialization vector of zero, using the file encryption key as the key. The result (16 bytes) is stored as the Perms string, and checked for validity when the file is opened.
7.6.4.4.12 Algorithm 13: Validating the permissions (Security handlers of revision 6)
Change bullet (a) as follows:
-
Decrypt the 16 byte Perms string using AES-256 in ECB mode
with an initialization vector of zeroand the file encryption key as the key. ...
7.6.5 Public-key security handlers
7.6.5.1 General
...
7.6.5.2 Public-key security dictionary
...
Change the paragraph below the NOTE as follows:
Permitted values of the SubFilter entry for use with conforming public-key security handlers are adbe.pkcs7.s3 (PDF 1.3), adbe.pkcs7.s4 (PDF 1.4), which shall be used when not using crypt filters (see 7.6.6, "Crypt filters") and adbe.pkcs7.s5 (PDF 1.5), which shall be used when using crypt filters.
...
Insert a new subclause heading immediately below the NOTE below Table 23 as follows:
7.6.5.3 Public-key security permissions
EDITOR NOTE: current text and Table 24 remain unchanged.
Renumber the next clause appropriately:
7.6.5.37.6.5.4 Public-key encryption algorithms
Change the second bullet as follows:
- ...
- A 4-byte value defining the permissions, most significant byte first. See 7.6.5.3, "Public-key security permissions" and "Table 24 — Public-key security handler user access permissions" for the possible permission values.
- ...
Add two new notes at the very end of the sub-clause as follows:
NOTE 1: This means that step c) only applies when both of the following conditions are met:
- the key is being generated for the crypt filter named DefaultCryptFilter (i.e. the crypt filter used as the value for StmF in the encryption dictionary);
- the EncryptMetadata entry of the associated crypt filter dictionary is set to false.
NOTE 2: Since crypt filters are not supported when SubFilter is set to adbe.pkcs7.s3 or adbe.pkcs7.s4 in the encryption dictionary, there is no way to specify that metadata is to be left unencrypted in these cases. In particular, step c) is always skipped for these SubFilter values.
7.6.6 Crypt filters
Change the first bullet in the sub-clause as follows:
PDF 1.5 introduces crypt filters, which provide finer granularity control of encryption within a PDF file. The use of crypt filters involves the following structures:
- The encryption dictionary (see "Table 20 - Entries common to all encryption dictionaries") contains entries that enumerate the crypt filters in the document (CF) and specify which ones are used by default to decrypt all the streams (StmF) and strings (StrF) in the document. In addition, the value of the V entry shall be 4 or 5 to use crypt filters.
...
Change Table 25 as follows:
| Key | Type | Value |
|---|---|---|
| Length | integer |
(Required; deprecated in PDF 2.0) ... When CFM is AESV2, the Length key shall have the value of 128 for public-key security handlers, and 16 for the standard security handler. When CFM is AESV3, the Length key shall have a value of 256 for public-key security handlers, and 32 for the standard security handler. |
...
Change Table 27 as follows:
| Key | Type | Value |
|---|---|---|
| Recipients | byte string or array |
(Required) If the crypt filter is referenced from StmF or StrF in the encryption dictionary, this entry shall be an array of byte strings, where each byte string shall be a binary-encoded CMS object that shall ... ... If the crypt filter is referenced from a Crypt filter decode parameter dictionary (see "Table 14 - Optional parameters for Crypt filters"), this entry shall be a byte string that shall be a binary-encoded CMS object that shall ... |
7.7 Document structure
7.7.1 General
Move Figure 5 from subclause 7.7.2 to after the first paragraph, and update Figure 5 as follows:
7.7.2 Document catalog dictionary
...
Move Figure 5 - Structure of a PDF document from here to subclause 7.7.1:
Change Table 29 as follows:
| Key | Type | Value |
|---|---|---|
| Extensions | dictionary | (Optional; shall be a direct object; ISO 32000-1) ... |
| Dests | dictionary |
(Optional; PDF 1.1 |
| Outlines | dictionary |
(Optional |
| Threads | array |
(Optional; PDF 1.1 |
| Lang | text string |
(Optional; PDF 1.4) A language identifier that shall specify the natural language for all text in the document except where overridden by language specifications for structure elements or marked-content (see 14.9.2, "Natural language specification"). If this entry is absent or invalid (see 14.9.2, "Natural language specification"), the language shall be considered unknown. NOTE All text in a document includes PDF text strings (see 7.9.2.2 "Text string type") as well as textual content. |
| StructTreeRoot | dictionary | (Optional; PDF 1.3; shall be an indirect reference) ... |
7.7.3 Page tree
7.7.3.2 Page tree nodes
Change Table 30 as follows:
| Key | Type | Value |
|---|---|---|
| Kids | array | (Required) An array of indirect references to the immediate children of this node. The children shall only be page objects or other page tree nodes (null entries shall not be present). The length of the array shall be at least one. |
| Count | integer |
(Required) The number of leaf nodes (page objects) that are descendants of this node within the page tree which shall be 1 or greater.
NOTE Since the number of pages descendent from a Pages dictionary can be accurately determined by examining the tree itself using the Kids arrays, the Count entry is redundant. A PDF writer shall ensure that the value of the Count key is consistent with the number of entries in the Kids array and its descendants which definitively determines the number of descendant pages. |
7.7.3.3 Page objects
Change Table 31 as follows:
| Key | Type | Value |
|---|---|---|
| Contents | stream or array |
(Optional) A content stream (see 7.8.2, "Content streams") that shall describe the contents of this page. If this entry is absent, the page shall be empty. NOTE If the Contents key is not present, a Resources dictionary must still be present, either directly or through inheritance, in the pages tree. ... |
| ID | byte string |
(Optional; PDF 1.3 |
| B | array |
(Optional; PDF 1.1; recommended if the page contains article beads) An array that shall contain indirect references to all article beads
appearing on the page (see 12.4.3, "Articles"). The beads shall be listed in the array in
... |
7.7.4 Name dictionary
...
Change all occurrences of "name string" to "string" in Table 32 as follows:
| Key | Type | Value |
|---|---|---|
| Dests | name tree |
(Optional; PDF 1.2) name tree mapping |
| AP | name tree |
(Optional; PDF 1.3) name tree mapping |
| JavaScript | name tree |
(Optional; PDF 1.3) name tree mapping |
| Pages | name tree |
(Optional; PDF 1.3) name tree mapping |
| Templates | name tree |
(Optional; PDF 1.3) name tree mapping |
| EmbeddedFiles | name tree |
(Optional; PDF 1.4) name tree mapping (PDF 2.0) For unencrypted wrapper documents for an encrypted payload document (see 7.6.7, "Unencrypted wrapper document") the
|
| AlternatePresentations | name tree |
(Optional; PDF 1.4) name tree mapping |
| Renditions | name tree |
(Optional; PDF 1.5) A name tree mapping |
7.8.2 Content streams
Change the paragraph above Table 33 as follows:
Ordinarily, when a PDF reader encounters an operator in a content stream that it does not recognise, an error shall occur. A pair of compatibility operators, BX and EX (PDF 1.1), shall modify this behaviour (see "Table 33 — Compatibility operators"). These operators shall occur in pairs and may be nested. They bracket a compatibility section, a portion of a content stream within which unrecognised operators shall be ignored without error. This mechanism enables a PDF processor to use operators defined in later versions of PDF without sacrificing compatibility with older applications. It should be used only in cases where ignoring such newer operators is the appropriate thing to do. The BX and EX operators are not themselves part of any graphics object (see 8.2, "Graphics objects") or of the graphics state (8.4, "Graphics state"). All pairs of matching operators (marked-content operators BMC, BDC, and EMC (see 14.6, "Marked content"); text object operators BT and ET (see 9.4, "Text objects"); the compatibility operators BX and EX (see "Table 33 - Compatibility operators") and the graphics state save and restore operators q and Q (see "Table 56 - Graphics state operators")) shall be properly (separately) nested.
7.8.3 Resource dictionaries
Change the bulleted list below EXAMPLE 1 as follows:
A resource dictionary shall be associated with a content stream in one of the following ways:
-
For a content stream that is the value of a page's Contents entry
(or is an element of an array that is the value of that entry), the resource dictionary shall be designated by the page dictionary's Resources entry or is inherited, as described under 7.7.3.4, "Inheritance of page attributes" from some ancestor node of the page object. PDF writers should not use this inheritance feature of PDF as its use can cause undue complexity for a PDF reader. A PDF writer should only include resource definitions for resources that are actually referenced by the content streams of the associated page in the Resources dictionary. If the content streams of multiple pages require exactly the same set of resources, a single Resources dictionary may be shared between them by using indirect references. If each page requires different sets of resources, then each should be written with its own Resources dictionary. -
Content streams that define the glyph descriptions of a Type 3 font shall include a Resources entry in the Type 3 font dictionary specifying all the resources used by all the content streams in the CharProcs dictionary of a Type 3 font.If a glyph description content stream in the CharProcs entry of a Type 3 font uses named resources directly then those resources shall be present in the resource dictionary designated by the first Resources entry found in the following search order:
- the stream dictionary of that glyph description content stream;
- the parent Type 3 font dictionary that contained the CharProcs entry with the glyph description content stream;
If there is no Resources dictionary explicitly associated with the Type 3 glyph description content stream or Type 3 font dictionary:
- the parent page dictionary on which the Type 3 font is used;
- resource inheritance from ancestor nodes of the parent page dictionary (see 7.7.3.4 "Inheritance of page attributes").
NOTE 2: Named resources referenced by a resource, such as an XObject referenced from a glyph description content stream, would be included in the Resources dictionary of that resource rather than in the designated resource dictionary of the glyph description content stream.
- For other types of content streams, a PDF writer shall include a Resources entry in the stream's dictionary specifying a resource dictionary which contains all named resources used by that content stream. This shall apply to content streams that define form XObjects (see "Table 93 — Additional entries specific to a Type 1 form dictionary"), patterns (see "Table 74 — Additional entries specific to a Type 1 pattern dictionary"), and annotation appearances (see 12.5.5 "Appearance streams").
-
PDF files written obeying earlier versions of PDF may have omitted the Resources entry in all form XObjects and Type 3 fonts used on a page. All resources that are referenced from those forms and fonts shall be inherited from the resource dictionary of the page on which they are used.
NOTE 3 PDF files written obeying earlier versions of PDF may have omitted the Resources entry in form XObjects, Type 3 glyph descriptions or annotation appearance streams used on a page. Those earlier versions state that resources that were referenced from those content streams can be inherited from the resource dictionary of the page on which they are used.
NOTE 4 Linearized PDF files impose additional requirements on resources - see "Annex F - (normative) Linearized PDF".
...
Change Table 34 as follows:
| Key | Type | Value |
|---|---|---|
| ColorSpace | dictionary |
(Optional) A dictionary that maps each resource name to either the name of a
|
7.9 Common data structures
7.9.1 General
Replace Table 35 with the following table and NOTE:
| Type | Description | Subclause |
|---|---|---|
| ASCII string |
|
7.3.4 7.9.2 |
| array | An array object. | 7.3.6 |
| boolean | A Boolean object. | 7.3.2 |
| byte string |
|
7.3.4 7.9.2 7.9.2.4 |
| date |
|
7.3.4 7.9.2 7.9.4 |
| dictionary | A dictionary object. | 7.3.7 |
| file specification | A file specification (dictionary or string) | 7.11 |
| function |
|
7.10 |
| integer | An integer number object | 7.3.3 |
| name | A name object | 7.3.5 |
| name tree |
|
7.9.6 |
| null | The null object | 7.3.9 |
| number |
NOTE: the term "real" may also be used in this specification to represent a numeric object. |
7.3.3 |
| number tree |
|
7.9.7 |
| PDFDocEncoded string |
|
7.9.2 7.9.2.3 |
| rectangle |
|
7.9.5 |
| stream | A stream object (including the stream extent dictionary) | 7.3.8 |
| string |
|
7.3.4 7.9.2 |
| text string |
|
7.9.2 7.9.2.2 |
| text stream | A text stream object (including the stream extent dictionary) | 7.9.3 |
NOTE: unless otherwise stated in this specification, all string objects may be written as either a literal string or a hexadecimal string as described in "7.3.4 - String objects".
7.9.2 String object types
7.9.2.2 Text string type
7.9.2.2.1 General
Change EXAMPLE 1 as follows:
EXAMPLE 1 A PDF dictionary containing key 'Key' with the value that is the text string "text‰" will look like
<</Key(text?)>>
<</Key (text\213) >>
where the character '?' after the 'text' is represented by the hex code 8Bh (octal code 213 - that is according to "D.2 Latin character set and encodings".
...
Change EXAMPLE 2 as follows:
EXAMPLE 2 A PDF dictionary containing key 'Key' with the value that is the text string "тест" (that is what the word in Russian with the translation to English as 'test') will look like
<</Key(??????????)>>
<</Key <FEFF0442043504410442> >>
where the characters in parentheses is the sequence of bytes with hex codes FE, FF, 04, 42, 04, 35, 04, 41, 04, 42.
...
Change NOTE 4 as follows:
NOTE 4 This mechanism precludes beginning a string using PDFDocEncoding
with the three characters dieresisidieresis,
guillemotright, questiondown, which is unlikely to be a meaningful beginning of a word or phrase.
Delete NOTE 5 as follows:
NOTE 5 It is important not to confuse UTF-16BE with UCS2 (i.e. wchar_t). UTF-16 is not a fixed width encoding scheme.
7.9.2.4 Byte string type
Change the first paragraph as follows, including adding an EXAMPLE and a new NOTE:
The byte string type shall be used for binary data that shall be represented as a series of bytes, where each byte may be any value representable in 8 bits.
Byte string type is a subtype of string type.
For example, byte strings are used to define a file identifier (see 14.4, "File identifiers") that is specified in ID entry of PDF file trailer
(see "Table 15 — Entries in the file trailer dictionary").In such case byte string is written in hexadecimal form (see 7.3.4.3, "Hexadecimal strings") and looks like
Unless otherwise stated in this document, a byte string may be either a literal string (see 7.3.4.2, "Literal strings") or a hexadecimal string (see 7.3.4.3, "Hexadecimal strings").
<B6FB54F3F8554D478DC874F11DAD0F11>
EXAMPLE Byte strings are used to define a file identifier (see 14.4, "File identifiers")
that are specified in the ID entry of the PDF file trailer (see "Table 15 — Entries in the file trailer dictionary").
If written in hexadecimal form, an ID array entry looks like:
<B6FB54F3F8554D478DC874F11DAD0F11>
NOTE 1 The Contents entry of a Signature dictionary can be required to be a hexadecimal string (see "Table 255 - Entries in a signature dictionary").
NOTE 2 The string can represent characters but the encoding is not known. The bytes of the string do not have to represent characters.
7.9.4 Dates
...
Change the last paragraph before the EXAMPLE as follows:
The prefix “D:” shall be present, the year field (YYYY) shall be present and all other fields may be
present but only if all of their preceding fields are also present. The APOSTROPHE following the hour
offset field (HH) shall only be present if the HH field is present. The minute offset field (mm) shall only
be present if the APOSTROPHE following the hour offset field (HH) is present. The default values for MM and
DD shall be both 01; all other numerical fields shall default to zero values. A PLUS SIGN as the value of
the O field signifies that local time is now and later than UT, a HYPHEN-MINUS signifies that local time is
earlier than UT, and the LATIN CAPITAL LETTER Z signifies that local time is equal to UT. If no UT information is specified,
the relationship of the specified time to UT shall be considered to be GMT.
the missing timezone offset shall be assumed to be the same as Greenwich Mean Time's timezone offset (+0'00).
Regardless of whether the time zone is specified, the rest of the date shall be specified in local time.
...
7.9.6 Name trees
...
Change Table 36 as follows:
| Key | Type | Value |
|---|---|---|
| Names | array |
(Root and leaf nodes only; required in leaf nodes; present in the root node if and only if Kids is not present) Shall be an array of the form [key1 value1 key2 value2 ...keyn valuen] where each keyi shall be a string and the corresponding valuei shall be the
object associated with that key. The keys shall be sorted |
Change the paragraph below Table 36 as follows:
The Kids entries in the root and intermediate nodes define the tree’s structure by identifying the immediate children of each node.
The Names entries in the leaf (or root) nodes shall contain the tree’s keys and their associated values, arranged in key-value pairs and shall be sorted
lexically in ascending order by key. Shorter keys shall appear before longer ones beginning with the same byte sequence.
Any encoding of the keys may be used as long as it is self-consistent; keys shall be compared for equality on a simple byte-by-byte basis.
...
7.9.7 Number trees
Change Table 37 as follows:
| Key | Type | Value |
|---|---|---|
| Nums | array |
(Root and leaf nodes only; shall be required in leaf nodes; present in the root node if and only if Kids is not present) Shall be an array of the form [key1 value1 key2 value2 ...keyn valuen] where each keyi shall is an integer and the corresponding valuei shall be the object associated with that key. The keys shall be sorted in numerical order, analogously to the arrangement of keys in a name tree as described in 7.9.6, "Name trees". Keys shall not be the null object. |
7.10 Functions
7.10.3 Type 2 (exponential interpolation) functions
Change the paragraph below Table 40 as follows:
Values of Domain shall constrain x in such a way that:
- if N is not an integer, all values of x will be non-negative; and
- if N is negative, no value of x will be zero.
Typically, Domain is declared as [0.0 1.0], and N is a positive number. To clip the output to a specified range the Range attribute shall be used.
...
7.10.5 Type 4 (PostScript calculator) functions
7.10.5 Operators and operands
Change Table 42 as follows:
| Operator Type | Operators |
|---|---|
| Conditional operators |
Ifif
ifelse
|
7.11 File specifications
7.11.3 File specification dictionaries
Change Table 43 as follows:
| Key | Type | Value |
|---|---|---|
| Type | name |
(Required if an EF, EP or RF entry is present; recommended always; PDF 1.3) The type of PDF object that this dictionary describes; shall be Filespec for a file specification dictionary. |
7.11.4 Embedded file streams
7.11.4.1 General
Change Table 44 as follows:
| Key | Type | Value |
|---|---|---|
| Subtype | name |
(Optional, required in the case of an embedded file stream used as an associated file (see 14.13 "Associated files") or as an asset of a RichMedia annotation (see "13.7 Rich media")) ... |
7.11.6 Collection items
Change Table 47 as follows:
| Key | Type | Value |
|---|---|---|
| D | text string, date or number |
(Optional) The data corresponding to the related entry in the collection field dictionary (see "Table 155 - Entries in a collection field dictionary").
The type of data shall match the data type identified by the corresponding collection field dictionary. |
| P | text string |
(Optional) A prefix string that shall be concatenated with the text string presented to the user. This entry is ignored when an interactive PDF
processor sorts the items in the collection. |
7.12.2 Extensions dictionary
Change Table 48 as follows:
| Key | Type | Value |
|---|---|---|
| Type | name |
(Optional, shall be a direct |
7.12.5 ExtensionLevel
Change the paragraph as follows:
The value of the ExtensionLevel entry shall be an integer, which shall be interpreted with respect to the BaseVersion value.
If a developer has released multiple extensions against the same BaseVersion value, they shallshould be ordered over time and the ExtensionLevel numbers shall be a monotonically increasing sequenceshould increase over time.
Last modified: 1 March 2024