(no subject)

From: Lloyd G. Rasmussen (lras@loc.gov)
Date: Wed Mar 01 1995 - 10:45:14 PST


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