Skip to content

PDF Spec Annex C

Jump to bottom
Marc Jones edited this page Dec 30, 2025 · 1 revision

Annex C: Implementation Limits

Part of: PDF-Spec-Annexes

Navigation: PDF-Spec-Annex-B | PDF-Spec-Index | PDF-Spec-Annex-D

Annex C

(normative)

Implementation Limits

Table C.1 - Architectural limits (continued)

Quantity Limit Description
5 Number of significant decimal digits of precision in fractional part (approximate).
string (in content stream) 32,767 Maximum length of a string, in bytes. This restriction applies only to strings in content streams. There is no effective restriction on other strings in PDF files.
name 127 Maximum length of a name, in bytes.
indirect object 8,388,607 Maximum number of indirect objects in a PDF file.
q / Q nesting 28 NOTE Maximum depth of graphics state nesting by q and Q operators. This is not a limit as such, but arises from the fact that q and Q are implemented by the PostScript gsave and grestore operators when
DeviceN components 32 Maximum number of colorants or tint components in a DeviceN colour space.
CID 65,535 Maximum value of a CID (character identifier).

Additionally, conforming writers should adhere to the following constraints, and conforming readers should accommodate PDF files that obey the constraints.

  • Thumbnail images should be no larger than 106 by 106 samples, and should be created at one-eighth scale for 8.5-by-11-inch and A4-size pages.
  • The minimum page size should be 3 by 3 units in default user space; the maximum should be 14,400 by 14,400 units. In versions of PDF earlier than 1.6, the size of the default user space unit was fixed at 1 Ú 72 inch, yielding a minimum of approximately 0.04 by 0.04 inch and a maximum of 200 by 200 inches. Beginning with PDF 1.6, the size of the unit may be set on a page-by-page basis; the default remains at 1/ 72 inch.
  • The magnification factor of a view should be constrained to be between approximately 8 percent and 6400 percent.
  • When a conforming reader reads a PDF file with a damaged or missing cross-reference table, it may attempt to rebuild the table by scanning all the objects in the file. However, the generation numbers of deleted entries are lost if the cross-reference table is missing or severely damaged. To facilitate such reconstruction, object identifiers, the endobj keyword, and the endstream keyword should appear at the start of a line. Also, the data within a stream should not contain a line beginning with the word endstream , aside from the required endstream that delimits the end of the stream.

C.3 Memory limits

Memory limits cannot be characterized as precisely as architectural limits because the amount of available memory and the ways in which it is allocated vary from one conforming product to another.

  • NOTE Memory is automatically reallocated from one use to another when necessary: when more memory is needed for a particular purpose, it can be taken from memory allocated to another purpose if that memory is currently unused or its use is nonessential (a cache, for example). Also, data is often saved to a temporary file when memory is limited. Because of this behaviour, it is not possible to state limits for such items as the number of pages in a document, number of text annotations or hypertext links on a page, number of graphics objects on a page, or number of fonts on a page or in a document.

D.1 General

This annex lists the character sets and encodings that shall be predefined in any conforming reader. Simple fonts, encompassing Latin text and some symbols, are described here. See 9.7.5.2, "Predefined CMaps" for a list of predefined CMaps for CID-keyed fonts.

D.2, "Latin Character Set and Encodings", describes the entire character set for the Adobe standard Latin-text fonts. This character set shall be supported by the Times, Helvetica, and Courier font families, which are among the standard 14 predefined fonts; see 9.6.2.2, "Standard Type 1 Fonts (Standard 14 Fonts)". For each named character, an octal character code is defined for four different encodings: StandardEncoding , MacRomanEncoding , WinAnsiEncoding , and PDFDocEncoding (see Table D.1). Unencoded characters are indicated by a dash (-).

D.3, "PDFDocEncoding Character Set", describes the entire set of characters that can be represented using PDFDocEncoding. It presents these characters in numerical order and it describes the Unicode representation of each character. This table overlaps the information presented in D.2, "Latin Character Set and Encodings", with respect to the presented octal character codes.

D.4, "Expert Set and MacExpertEncoding", describes the 'expert' character set, which contains additional characters useful for sophisticated typography, such as small capitals, ligatures, and fractions. For each named character, an octal character code is given in MacExpertEncoding .

NOTE The built-in encoding in an expert font program may be different from MacExpertEncoding .

D.5, "Symbol Set and Encoding", and D.6, "ZapfDingbats Set and Encoding", describe the character sets and built-in encodings for the Symbol and ZapfDingbats (ITC Zapf Dingbats) font programs, which shall be among the standard 14 predefined fonts. These fonts have built-in encodings that are unique to each font. The characters for ZapfDingbats are ordered by code instead of by name, since the names in that font are meaningless.

Table D.1 - Latin-text encodings

Encoding Description
StandardEncoding Adobe standard Latin-text encoding. This is the built-in encoding defined in Type 1 Latin-text font programs (but generally not in TrueType font programs). Conforming readers shall not have a predefined encoding named StandardEncoding . However, it is necessary to describe this encoding, since a font's built-in encoding can be used as the base encoding from which differences may be specified in an encoding dictionary.
MacRomanEncoding Mac OS standard encoding for Latin text in Western writing systems. Conforming readers shall have a predefined encoding named MacRomanEncoding that may be used with both Type 1 and TrueType fonts.
WinAnsiEncoding Windows Code Page 1252, often called the 'Windows ANSI' encoding. This is the standard Windows encoding for Latin text in Western writing systems. Conforming readers shall have a predefined encoding named WinAnsiEncoding that may be used with both Type 1 and TrueType fonts.

Navigation: PDF-Spec-Annex-B | PDF-Spec-Index | PDF-Spec-Annex-D

Clone this wiki locally