Greetings:
Warning: Long post.
The following is re-posted from the comp.text.sgml newsgroup. I may
be missing something, but it looks to me as if our concerns about
accessibility of federal documents in the Adobe PDF format have fallen on
deaf ears.
Lloyd Rasmussen, Senior Staff Engineer
National Library Service, Library of Congress
202-707-0535 lras@loc.gov
Article 7874 of comp.text.sgml:
Path: rs7.loc.gov!darwin.sura.net!mojo.eng.umd.edu!bloom-beacon.mit.edu!gatech!swrinde!pipex!sunic!trane.uninett.no!nntp.uio.no!ifi.uio.no!gyda.ifi.uio.no!enag
From: Erik Naggum <erik@naggum.no>
Newsgroups: comp.text.sgml
Subject: Re: Proposed PDF FIPS report
Date: 26 Feb 1995 23:40:01 UT
Organization: Naggum Software; +47 2295 0313
Lines: 455
Message-ID: <19950226T234002Z.enag@naggum.no>
References: <entrpoop.793664966@access3>
NNTP-Posting-Host: gyda.ifi.uio.no
[Dexter Medley]
| In case it is of interest to anyone in this group, here is the uuencoded
| Adobe PDF formatted draft report of the committee "advising" NIST on the
| creation of a FIPS for a portable document delivery format.
thank you for posting this. below, please find the extracted _textual_
_contents_ from this otherwise useless heap of bits. I appreciate that the
acrobat viewer had cut-and-paste functions, but this is still _way_ beyond
user hostile. "portable document delivery format", my <beep>.
#<Erik>
---------------------------------------------------------------------------
PDDF Requirements Document Draft 53/24/95
A REPORT TO NIST
FROM THE BLUE RIBBON PANEL
ON REQUIREMENTS AND RECOMMENDATIONS
FOR A
PORTABLE DOCUMENT DELIVERY FORMAT
February 24, 1995
Background
In September, 1994 a Blue Ribbon Panel was established under the direction
of National Institute of Standards and Technology (NIST), Computer Systems
Laboratory, Office Systems Engineering, Software Systems Technology
Division. This panel, made up of Federal Government users , were to advise
on action NIST can take to improve the interchange of final form electronic
documents. Mike Rubinfeld of NIST was directing this effort.
NIST was already working under a Cooperative Research and Development
Agreement with Adobe Systems Incorporated in defining broad requirements of
a portable document format that would be acceptable to a wide range of
users. This Blue Ribbon Panel's role was set up to be an advisory body of
active federal users. NIST's agenda was to develop adequate requirements
in order to develop a Federal Information Processing Standard (FIPS) for a
Portable Document Delivery Format (PDDF).
The Blue Ribbon Panel was co-chaired by Burt Newlin of the Office of the
Secretary of Defense and Basil Manns of the Library of Congress. Members
included individual representatives from Defense Information Standards
Agency (DISA) , IRS, Department of Energy, GSA, SEC, Department of
Education, US Courts, NARA, IRS, Supreme Court, NASA, US Patent & Trademark
Office, Department of State, USGS, NOAA, Department of Housing & Urban
Development, National Library of Medicine, GAO, GPO, Food and Drug
Administration (FDA), Bureau of Economic Analysis, and CIA. A list of
individuals associated with the represented organization is Attachment A.
The Blue Ribbon Panel held a number of meetings and workshops to both
review and evaluate existing portable document formats and final form
presentation quality formats in order to identify all potential concerns
and recommendations to the requirements users may have. User concerns
about the requirements, addressed technical specification issues,
implementation issues, and legal and proprietary issues. These
requirements are discussed further in this report.
Specific vendors' systems were evaluated. These include: Interleaf's World
View, SGML Open, Farallon's Replica, WordPerfect's Envoy, No Hands
Software's Common Ground, Electronic Book Technologies' DynaText, and
Adobe's Acrobat. All these systems provide some level of portability and
final form presentation. The Blue Ribbon Panel did not attempt to evaluate
all available systems, but provided opportunities for vendors to make
presentations.
Paper reports, providing specific input, were provided to the Blue Ribbon
Panel from specific organizations and individuals. These include:
1. A Position Paper regarding a FIPS for Electronic Document Exchange
prepared for the Blue Ribbon Committee and NIST by members of the
International Committee for Accessible Document Design (ICADD),
November 29, 1994.
2. Accessibility Considerations of Government Electronic Information, by
Paul Fontaine, Clearing House on Computer Accommodations, GSA.
3. Books for Blind Scientists: The Technical Requirements of
Accessibility, by William A. Berry, John A. Gardner, and Randy
Lundquist, Oregon State University.
4. Standardized Electronic Document Interchange Code, Chris Brooks,
Recording for the Blind, E-Mail, Oct. 14 and Oct. 26, 1994.
5. Comments on: Draft Requirements for Portable Document Format, from SGML
Open, Coraopolis, PA, January 3, 1995.
6. Comments from Friedolf Smits, IEEE, regarding Gardner's comments on
accessibility, E-Mail November 27, 1995.
These document are included in Attachment B.
Objectives
The Federal Government is a major publisher of documents (memoranda, office
documents, and scientific, technical, and medical literature) and has a
need to make these documents available in electronic form. Electronic
submission of documents in a standard portable final format is also an
important objective for many federal agencies. Just as printed material is
distributed through a variety of channels, the objectives for electronic
distribution are:
1. Deliver information electronically in a standardized platform-
independent format for which display software packages are readily
available on all major desktop and office computer platforms (DOS,
Windows, MAC, and UNIX).
2. Assure that on-screen document display becomes a viable and generally
available alternative to viewing printed documents.
3. Develop a strategy for interchanging digital documents in a
multi-platform open system environment.
4. Assure that all patents and legal or proprietary issues are resolved up
front.
5. Establish a Federal Information Processing Standard (FIPS) which shall
define a mutually acceptable open published portable format
specification.
To meet these objectives, all documents intended for electronic
distribution should be coded in a standard format defined by the proposed
FIPS. The Portable Document Delivery Format (PDDF) standard should support
both textual material and graphic elements. The Blue Ribbon Panel has
analyzed vendor products on the market and identified the requirements and
recommendations for an open portable document delivery format that can
serve as guidelines for the development of a FIPS. The requirements and
recommendations follow in this report.
Context
The Blue Ribbon Panel has defined a set of requirements for the portable
delivery of final form documents. These requirements are best understood
within the context of a document creation and delivery model. This model
(shown below) begins with the creation of a document using any of a variety
of tools, such as word processors, spreadsheets, graphics tools, etc.
These documents contain text and pictorial content, and a page composition
and layout that adds information to the presentation. Typically these
documents are created using proprietary products, and are saved in a
proprietary file format which provides a revisable form. Some products may
be capable of creating a revisable form text document in SGML (which has
some standard components, but no tag standards), rather than in a
proprietary format. However, SGML is not well suited to carrying page
layout and pictorial information, and does not meet many of the other
requirements described below.
The focus of the requirements effort has been on the need for a final form
standard (PDDF) which retains the page layout and pictorial information
needed for the delivery of complex documents. The portable final form
document is created from the revisable form document using conversion
applications. The resulting PDDF file can be distributed to end users,
and/or stored in a repository. The PDDF file can be viewed and printed
using widely available applications. The content of the PDDF file can also
be reused by extracting text and formatting (e.g. cut and paste), or by
using revision tools which can replace or reorder pages, and maintain a
document revision history.
Most of the requirements address a need for a flexible final form file
format which will permit the inclusion of many features and capabilities.
However, some of the requirements suggest the need for particular kinds of
applications which are used in conjunction with the PDDF file. The
distinction between file format and application is not always clearly drawn
because of the close relationship between the data contained in the file,
and the application associated with this data. This issue illustrates the
complex kinds of document types which government users envision creating,
and also the broad flexibility which already exists in final form products
on the market. Complex document types which depend on applications (like
video) not readily available with a simple viewing application may pose
problems for both immediate use and long term document retention. These
issues need to be addressed by both the originators of the documents and
the recipients.
Requirements
This final set of requirements evolved after many meetings of the Blue
Ribbon Panel. These requirements grew from a set of requirements developed
by individuals in private industry and by the Multimedia Distributed
Document Interchange (MDDI) sub-group of the Open Systems Implementor's
Workshop (OIW).
The Portable Document Delivery Format (PDDF) should be device independent,
efficiently stored and transmitted, and meet the needs of a diverse
population of document generators and consumers. Specifically it should
include the following properties:
1. Open Published Format
A published open format is defined here as a document that contains the
full format specification and is accessible to the public at a
reasonable cost. This document shall enable the implementation of
products based on the format specification without royalty to the
author(s) or providing organization. An extensible open format also
allows third party vendors to create value-added products with
competitive advantages.
2. Platform Independence
The PDDF should be free from platform dependent criteria. The format
can be accessed from a variety of platforms without any conversion of
the format itself. The viewing software, not the formatted data,
should be designed and implemented for each platform environment.
3. Modular Specification; Backward Compatibility
Future upgrades of the PDDF should not destroy the viewable form of
existing documents (and to the extent possible do not break existing
viewers). Earlier versions of the format specification shall be
compatible with future versions.
4. Support a Wide Range of Document Preparation Sources
The PDDF should support a wide range of existing document generation
software, such as word processors, scanning non-electronic documents,
graphics packages, image processing packages, electronic publishing
packages and forms generation packages. The format should be able to
be generated by a wide range of electronic document preparation
applications. Such conversion should be robust, simple, and
consistent.
5. Support for Full Function, Two Dimensional Graphics and Bit-mapped
Images
The PDDF should support device independent presentation of complex as
well as simple graphics from all kinds of sources, including but not
limited to drawing programs, architectural/engineering applications,
image and graphics applications.
6. Device Independent Color Support
The color reproduction capability of different devices varies widely,
both in the range of colors that can be reproduced and the intensity,
saturation and hue produced for a given, uncharacterized color value.
The PDDF should provide methods for expressing color values using color
spaces such as RGB, CMYK, or YC R C B that are device independent and
whose rendering on different devices will be as close to the same as is
relevant for the devices. The format should preserve the intended
color in a device-independent way as much as possible.
7. Support the Full Range of Textual Formatting and Typography
Document formatting and typography is a rich area of design and
presentation. It is important for the PDDF to support the electronic
transmission of documents with sophisticated formatting and a wide
range of fonts. This should include both provision for transmitting
relevant font information, in widely available formats such as Adobe
Type 1 (ISO 9541-3), True Type, Bitstream, as well as other raster
fonts and provide for font simulation where fonts are not transmitted
nor available to a viewer.
8. Computer Storage Space Efficiency
Both the storage and transmission of final form documents require that
the format of the document should be as compact as possible. This
includes the use of relevant compression techniques to reduce document
storage space. The format should allow for compression technologies
such as JPEG, LZW, T.4 and T.6 of the ITU FAX Standard (formerly the
CCITT Group 3 & 4 FAX), and newer technologies in future revisions of
the format specification. If the PDDF is extended to multimedia
environments such as audio and video, appropriate compression schemes
for these environments should be specified as well. Among the methods
that might be used to satisfy video compression are: MPEG, Cinepak
(used in QuickTime TM ) and Indeo (used in AVI).
9. Support Access/Use Restrictions
The PDDF should allow for controlled access to and use of the material
in a final form document to the users for which it was intended. This
includes password protection of the document and separate password
protection for the privileges controlled by the document password. The
protection scheme should be reliable, secure and suitable for export
outside the US. The PDDF should allow for encryption of the document
or parts of the document, allow for privilege classifications, and
allow for multiple levels of successive digital signatures at the file
level.
10. Document Construction/Rearrangement Capabilities - The PDDF should be
organized in a way that allows insertion, deletion and reordering of
pages without undue overhead. The format should be extended to allow
for revision (configuration) history, annotations anywhere within the
document, and document revision tracking.
11. Accessibility of Text, for Copying or Extracting or for Indexing (with
some level of formatting information)
The textual information contained within a final form document should
be accessible both to extract the text (with as much information about
its format as possible) and to index text using a full text indexing
technology. The format should allow for conversion to Braille encoding
or voice synthesis appropriate to meet requirements under the
accommodation law for accessibility to persons with disabilities. The
format should allow for textual description of graphical elements
(e.g., a 2x3 photograph in the top right corner of the page of a French
Poodle standing up).
12. Capture Structure
In addition to the presentation, the PDDF should be able to represent
structural information, such as paragraph markers, article threading,
the flow of connected sections of text, subject indexes, and
information in a table of contents. The PDDF should also support
imbedding of data such as EDI, SGML or HTML, access to persons with
disabilities by using the ICADD DTD (ISO standard #12083.
13. Support Navigation Aids to Directly Access Segments of a Document
The PDDF should include navigation aids such as a Table of Contents,
with hyperlinks to named segments or viewing rectangles on pages of the
document. The format should additionally allow for embedded textual
and graphical hyperlinks, links to any place within a document via
identified Hyperlink destination points.
14. External Hyperlink Capabilities
The format should allow links across documents, to other files (audio,
video), and via mechanisms like HTTP to participate in the World Wide
Web (WWW). The format should allow for a variety of search and
retrieval software interfaces, and provide an interface to an indexing
strategy that encompasses not only the document itself, but a
compendium of documents.
15. Single or Multiple File Documents
It should be possible to represent a complete document, including pages
of varying size and rotation, in a single file for ease of distribution
purposes. However, a document may optionally be separated into
multiple files.
16. Page Fidelity
The visual appearance of the document including the orientation and
makeup of each page, should maintain the same characteristics between
the source document and the final form formatted document. General
spacing and positioning of text, art work, mathematical notation,
graphics, and pictures, as well as number of lines per page, page
breaks, line breaks and pagination style should be preserved. The
format should maintain maximum fidelity between the printed document
and the electronically viewable document.
17. Large Document Scalability
The PDDF should be able to represent large documents with up to 20,000
pages per document; and/or large page size, without any significant
additional CPU memory requirements in the viewer or degradation of
processing speed for viewing, and maintaining random access
capabilities.
18. Print Capability Directly from Format
The PDDF should allow for direct conversion to printer specific
languages such as SPDL, Postscript TM, SPDL (ISO standard) or PCL TM
(Hewlett Packard's printer language) while maintaining page fidelity
between the printed version and the electronic version of the document.
Recommendations
In order to ensure this standard is successful there will need to be an
organizational function to verify that software products comply with the
standard. A registry of conformant software products should be maintained
by NIST. In doing so, a software conformance test plan and associated test
suite for the PDDF will need to be developed. It is advised that NIST
develop this in conjunction with the FIPS.
There should also be a PDDF Users Group established to maintain the
relevancy of the use of the standard, resolve technical issues and ensure
the logical migration of requirements into revisions.
It is the underling assumption that the Adobe Portable Document Format
V. 2.0 comes in meeting most if not all of the current requirements
specified by the Blue Ribbon Panel. The Blue Ribbon Panel believes that
this format is both flexible and extensible, and is likely to meet future
requirements as they evolve. This is the intent; to have a PDDF available
now, that can be implemented across platforms in an open environment.
Making the Adobe PDF a FIPS will benefit the government user community in
improving the interchangability of final form electronic documents.
The Blue Ribbon Panel recommends that NIST investigate any submarine
patents, or any proprietary elements in the Adobe's Acrobat or family of
products that may limit users of the PDDF. Specifically the use of the LZW
compression scheme and the halftone method used by Adobe cause the Blue
Ribbon Panel some concern. An agreeable licensing arrangement with Adobe
or the patent holders must be worked out in advance and incorporated into
the FIPS.
---------------------------------------------------------------------------
below, please find an ASCII drawing to mimic the useless figure included
only for effect:
---------------------------------------------------------------------------
Portable Document Creation & Delivery Model
------------------------------
(white box) Composition
Word Processing
& Graphics
------------------------------
|
|
V
------------------------------
(white oval) Revisable
Document
Format
------------------------------
|
|
V
------------------------------
(grey box) Final Form
Conversion
Process
------------------------------
|
|
V
------------------------------
(grey oval) Portable Document
Delivery Format
(PDDF)
------------------------------
|
|<------------------------+
V |
------------------------------ |
(database symbol) Distribution |
and |
Repository |
------------------------------ |
| |
| |
V |
+------------------------------+ |
| | |
V V |
----------------- ----------------- |
(grey boxes) |
View Document |
and Print Re-use |
|
----------------- ----------------- |
| |
+----------+
---------------------------------------------------------------------------
-- miracle of miracles. look what the Net dragged in.
This archive was generated by hypermail 2b29 : Sun Dec 02 2012 - 01:30:03 PST