PDF 2.0 (ISO 32000-2:2017) had been published in July 2017. By May 2019, the first production libraries with PDF 2.0 support were shipping: iText 7's PDF 2.0 features were available, PDFlib had PDF 2.0 output, and Adobe Acrobat had selective PDF 2.0 support. PDF Days Europe 2019 was the first conference where sessions could draw on real implementation experience rather than specification analysis. AES-256 encryption improvements — PDF 2.0 corrected a known vulnerability in PDF 1.7's AES-256 key derivation. Implementors reported that the correction was technically straightforward but required careful handling of the /EncryptMetadata and encryption dictionary versioning to avoid creating PDFs that older viewers would misidentify as PDF 1.7 encrypted files (which would use the weaker key derivation). Page-level metadata — PDF 2.0 introduced page-level XMP metadata streams. The use case — different pages of a document having different copyright, authorship, or licensing information — was well-understood from publishing workflows, but implementors were discovering that the inheritance rules between document-level and page-level metadata needed careful handling. If a page has its own metadata stream, does it fully replace the document-level metadata, or only override the properties it explicitly specifies? Associating file attachments with pages — PDF 2.0 formalised the page-level /AF (Associated Files) mechanism, which allows arbitrary files to be attached to a specific page rather than the document as a whole. This was particularly relevant for PDF/A-3 workflows embedding structured data: with page-level AF, an invoice PDF could embed its ZUGFeRD/Factur-X XML attachment at the document level while embedding image references at their respective pages. New structure elements — The additional tagged PDF structure elements in PDF 2.0 (/Aside, /FENote, /Sub, /Em, /Strong) were discussed. Tool support was minimal — authoring tools were not yet producing them, and validators were not yet checking for them. They were a future capability rather than a current practitioner concern.

The EU Web Accessibility Directive (2016/2102) required member state public sector bodies to make their websites and mobile applications accessible by September 2019 (for new content) and September 2020 (for existing content). PDFs published on public body websites were in scope. This created an urgent, compliance-driven demand for PDF/UA guidance and tooling that had not existed as strongly in previous years. Matterhorn Protocol adoption — The PDF Association's Matterhorn Protocol (a machine-testable interpretation of PDF/UA requirements) had been published in 2013. By 2019, validator tools (PAC 3, veraPDF) had implemented Matterhorn Protocol checkpoint testing, making automated PDF/UA validation practical for the first time. Government agencies were deploying these validators in document management system workflows to catch non-compliant PDFs before publication. Common failures in government PDFs — Analysis of UK Government, European Commission, and German federal agency PDFs revealed consistent failure patterns: missing document language declaration, missing document title in XMP metadata, untagged figures (images without alt text), incorrectly tagged tables (missing header scope attributes), and reading order that did not match visual order for multi-column layouts. PDF/UA for procurement — A key development discussed at PDF Days 2019 was the inclusion of PDF/UA requirements in public procurement contracts for document management software. Several EU member states had begun specifying PDF/UA in their tender requirements for content management systems, word processors, and PDF generation tools. This was a significant market signal: PDF/UA support was becoming a procurement filter rather than an optional feature.

Three years after eIDAS came into force, the 2019 conference could draw on real enterprise adoption data. The patterns that had emerged by 2019: Qualified signatures in the public sector — EU public administrations were the primary early adopters of qualified signatures. Tax authority filings, land registry submissions, and notarial documents were among the first use cases to require qualified signatures under national implementations of eIDAS. Remote signing services — The hardware token model (USB tokens, smart cards) was being displaced by remote signing services where the private key is stored in an HSM at a trust service provider. Users authenticate via a mobile app (typically SMS OTP or biometric) to authorise the signing operation without handling a hardware token. ETSI's standardisation of the remote signing protocol (TS 119 432) had enabled multiple TSPs to offer interoperable remote signing services. Seal signatures for organisations — eIDAS also defined electronic seals for legal entities (as opposed to natural persons). Organisation-level PDF seals were being adopted for automated, high-volume document workflows: generating and sealing client statements, invoices, and confirmations without individual human signature actions. Cross-border signature validation challenges — Despite eIDAS's goal of cross-border recognition, practical interoperability challenges persisted. The EU Trusted Lists of qualified trust service providers were the mechanism for cross-border validation — a qualified signature created with a certificate from a qualified TSP in one member state should be verifiable in another. Validator tools and PDF viewers were inconsistently implementing the Trusted List lookup, leading to "signature unknown" results when validating cross-border qualified signatures in some environments.