1. ISO Standard Development
Portable Document Format Archive (PDF/A)
ISO Standard Development
Overview of the Draft PDF/A Standard
May 11, 2004

2. Introduction
Today’s presentation will provide an archival/records management perspective on the Draft PDF/A Standard (PDF/A):
Background of PDF/A
Why and how PDF/A was initiated, and its status in the ISO process
What is covered in PDF/A
The approach used in developing PDF/A
An overview of each clause of PDF/A (as currently drafted)
What is specified and why
Examples of topics covered and their use in PDF/A
What NARA’s expectations are for PDF/A
Where you can get more information on NARA and PDF/A

3. NARA’s Involvement in PDF/A
U.S. National Archives and Records Administration (NARA) is actively participating in PDF/A development with the following goals:
To influence the process so that PDF/A compliant records can be preserved by NARA over the long term, and
To provide information used in developing NARA guidance for transferring future permanent records in PDF.
Current NARA transfer guidance for records in PDF issued March 31, 2003
nce/nwm11_2003.html

4. PDF/A Background – Wide Use of PDF
PDF is a digital format that electronically reproduces the visual appearance of documents whether they are:
Created natively in PDF,
Converted from other electronic formats, or
Digitized from paper or microform
Businesses, governments, libraries, archives, and other institutions and individuals around the world use PDF to:
Collect and disseminate information over the Internet,
Store electronic records, and/or
Make scanned images searchable by embedding OCR’d text.
As a result, large bodies of important information are maintained in PDF.
PDF is a digital format for representing documents, whether they are created natively in PDF, converted from other electronic formats, or digitised from paper or microform.
Businesses, governments, libraries, archives, and other institutions and individuals around the world use PDF to represent considerable bodies of important information. Much of this information must be kept for substantial lengths of time; some must be kept permanently.
These PDF documents must remain usable and accessible across multiple generations of technology.
The future use of and access to these documents depends on maintaining the ability to reproduce their visual appearance as well as their higher-order properties, such as their logical organization of pages, clauses, and paragraphs; machine recoverable text stream in natural reading order; and a variety of administrative, preservation, and descriptive

5. PDF/A Background – PDF Not a Suitable Archival Format
PDF itself is not suitable as an archival format.
Adobe is under no obligation to continue publishing the specification for future versions.
Can include features incompatible with current archival requirements
Encryption
Embedded files
PDF documents not necessarily self-contained
Can depend on system fonts and other content drawn from outside the file
Multiple PDF development tools on the market
Inconsistency in the file format (all PDFs are not created equal)
Long-term solution needed to ensure that digital PDF documents remain accessible for long periods of time
Permanent archival records, in some cases

6. PDF/A Background – Example Business Case for PDF/A
Administrative Office of the U.S. Courts (AOUSC)
Uses PDF as the electronic format for Electronic Case Filing System
Business need for court documents to maintain their “visual appearance” (i.e., pagination, layout)
System accepts filings and provides access to filed PDF documents over the Internet
Electronic court documents are submitted in PDF
Hard copy submissions are scanned to PDF
Many AOUSC files must be maintained for long periods of time (i.e., 40 years)
Some will be transferred to the National Archives for permanent retention
Future use of and access to the AOUSC’s PDF documents depends on maintaining the ability to reproduce their visual appearance and other properties over the long term (i.e., across multiple generations of technology).
The future use of and access to the U.S. Court’s PDF documents depended on maintaining the ability to reproduce their visual appearance as well as their higher-order properties, such as:
their logical organization of pages, Clauses, and paragraphs;
machine recoverable text stream in natural reading order;
and a variety of administrative, preservation, and descriptive metadata.

