Conference September 2006 📍 San Jose, California, USA

PDF Days North America 2006 — San Jose: PDF/A-1 Published, Government Adoption Begins

PDF Days North America 2006 took place shortly after the October 2005 publication of ISO 19005-1 (PDF/A-1). North American attendees were largely government and legal records professionals confronting real questions about PDF/A-1a vs -1b conformance, font embedding at scale, and what the new standard meant for federal records management under NARA guidance.

Official event page →

Key takeaways

PDF/A-1 had just been published (October 2005) — 2006 was the first year of real implementation
Font embedding was the dominant technical barrier for legacy document archive conversion
NARA evaluating PDF/A for federal records transfer guidance — policy was ahead of operational capability
PDF/A-1b was the realistic target; PDF/A-1a was aspirational for most organisations in 2006
No native PDF/A export in Acrobat until version 8 (November 2006, just after the conference)
Open-source validation tooling gap — no free PDF/A validator available in 2006

PDF Days North America 2006 in San Jose took place just months after the October 2005 publication of ISO 19005-1 (PDF/A-1) — the first PDF International Standard. For attendees who had followed the standard's development through years of AIIM committee work, the publication was both a milestone and a starting gun: now the hard work of actual implementation began. The 2006 conference drew a largely North American audience of government records managers, IT professionals, and PDF software vendors who were all confronting the same question: what does PDF/A-1 compliance actually mean in practice, for real document inventories, with real operational constraints?

PDF/A-1 just published: first implementation questions

PDF/A-1 had been published in October 2005 — less than a year before the 2006 conference. Attendees were not discussing the standard in the abstract; they were discussing what happened when they actually tried to implement it: Font embedding at scale — The single most discussed issue was font embedding. Organizations had been producing PDFs for a decade without mandatory font embedding. Millions of archived documents used unembedded system fonts. The process of batch-converting these archives to PDF/A-1 compliance required either re-generating documents from source (often impossible for legacy documents) or using PDF post-processing tools to embed fonts retroactively — a technically complex operation that often produced imperfect results. PDF/A-1a vs PDF/A-1b decision — The two conformance levels presented a practical choice: PDF/A-1b (visual reproduction) was achievable for many existing documents; PDF/A-1a (full accessibility with structure tags) required either authoring-time tagging or expensive post-processing remediation. Most organisations at the 2006 conference were planning to target PDF/A-1b for legacy conversion and PDF/A-1a only for new documents created with compliant tools. Output intent requirements — For colour documents, PDF/A-1 required an embedded output intent ICC profile defining the colour space. Most word-processed documents and simple office PDFs used device-dependent RGB without ICC profiles. Adding output intent retroactively was possible (sRGB was an acceptable profile for screen-optimised documents) but added to the complexity of bulk conversion.

NARA and federal records management

The North America conference had strong representation from the federal records management community, reflecting the US government's leading role in PDF/A adoption: NARA PDF/A evaluation — NARA had been tracking PDF/A since the standard was in development. By 2006, NARA's archivists were evaluating whether PDF/A should be included in NARA's Transfer Guidance for electronic records. The principal concern: NARA needed to ensure that records transferred by federal agencies would be usable indefinitely — PDF/A-1's font embedding, colour management, and prohibition on external dependencies directly addressed this concern. Agency readiness gap — The 2006 conference revealed a significant gap between policy intent and operational readiness. Federal agencies had legal obligations to preserve records (Federal Records Act, NARA regulations) but lacked the IT infrastructure, workflow changes, and staff training to systematically produce PDF/A-1 compliant documents. The conference addressed what realistic adoption timelines looked like. Procurement implications — Several attendees raised the question of whether federal agencies could mandate PDF/A in procurement specifications for document management systems and document scanning services. ISO 19005-1 having been published made this legally more feasible, but practical implementation specifications were not yet standardised.

Early production tools and validator landscape

Adobe Acrobat Professional 7 — The primary tool available for PDF/A creation in 2006 was Adobe Acrobat Professional 7 (released January 2005), which had no native PDF/A export mode. Users needed to configure print settings manually or use Acrobat Distiller with carefully tuned PostScript settings to approach PDF/A compliance. Acrobat 8 (November 2006) added native PDF/A-1b export support — appearing just after the 2006 conference. pdfaPilot — callas software's pdfaPilot was one of the first commercial tools specifically designed for PDF/A creation and validation. It provided command-line and Acrobat plug-in interfaces for batch conversion and validation. Several conference attendees were evaluating it for production workflows. Open-source tooling gaps — There were no mature open-source PDF/A validators in 2006. Ghostscript could produce PDFs but had no PDF/A-specific compliance features. This gap meant organisations either purchased commercial tools or attempted to implement PDF/A compliance by configuration alone, without systematic validation. The first validation test — The PDF/A Competence Center (forerunner of the PDF Association) had begun work on PDF/A test suite development in 2006 — the foundation for what would later become the Isartor test suite and eventually contribute to veraPDF's development. Having a conformance test suite for validators was essential for ensuring that "PDF/A-1 compliant" actually meant the same thing across different tools.

Frequently asked questions

What is the difference between PDF/A-1a and PDF/A-1b?

PDF/A-1b (basic) requires that the document can be consistently visually reproduced: all fonts must be embedded, colour spaces must use device-independent colour or have an output intent, encryption and external dependencies are prohibited. A PDF/A-1b document looks the same on any compliant viewer, indefinitely. PDF/A-1a (accessible) requires everything that PDF/A-1b requires, plus: the document must be fully tagged with a logical structure tree (reading order, heading hierarchy, figure descriptions, table structure); all characters must have Unicode representations available (ToUnicode CMaps); and natural language must be declared. PDF/A-1a enables text extraction, screen reader accessibility, and reflow. In practice, PDF/A-1a requires authoring-time effort or extensive post-processing remediation — most legacy conversion workflows targeted PDF/A-1b as the achievable baseline.

Can PDF/A-1 documents include digital signatures?

Yes, with restrictions. PDF/A-1 allows digital signatures but prohibits certification signatures (which use the /DocMDP mechanism to restrict document modifications). Approval signatures (which attest to document content without restricting further modifications) are permitted. The signature must comply with all other PDF/A-1 requirements: fonts in the signature appearance must be embedded, the signature appearance must not use prohibited features. PDF/A-1 also prohibits encryption — but digital signatures do not encrypt the document, so they are compatible. The practical implication: digitally signing a PDF/A-1 document via an incremental update is the standard approach, preserving the original PDF/A-1 body and adding the signature as a conforming incremental update.

Why did government agencies lead PDF/A adoption rather than private sector organisations?

Government agencies were the primary PDF/A early adopters for several interconnected reasons. First, government records are subject to legal retention obligations — records managers needed a format they could legally defend as appropriate for long-term archival under NARA guidance and Federal Records Act requirements. Second, government procurement policies favour ISO standards — ISO 19005-1 gave procurement officers a formal standard to reference. Third, government document volumes justified the investment in workflow changes — agencies producing millions of documents annually had a strong cost-benefit case for standardised processing. Fourth, government agencies faced specific accessibility obligations (Section 508) that aligned with PDF/A-1a requirements. Private sector PDF/A adoption came later and has generally been driven by regulated industries (finance, healthcare, legal) with similar records retention requirements.

Try it in your browser

The PDF tools and standards discussed at this event are available free — no account needed.

Edit PDF Protect PDF Sign PDF Open editor