The PDF 2.0 specification (ISO 32000-2:2017) is a substantial document running to over 900 pages. Summit sessions distilled the changes that mattered most for implementers: Encryption improvements — PDF 1.7's encryption had several weaknesses, including RC4 cipher support and a vulnerable key derivation scheme. PDF 2.0 deprecated RC4, made AES-256 the mandatory algorithm for encrypted PDFs, and updated the key derivation to use a more robust scheme based on SHA-256. Sessions covered the migration path for tools that previously wrote RC4-encrypted documents. Optional content improvements — Optional content (layers, used in technical drawings and CAD-generated PDFs) was substantially revised. The rendering model was clarified, several ambiguities in the PDF 1.7 specification were resolved, and new attributes for usage application were defined. For tools used in engineering and architecture workflows, these changes were significant. Unencrypted wrapper documents — PDF 2.0 formalized the "unencrypted wrapper" pattern for encrypted PDFs: an outer PDF containing a visible message (e.g., "this document is encrypted") that wraps an encrypted inner PDF. This pattern existed informally in PDF 1.7 but had no normative specification. Structure element additions — New structure element types were added for more precise semantic markup, including types relevant to scientific and academic publishing. These are the foundation for PDF/UA-2's later requirements. Deprecated features — PDF 2.0 formally deprecated several features from PDF 1.x: XFA forms, certain obsolete encryption algorithms, and legacy file identifier schemes. Deprecation does not remove them from the specification but signals that conforming writers should not produce them in new documents.

The PDF specification, like all ISO standards, is normative text — it describes requirements in language intended to be precise but which inevitably contains passages open to interpretation. Two engineers reading the same sentence may implement different behaviours, both believing themselves correct. The result is interoperability failures: PDFs created by Tool A are mishandled by Tool B, and neither can easily determine who is "wrong." The PDF Association's response was the PDF 2.0 conformance test suite: a collection of specific PDF files designed to test particular features of the specification, with documented expected behaviours. A tool that correctly handles all test cases in a given category can claim conformance for that feature. Summit sessions covered the test suite's scope, how to use it in implementation workflows, and — critically — how to interpret failures. The test suite is not a pass/fail gate; it is a debugging tool. Understanding why a tool fails a specific test case leads directly to the implementation change needed to fix it. By the time of the Summit, the test suite was still in active development. Attendees were encouraged to contribute test cases for features their tools implemented, building out coverage in areas the Association's staff had not yet addressed.

Even a carefully written specification can contain errors, ambiguities, or inconsistencies that only become apparent when real-world implementations encounter edge cases. PDF 2.0 was no exception. Summit sessions provided a frank accounting of known issues in the PDF 2.0 specification text and the process for reporting and resolving them. The PDF Association's errata and clarifications process allows implementers to report specific passages that are ambiguous or incorrect. The Association's Technical Working Group reviews reports, determines the correct interpretation, and publishes non-normative clarifications on its website. The non-normative status of these clarifications was a source of frustration for some attendees: a clarification published by the PDF Association carries significant practical authority (it represents the consensus of the specification's authors and the broader expert community), but it is not technically part of the ISO standard. An implementation that follows the clarification is not formally more conformant than one that follows a different interpretation of the same text. This tension was addressed directly in discussion: the practical answer was that interoperability — the ability of different tools to produce and consume each other's output correctly — is the real objective, and the clarifications represent the best available guidance for achieving it. Formal incorporation into the standard happens at the next revision cycle.

Beyond the specification content itself, Summit sessions addressed the practical questions of how to prioritise and sequence PDF 2.0 implementation: Start with the encryption update — The deprecation of RC4 and the new AES-256 key derivation were identified as the highest-priority changes for any tool that writes encrypted PDFs, given the security implications of continuing to use deprecated algorithms. Test against PDF 1.7 outputs — PDF 2.0 is designed to be backward-compatible for most features. A PDF 2.0 parser that correctly handles a PDF 2.0 document should also correctly handle a PDF 1.7 document that uses equivalent features. The test suite includes both PDF 1.x and PDF 2.0 test cases for this reason. Deprecation ≠ removal — XFA forms and other deprecated features remain in the specification and conforming readers must still handle documents that contain them. Deprecation only restricts what a conforming writer should produce in new documents. Use PDF 2.0 features for new functionality only — Rather than wholesale migration, the recommended approach was to use PDF 2.0 output when new PDF 2.0 features are specifically needed, while continuing to produce PDF 1.7 output for documents that do not require them. This minimises adoption friction while building implementation experience. The Summit's practical guidance was borne out by subsequent events: PDF 2.0 adoption in the market followed exactly this gradual pattern, with tools adding PDF 2.0 output incrementally as specific features were required, rather than making a single wholesale transition.