7. PDF/A Background – Addressing the Long-term Use of PDF
AOUSC collaborated with other the U.S. government agencies, libraries, academia, private industry (e.g., imaging product vendors, drug companies, consultants), Adobe, and other PDF vendors.
Formed a U.S. Committee to initiate an ISO Standard to:
Ensure preservation of PDF documents over extended periods of time, and
Further ensure that PDF documents would be rendered with consistent and predictable results in the future.
U.S. Committee working under two Standards Organizations
AIIM International (the Association for Information and Image Management, International)
NPES (The Association for Suppliers of Printing, Publishing and Converting Technologies)
To address the need to preserve PDF records over the long-term, The U.S. Courts worked with Adobe and two Standards organizations.
contacted representatives from government agencies, libraries, academia, private industry and PDF software developers to determine their interest in developing an archival standard for PDF
conducted meetings to determine the best method of developing a standard to specify the archival use of PDF.
This joint committee, comprised of government and industry, began to explore ways:
to ensure preservation of PDF documents over extended periods of time,
and further ensure that PDF documents would be rendered with consistent and predictable results in the future.
ThePDF/A effort evolved into a joint committee formed under AIIM International (the Association for Information and Image Management, International) and NPES (The Association for Suppliers of Printing, Publishing and Converting Technologies).

8. PDF/A ISO Process – International Joint Working Group
ISO Joint Working Group (JWG) - PDF/A
TC/46
Archives/
Records Mgmt
TC/171*
Document Imaging
Applications
TC/130
Graphics
Technology
TC/42
Photography
TC/46 SC11
Archives/
Records Mgmt
TC/171 SC 2
Application
Issues
NPES and AIIM recommended that ISO Joint Working Group be formed under the lead of ISO TC 171 SC2. The JWG consists of representation from ISO TC 130 (Graphic technology), ISO TC 171 (Document Imaging Applications) and ISO TC 46 (Information and documentation) ISO TC 42 (Photography).
The first meeting of the JWG will be held during the week of October 20 in conjunction with the ISO TC 171meetings in New Orleans. Meetings of the U.S. group will continue to be held between the ISO meetings to provide input.
The U.S. Group of Experts is working under the American National Standards Institute Technical Advisory Group (TAG)
The role of the JWG is to coordinate in liaison with each other to reach consensus on the technical content of the of PDF/A standard. This work continues until all technical issues are resolved and the draft is accepted for circulation for the next stage of the process
TC/171 SC 2 WG-5
PDF/A
PDF/A JWG
* JWG formed under the auspices of TC/171

9. PDF/A ISO Process – Progress and Next Steps
Early 2002 PDF/A development initiated
September 2003 Approval of ISO New Work Item (NWI)
October 2003 TC-171 Meeting - JWG prepared Committee Draft (CD)
November CD ballot circulated to National Bodies (NBs)
February CD ballot closed
March JWG reviewed NB comments on CD
June Second CD ballot to be circulated to NBs
September Second CD ballot closes
October Next JWG Meeting
Spring 2005? - Draft International Standard
Winter 2005? - International Standard
In early to mid 2002, this committee defined the business and technical requirements and studied possible solutions making the PDF format suitable for long-term preservation.
In late 2002, the group determined that the solution was to use a restricted subset of the PDF specification.
This solution was similar to the standard developed in the printing and publishing industry, known as PDF/X (ISO 15930). As a result, the project became known as PDF Archive (PDF/A).
In mid 2002, the group agreed that the standard would need to specify both a file format and define the behavior of retrieval devices such as readers and viewers. These would need to be compatible with both electronic documents and scanned images in PDF
To accomplish this, they identified clauses of the draft standard formed subcommittees to develop each of these clauses
Using Listserves and by meeting about every three months, the committee developed developed, reviewed and discussed each clause of the draft standard
In early 2003, the draft standard was drafted and circulated with the New WorkItem (NWI) ballot to move this work into ISO under TC- 171, Document Imaging Applications.
In early September PDF/A was accepted into ISO as a New Work Item
As a result, the latest version has been sent to the ISO Joint Working Group as a Working Draft.

10. National Bodies Voting/Providing Comments on PDF/A CD
Australia
France
Germany
Japan
United Kingdom
United States
Sweden

