Why Standard PDFs Will Stop Opening Thirty Years from Today

When a business, court of law, or national archive stores a digital contract, patent filing, or historical record today, there is an implicit assumption: someone will be able to open, read, and interpret this document identically 30, 50, or 100 years from now.

Under the standard commercial PDF specification (ISO 32000), that assumption is dangerous. Ordinary PDFs are packed with dynamic features designed for real-time web interactivity: external font references, live JavaScript form calculations, embedded 3D models, audio tracks, proprietary compression filters, and remote hyperlinks. In two decades, the fonts referenced on your operating system will no longer exist, the external servers hosting hyperlinked assets will be decommissioned, and modern viewing software will refuse to run legacy interactive scripts for security reasons.

To solve the existential threat of digital document decay, the International Organization for Standardization developed ISO 19005 (PDF/A). In this engineering analysis, we deconstruct the technical machinery of PDF/A, examine what makes a document truly self-contained, and provide a comprehensive blueprint for long-term archival preparation.

1. The 20-Year Problem: Why Ordinary PDFs Become Unreadable

To understand why standard PDFs decay over time, consider what happens when a PDF document renders a single sentence of text. In an unoptimized, standard PDF, the file often contains a font dictionary like this:

/Font <<
  /Type /Font
  /Subtype /TrueType
  /BaseFont /Helvetica-Bold
>>

Notice what is missing: the actual font outline program (the Bézier curves defining the letters) is not stored inside the document. The PDF merely tells the viewing engine: "Find Helvetica-Bold on the host operating system and draw it."

If that document is opened in the year 2045 on an operating system that lacks Helvetica, the viewer falls back to a substitute font (such as Arial or a generic sans-serif). Because the letter widths, kerning pairs, and x-heights of the substitute font do not match the original typography, text overflows margins, tables become misaligned, lines wrap unexpectedly, and legal paragraph references shift to wrong pages. In legal and regulatory settings, this visual deviation can compromise an entire contract.

2. Deconstructing the ISO 19005 Family: PDF/A-1, A-2, A-3, and A-4

The PDF/A standard has evolved across four distinct releases, each balancing historical permanence with modern document capabilities:

3. Conformance Levels Explained: 1b vs. 1a vs. 2u

Within each standard, documents achieve different conformance tiers designated by lowercase letters:

• Level B (Basic Visual Integrity - e.g., PDF/A-1b, PDF/A-2b): The minimum threshold. Guarantees that the visual rendering of the document will look identical on any device at any future date. Does not mandate semantic text tagging.
• Level U (Unicode Support - e.g., PDF/A-2u): Inherits Level B requirements and mandates that all character glyphs possess valid Unicode mappings (via /ToUnicode tables), ensuring text can always be copied, pasted, and searched by search indexers.
• Level A (Accessible / Structural Tagging - e.g., PDF/A-1a, PDF/A-2a): The highest compliance tier. Mandates complete structural hierarchy (Tagged PDF) with logical reading order, heading levels (/H1, /H2), paragraph tags (/P), and alternative text descriptions for images (/Alt) for screen readers.

4. Forbidden Features Matrix: JavaScript, Audio, and External Dependencies

To guarantee complete self-containment, ISO 19005 strictly outlaws any feature that introduces non-deterministic behavior or external software dependencies:

5. Font Embedding Mandates: CIDFonts, Glyphs, and ToUnicode CMaps

The single most common reason PDFs fail archival validation is font non-compliance. In ISO 19005:

1. 100% Glyph Embedding: Every character rendered in the document must have its corresponding outline program stored in the PDF binary payload (either as a TrueType stream or a CFF / Type 1C font file). Subsetting is permitted, but every used glyph ID must exist.
2. Unicode Mapping Requirement: Even if a custom symbol or decorative glyph renders visually, the PDF must include a /ToUnicode CMap dictionary. This lookup table translates internal glyph IDs (such as character code 0x0024) into standard UTF-16 Unicode code points, preventing "gibberish" extraction when copying text.

6. OutputIntents & Device-Independent Color Science

In standard printing, an RGB color like rgb(220, 40, 40) produces wildly varying shades depending on whether it is viewed on an sRGB monitor, a mobile display, or printed on uncoated newsprint. PDF/A eliminates this ambiguity through the mandatory use of an OutputIntent dictionary.

Every PDF/A file must declare an /OutputIntent in its document catalog containing an embedded standardized ICC profile (such as sRGB IEC61966-2.1 for screens or FOGRA39 / GRACoL 2006 for commercial print). This ensures that any rendering engine knows the precise, mathematically objective color space intended by the author.

7. The XMP Metadata Schema: Structuring Archival Provenance

Legacy PDFs stored metadata in simple ASCII info dictionaries (e.g., /Title, /Author, /CreationDate). PDF/A mandates that all metadata must also be encoded as an extensible, schema-validated XMP (Extensible Metadata Platform) XML stream:

<x:xmpmeta xmlns:x="adobe:ns:meta/">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
        xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/"
        xmlns:pdfaProperty="http://www.aiim.org/pdfa/ns/property#"
        xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
      <pdfaid:part>2</pdfaid:part>
      <pdfaid:conformance>B</pdfaid:conformance>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>

The pdfaid:part and pdfaid:conformance tags explicitly announce the document's compliance claims to automated ingestion bots used by national libraries and judicial courts.

8. Pre-Flight Verification: Automated Toolchains & veraPDF Auditing

Before submitting documents to government portals, enterprise records repositories, or European e-Invoicing networks, developers and legal operators should run automated pre-flight checks using open-source reference validators such as veraPDF (the official industry validation software supported by the PDF Association):

# Run automated veraPDF preflight compliance audit in terminal
verapdf --flavour 2b --format text document-audit-package.pdf

When creating or restructuring documents locally inside VersaPDF Studio, our client-side WebAssembly engine strips dynamic script actions, normalizes embedded color spaces, and cleans metadata streams, ensuring your exported files provide maximal long-term archival reliability without depending on proprietary remote servers.