11. PDF/A Approach PDF/A specifies: PDF 1.4 Reference PDF/A
The subset of PDF components, from the Adobe published specification for Version 1.4 (i.e., PDF 1.4 Reference), that are either mandatory, recommended, or prohibited, and
How these components may be used by software to render the file.
Adobe Systems, Inc., makes the PDF specification publicly available. As mentioned before, the inclusive, feature-rich nature of the format requires that additional constraints be placed on its use to make it suitable for the long-term preservation of electronic documents.
The base-line criterion for PDF/A conformance is adherence to Version 1.4 of the PDF Reference. A conforming PDF/A document may include any valid PDF 1.4 feature that is not explicitly forbidden by this standard.
PDF/A
PDF 1.4 Reference
Specifies required features
Specifies constrained features
Specifies prohibited features

12. Preservation Criteria for PDF/A Requirements
PDF/A attempts to maximize:
Device independence
The degree to which a PDF/A file is independent of the platform on which it is interpreted and rendered
The degree to which a PDF/A file is amenable to direct analysis with basic tools, including human readability
Self-containment
The degree to which a PDF/A file contains all resources necessary for its reliable and predictable interpretation and rendering
Self-documentation
The degree to which a PDF/A file documents itself in terms of descriptive, administrative, structural, and technical metadata

13. PDF/A Introduction
Explains PDF/A background and approach, and further explains that:
PDF/A should be used as one component of an organization’s electronic archival environment. Implementation depends on:
Records management policies and procedures and any additional requirements and conditions necessary to ensure the persistence of electronic documents over time
Quality assurance processes necessary to very conformance with requirements
Examples of other topics addressed in the Introduction include:
Use of “Part 1” in title
Intellectual property rights
Location of application notes

14. Structure of the Draft PDF/A Standard
1 Scope
2 Normative References
3 Terms and Definitions
4 Notation
5 Conformance Levels and Identification
6 Technical Requirements
6.1 File Structure
6.2 Graphics
6.3 Fonts
6.4 Transparency
6.5 Annotations
6.6 Actions
6.7 Metadata
6.8 Logical Structure
6.9 Forms
Informative annexes
Annex A - Summary of Prohibited PDF Features
Annex B - Best Practices for PDF/A
Bibliography

15. Clause 1 of the Draft PDF/A Standard – Scope
“This International Standard specifies the use of the Portable Document Format (PDF) 1.4 for the long-term preservation of electronic documents.” (Clause 1, PDF/A Scope)
This International Standard should lead to development of various applications, such as products that read, render, write, and validate compliant PDF/A documents. Different products will incorporate various capabilities to prepare, interpret, and process conforming PDF/A documents based on the application needs as perceived by the suppliers of those products. However, it is important to note that a conforming application must be able to read and appropriately process all files complying with a specified conformance level.

16. Clause 1 of the Draft PDF/A Standard – Scope
“It is applicable to documents containing combinations of character, raster, and vector data.”
Raster images
Vector graphics
Character text
PDF/A focuses on document based electronic information.
Text-based documents that also contain photographic images and graphics.
Vector graphics - created by mathmatical algorithms
Raster Images - colored pixels
Text that is represented by characters (fonts)

17. Clause 1 of the Draft PDF/A Standard – Scope
“PDF/A does not apply to:
“Converting paper or electronic documents to the PDF/A format
Specific technical design, user interface, implementation, or operational details of rendering
Specific physical methods of storing these documents such as the media and storage conditions
Required computer hardware and operating systems”
Although computer hardware, storage, and software operating systems are evolving as rapidly as are individual file formats. The PDF/A standard does not address specific physical methods of storage
PDF/A

18. Clause 2 of the PDF/A Standard – Normative References
The Normative Reference clause lists documents which, through reference in PDF/A, constitute provisions of PDF/A.
Examples of normative references include:
Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 2000
ICC.1: , File Format for Color Profiles, International Color Consortium
ISO/IEC , Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane
PDF Reference: Adobe Portable Document Format, Version 1.4, Adobe Systems Incorporated – 3rd ed. (ISBN )
XMP Specification, January 2004, Adobe Systems Incorporated
The following normative documents contain provisions which, through reference in this text, constitute provisions of this International Standard.
For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain registers of currently valid International

19. Clause 3 of the PDF/A Standard – Terms and Definitions
Lists Terms and Definitions as they apply to PDF/A
Examples of terms defined in this clause include:
Electronic document - electronic representation of a page-oriented aggregation of text and graphic data, and metadata useful to identify, understand, and render that data, that can be reproduced on paper or optical microform without significant loss of its information content
Interactive reader- reader that requires or allows human interaction during the software's processing phase
Long-term - period of time long enough for there to be concern about the impacts of changing technologies, including support for new media and data formats, and of a changing user community, on the information being held in a repository, which may extend into the indefinite future [ISO 14721]
Writer- software application that is able to write files [ISO ]

20. Clause 4 of the Draft PDF/A Standard - Notation
The Notations clause explains conventions used for identifying PDF specific elements in PDF/A.
Examples of topics specified in this clause include:
Notation for PDF operator names, PDF keywords, the names of keys in PDF dictionaries, and other predefined names
Notation for operator values or values of dictionary keys
Identification of individual characters (e.g., CARRIAGE RETURN (U+000D)).
References to the "PDF Reference"

21. Clause 5 of the Draft PDF/A Standard – Conformance
The Conformance clause specifies two levels of conformance for PDF files to allow the exclusion of requirements that could be burdensome.
Full conformance - meeting all requirements
Minimal conformance - meeting requirements minimally necessary to ensure predictable and reliable rendering
Examples of topics specified in this clause:
Full conformance (Meets all requirements of PDF Reference, as modified by PDF/A)
Minimal conformance - Excludes requirements for:
Unicode character mapping
Logical Structure (Tagged PDF)
The requirements for full conformance place greater burdens on PDF/A writers but these requirements allow for a higher level of document preservation service and confidence over time
Tagged PDF defines conventions for explicitly declaring and describing the logical structural aspects of document content.
Additionally, full conformance facilitates the accessibility of PDF/A documents for physically impaired users.
The minimal conformance requirements are intended to ensure that the rendered visual appearance of a PDF/A document is preservable over the long-term,
But minimally conforming files might not have sufficiently rich internal information to allow for the preservation of the document's logical structure and content text stream in natural reading order, which is provided by full conformance.

22. Clause 6.1 of the Draft PDF/A Standard – File Structure
The File Format clause specifies attributes of the PDF format to produce uniform PDF/A files.
Examples of topics specified in this clause and their use:
Mandatory
Header begins at byte offset 0
Header followed by comment with at least four bytes < 127
Conform to limits on quantities defined in Table C.1 of PDF Reference
Recommended
Reader: ignore any linearization information
Prohibited
Encryption
Embedded files
External content
Optional content (i.e., OC Properties)
Header - No data shall precede the file header
Header - The presence of character byte values greater than 127 near the beginning of a file is used by various software tools and protocols to classify the file as containing arbitrary binary data that should be preserved during processing.
Encrypt - The explicit prohibition of the Encrypt keyword has the implicit effect of disallowing encryption and password-protected access permissions.
OC Properties - This key is used in PDF 1.5 for the use of optional content that generates alternative renderings of a document.

23. Clause 6.2 of the Draft PDF/A Standard - Graphics
The Graphics clause specifies attributes of the PDF format to ensure that all the information needed to appropriately render graphics is contained within the file.
Examples of topics specified in this clause and their use:
Mandatory
Device independent color space (either directly or by Output Intent)
Recommended
For color-critical applications, follow additional requirements of PDF/X-3
Prohibited
Form XObjects
Reference XObjects
PostScript XObjects
Content stream operators not documented in PDF 1.4
This clause describes restrictions placed on both PDF files that comply with the specification (compliant files) and applications that render such files (compliant readers). It is intended to address graphical rendering issues that do not involve fonts and interactive elements.
FormX, ReferenceX, PostscriptX are device dependent.

24. Clause 6.3 of the Draft PDF/A Standard - Fonts
The Fonts clause specifies attributes of PDF to ensure that future rendering of the textual content of a PDF file matches the static appearance as originally created.
Examples of topics specified in this clause and their use:
Mandatory
Embed all referenced fonts
Reader: only use embedded fonts
Map to Unicode (only necessary for full conformance)
Recommended
Font subsets
Prohibited
Fonts not legally embeddable for unlimited, universal rendering
The intent of the requirements is to ensure that future rendering of the textual content of a PDF/A file matches the static appearance of the file as originally created, on a glyph by glyph basis and to allow the recovery of semantic properties for each character of the textual content.
Self-contained, does not need to rely on the fonts residing on the computers of the future.
All PDF/A conforming readers shall use the embedded fonts, rather than other locally resident, substituted, or simulated fonts, for rendering.
It is the responsibility of the file writer to ensure the conformance of all fonts. PDF/A does not prescribe the manner in which conformance is determined.
The use of font subsets allows a potentially substantial reduction in the size of PDF/A files.
Only fonts that are legally embeddable in a file for unlimited, universal rendering shall be used

25. Clause 6.4 of the Draft PDF/A Standard - Transparency
The Transparency clause explicitly prohibits the use of transparency within the PDF/A format for overlapping or three dimensional graphics.
Examples of topics specified in this clause and their use:
Mandatory
Not applicable
Recommended
Alternatives for displaying “transparent” graphics (e.g., flattened vector objects)
Prohibited
Transparency Keys
An ExtGState dictionary shall not contain any of the following: the SMask key; the CA key with a value other than 1.0; the ca key with a value other than 1.0; or the BM key with a value other than Normal or Compatible. If present in an ExtGState object, the BM shall have a value of Normal or Compatible; the CA key shall have a value of 1.0; and the ca key shall have a value of 1.0.
An Image XObject dictionary shall not contain the SMask key.
The SMask key shall not be used in an ExtGState object or in an Image XObject with any value other than None.
A Group object shall not be included in a Form XObject if it includes an S key with a value of Transparency.
NOTE: These provisions prohibit the use of transparency within the file. The visual effect of partially transparent graphics may be achieved using techniques other than the use of the PDF 1.4 transparency keys, including pre-rendered data or flattened vector objects. The use of such techniques does not prevent a file from being PDF/A compliant.

26. Clause 6.5 of the Draft PDF/A Standard - Annotations
The Annotations clause specifies the use of annotations to ensure that:
The visual presentation of the actual page is rendered exactly as the author intended, and
Hidden content is available for viewing.
Examples of topics specified in this clause and their use:
In addition to the rendering behaviour defined by the PDF Reference, as modified by PDF/A, conforming PDF/A interactive readers shall provide a mechanism to display the values of the Contents key of annotation dictionaries.
NOTE PDF/A does not prescribe the specific behaviour or technical implementation details that interactive readers may use to implement this functional requirement.
Support for multimedia content is outside the scope of PDF/A
Annotations that are hidden or that are viewable but not printable are restricted.
Annotations that rely on external content or software are prohibited
Annotations not defined in the PDF Reference not allowed. Not predictable for standardization of PDF.
Mandatory
Reader Behavior
Must display the actual contents of all annotations in human-readable form
Recommended
Not Applicable
Prohibited
Hidden Annotations
File Attachments
Sound Annotations
Movie Annotations
Annotations not defined in the PDF Reference

27. Clause 6.6 of the Draft PDF/A Standard - Actions
The Actions clause specifies attributes of PDF to ensure that PDF/A files are self-contained and do not rely on external sources for content.
Examples of topics specified in this clause and their use:
Mandatory
Reader behavior
Interactive readers must display destination of links (address)
Recommended
Reader Behavior
Not required to act on links, but may
Security risk
Prohibited
Actions external to the document
Launch
Sound
Movie
ResetForm
ImportData
JavaScript
Since hyperlinks transfer the thread of execution outside the control of a reader, this clause allows a reader to choose to make them not actionable. For purposes of archival disclosure of the complete information content of PDF/A documents it is important for interactive readers to provide some mechanism to expose the destination of all hyperlinks. However, PDF/A does not prescribe any specific behaviour or the technical implementation details that interactive readers might use to meet the functional requirement of this clause.
interactive reader - reader that requires or allows human interaction during the software's processing phase.. A pre-flight tool is an example of an interactive reader;
a raster image processor is an example of a reader that is not interactive.

28. Clause 6.7 of the Draft PDF/A Standard – Metadata
The Metadata clause specifies the use of the Adobe eXtensible Metadata Platform (XMP) for embedding metadata within PDF/A files.
Outlines a structured, consistent process to support a broad variety of metadata requirements.
Examples of topics specified in this clause and their use:
This Clause specifies requirements for metadata within PDF/A files. Metadata is essential for effective management of a file throughout its life cycle.
A file depends on metadata for identification and description, as well as for documenting appropriate technical and administrative matters.
As a result, PDF/A file writers may have to comply with various domain-specific metadata requirements defined external to PDF/A.
PDF/A outlines a structured, consistent process that supports a broad variety of metadata requirements.
XMP Stream - Since XMP metadata streams are unfiltered, their contents are visible as plain text to non-PDF/A aware tools.
DID - To ensure that metadata appearing in two areas of the file match. DID is required in PDF/X and there is a need for PDF/X files to also be PDF/A compliant.
Extension schemas must be embedded. Facilitates interchange and supports consistent depiction of metadata by conforming PDF/A interactive readers.
File identifies itself as PDF/A and gives the conformance level
File Identifiers, provenance - open and flexible (best practices)
Font metadata - licensing information
Mandatory
XMP stream defined by catalog Metadata key
Info dictionary entries must have equivalent XMP properties
Embed any extension schemas
PDF/A version and conformance level
Recommended
File Provenance
File Identifiers
Font Metadata
Prohibited
Deprecated bytes attribute in XMP packet header

29. Clause 6.8 of the Draft PDF/A Standard – Logical Structure
The Logical Structure clause applies only to fully conforming PDF/A files and specifies the use of Tagged PDF to ensure:
The recovery of a PDF file’s textual content,
The recovery of individual characters that make up each word, and
The recovery of information about the logical structure of the document.
Examples of topics specified in this clause and their use:
This Clause is applicable only for full compliance with this standard. For minimal compliance the requirements of this Clause can be ignored.
Tagged PDF defines conventions for explicitly declaring and describing the logical structural aspects of document content.
The intent of the requirements stated in this Clause is to insure the recovery of a PDF file’s textual content as a sequence of words defined in the natural reading order of the language in which they are written.
Similarly, the individual characters of each word must be recoverable in their natural reading order.
Furthermore, these requirements allow the recovery of higher-level semantic information concerning the logical structure of the document.
Mandatory
Tagged PDF (meets all requirements in Clause 9.7 of the PDF Reference)
Explicit white space to indicate word breaks (if appropriate for language)
Default language
Recommended
Pagination, layout, and page artifacts
Structural hierarchy
Language
Alternate descriptions
Replacement text
Expansion of abbreviations and acronyms
Prohibited
No current prohibitions

30. Clause 6.9 of the Draft PDF/A Standard - Forms
The Forms clause specifies attributes of PDF to ensure that:
There is no ambiguity about the rendering of form fields
The rendered representation of the page or the content of the document is not changed at any time, and
Form fields do not perform actions of any type.
Examples of topics specified in this clause and their use:
The intent of the requirements of this Clause is to insure that there is no ambiguity about the rendering of form fields.
A conforming PDF/A reader shall not use form fields to change the rendered representation of the page or the content of the document at any time. Form fields shall not perform actions of any type.
The NeedAppearances flag of the interactive form dictionary either shall not be present or shall be false.
Every form field shall have an appearance dictionary associated with the field's data.
A conforming PDF/A reader shall render the field according to the appearance dictionary without regard to the form data. A conforming PDF/A reader shall not implement any feature that would allow the document appearance to change.
Mandatory
Appearance dictionary (required for each form field containing data)
Reader Behavior (render the field according to the appearance dictionary without regard to the form data)
Recommended
No current recommendations
Prohibited
Any feature that would allow the document’s appearance to change

31. Annexes of the Draft PDF/A Standard – Informative Annexes
Informative Annexes will be included in the Draft PDF/A Standard to provide supplemental information including:
Summary of Prohibited PDF Features
Best Practices for PDF/A
Recommended software requirements for capturing or converting electronic documents to PDF/A
For documents created according to specific institutional rules
Replicates the exact quality and content of source documents within the PDF/A file
to ensure that resulting PDF/A documents retain their quality and integrity as records.
ISO , 7.1, specifies that “to support the continuing conduct of business, comply with the regulatory environment, and provide necessary accountability, organizations should create and maintain authentic, reliable and useable records, and protect the integrity of those records for as long as required” [8].
The regulatory environment document quality rules such as minimum image resolution, compression restrictions, or prohibited processes that either alter or dispose of approved data. For archival preservation purposes, the quality and integrity of documents should be retained when they are captured or converted to PDF/A.
To meet this critical archival need, PDF/A capture or conversion processes should replicate the exact content and quality of the source document within the PDF/A file. Following are examples of specific software requirements that accomplish this:
¾ PDF/A writers should not use lossy compression, subsampling, downsampling, or any other process that either alters the content or degrades the quality of source data in the PDF/A document
¾ Software should not substitute searchable text, based on optical character recognition, for the original scanned text within the bit-mapped image of documents that are scanned to PDF/A from paper or converted to PDF/A from image formats
NOTE Optical character recognition processes may involve loss of data through imprecise interpretation of scanned characters.

32. Summary - PDF Background
PDF reproduces the visual appearance of electronic documents and is widely used to represent large bodies of important information, some of which must be maintained for long periods of time.
PDF, itself, is not a suitable archival format.
Long-term solution is needed to ensure that PDF documents can remain accessible over long periods of time (e.g. multiple generations of technology).
Draft PDF/A Standard initiated by AOUSC in collaboration with U.S. government agencies, libraries, academia, private industry.
PDF/A has been circulated as a Committee Draft and will be circulated again as a Committee Draft
Technical changes and additions

33. Summary - PDF/A Overview
Goals - to ensure preservation of PDF documents over extended periods of time, and further ensure that PDF documents will be rendered with consistent and predictable results in the future.
Approach
PDF/A identifies the subset of PDF components from the PDF 1.4 Reference that are either mandatory, recommended, or prohibited, and how these components may be used by software to render the file.

34. Summary - PDF/A Requirements
Two levels of conformance
Full
Minimal (e.g. No Tagged PDF, UNICODE Mapping)
Uniform file format (header, trailer, no encryption)
Device-independent rendering of graphics
Embedded fonts, character encoding
Transparency prohibited
Annotations restricted, content should be displayed by readers
External actions restricted, no dependence on external content
Readers not required to act on hyperlinks, but may
XMP metadata “Adobe XML Metadata Framework”
Forms based on appearance, not data

35. Conclusion NARA’s expectation for PDF/A
Should address some existing archival issues with PDF and enable records in PDF to be maintained for longer periods of time in that format
Standard maintained by external International organization, not just vendors
Increased degree of format reliability
Enhanced future migration capabilities (embedded XMP metadata)

36. More Information is Available
PDF/A standard is projected to be issued as an ISO Standard in 2004
More information on PDF/A on AIIM Web Site
Information about the U.S. National Archives and Records Administration
Contact Susan Sullivan at

37. Questions/Discussion