(Supersedes NISTIR 4567)
Raster Graphics: A Tutorial and Implementation Guide
Frankie E. Spielman
Louis H. Sharpe, II
U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Computer Systems Laboratory Gaithersburg, MD 20899
QC 100 NIST • U56 #5108 1993
(Supersedes NISTIR 4567)
Raster Graphics: A Tutorial and Implementation Guide
Frankie E. Spielman
Louis H. Sharpe, II
U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Computer Systems Laboratory Gaithersburg, MD 20899
January 1993
U.S. DEPARTMENT OF COMMERCE Barbara Hackman Franklin, Secretary
TECHNOLOGY ADMINISTRATION Robert M. White, Under Secretary for Technology
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY John W. Lyons, Director .
- ' .. :% ,; ^^''^;S' 'j!
v'- v' '“"*' •''../ .ig;'-^^,- ' " -, /7'' A^vi'
' ‘''=' • ;•.. -1 \-'''-- : J \7A^rif^y“''f7£y
' - I .. 1 '.VI i . Preface
This report examines the technical issues facing an implementor of the raster data interchange format defined in the Open Document
Architecture (ODA) Raster Document Application Profile (DAP) . The ODA Raster DAP is also included as an appendix to military specification MIL-R-28002B . Information previously scattered throughout several standards is incorporated into this report for ease of reference. The ODA Raster DAP is analyzed with regard to both notation and intent.
The motivation behind the development of the raster graphics file formats for large documents which are detailed in the ODA Raster DAP originated in a meeting between the Department of Defense (DoD) and industry experts in 1987. The Computer-aided Acquisition and Logistic Support (CALS) Office of DoD asked the large document raster industry to provide suggestions for a standard interchange file format and raster encoding scheme. The result was the formation of an ad-hoc industry group known as the Tiling Task Group (TTG) which quickly completed work on a draft standard based on Consultative Committee on International Telegraphy and Telephony (CCITT) recommendations.
CCITT had been collaborating with the International Organization for Standardization (ISO) and was developing a technology based upon the concept of a compound document which was to replace the current facsimile environment. International Standard (IS) 8613, which defines the Open Document Architecture (ODA) , was the result. It fills two important needs: (1) storing complex documents containing graphics and textual information in complex word processors, and (2) allowing facsimile technology to produce true compound documents which are more than just hard copy.
Using the TTG draft standard, the TTG defined its requirements in a DAP and wrote a proposed addendum to IS 8613, Part 7, in order to insert the minimal mechanisms needed to support tiling. The DAP was further developed through the efforts of the Open Systems Environment Implementors' Workshop (OIW) which named it the "ODA Raster DAP." Requirements were recently added to the ODA Raster DAP to support requirements defined by the Association for Information and Image Management (AIIM) and to make the ODA Raster DAP more compatible with other ODA DAPs that are being developed.
This document supersedes NISTIR 4567, Tiled Raster Graphics and MIL-R-28002A: A Tutorial and Implementation Guide.
Ill Acknowledgments
Many people contributed to the creation of this report. All the members of the Tiling Task Group originated and reviewed many of the ideas in this document and anticipated the problems implementors might have. Marcel Rivard, Christian Kunz , Bancroft Scott, Peter Sih, Rick Pond, and members of the ODA Special Interest Group brought to light and analyzed some difficult areas of ODA or ASN.l interpretation. Nick Mitschkowetz created the tiled test image which is used in the examples. Joe Farrington helped analyze the original examples with the use of the NIST Free Value tool and developed procedures for using the tool. Annette Shuford and Les Potter made particularly close readings of the drafts of this report. Joe Garner, Jack Jeffers, Phil Battey, Bob Moyer, and Jim Dalgety contributed to the original version of this document, NISTIR 4567.
The efforts of many other people too numerous to mention are gratefully acknowledged.
IV Table of Contents
Preface iii
Acknowledgments iv
Table of Contents v
1 Introduction 1
2 Pertinent Standards 2 2.1 MIL-STD-1840 2 2.2 MIL-R-28002B 2 Contracting Options 2 Type I and Type II Data 3
2 . 3 ODA Raster DAP 3 2.4 ANSI/AIIM MS-53 4
3 Benefits of ODA 5
3 . 1 Compound Documents 5 3.2 Relationship to Facsimile 5 3.3 Using ODA 6
4 Overview of ODA 7 4.1 ODA's Relation to OSI 7 4.2 ODA's Base Standard: IS 8613 7
4 . 3 ODA Encoding 8 4.4 Document Application Profiles (DAPs) 9
5 Involved Organizations 10 5.1 Government Initiatives 10 5.2 U.S. Initiatives 10 5.3 International Initiatives 10
6 File Structure 12 6.1 DoD Raster Header Information 12 6.2 ODA Structure 12 Document Profile 12 Presentation Styles 12 Document Layout Root 12 Composite Page 12 Frame 12 Block 13 Content Portion 13
7 Views of Raster Data 15
8 ODA Constituents and Attributes 20 8.1 Content Portion Description 20
V 8.1.1 Content Portion Attributes 20 8.1.2 Content Information 22 8.1.3 Alternative Representation 23 8.2 Presentation of the Image 2 3 8.2.1 Presentation Attributes 24 8.2.2 Presentation Style ..... 25 8.3 Document Layout Structure 26 8.3.1 Document Layout Root 27 8.3.2 Composite Page 27 8.3.3 Image Frame 28 8.3.4 Specific Block 28 8.3.5 Relationship Attributes and Layout Objects 2 8 8.3.6 Specific Layout Attributes 31 8.4 Document Profile 32 8.4.1 General Attributes 33 8.4.2 Document Characteristics 33
8.4.2. 1 Raster Graphics Content Defaults . . 35
8. 4. 2. 2 Non-basic Document Characteristics . 35 8.4.3 Document Reference Attribute 36 8.4.4 Summary 36 8.5 Relationship of Objects 37
9 Technical Specification in the DAP 4 0 9.1 Genealogy 4 0 9.2 Simplifications 40 9.3 DAP Narrowed by MIL-R-28002B 40 9.4 Proforma and Notation 41 9.5 Elements of the DAP 42 9.6 Format of DAP Technical Specification Section ... 42 9.7 DAP Technical Specification 42 9.7.1 Content Portion Constraints 43 9.7.2 Presentation Style Constraints 44 9.7.3 Layout Constituent Constraints 45 9.7.4 Document Profile Constraints 47
10 ASN.l Coding Concepts 49 10.1 ASN.l Notation 49 10.2 Sample of ASN.l Definitions 49 10.3 The Basic Encoding Rules 53 10.4 Transfer Values 56
11 Technical Concepts 64 11.1 Raster Graphics Basics 64 11.2 Encoders and Decoders 67 11.3 Converters Versus Native Systems 68 11.4 Bit Order 68 11.5 Padding/Byte Boundaries 68 11.6 Partial tiles 69 11.7 Tile Ordering 70 11.8 Orientation 71 11.9 Rotation to Proper Viewing Orientation 74
VI 1
11.10 Uncompressed Bit Sense 74 11.11 Database Issues 74 11.12 Definite Versus Indefinite Length 75
11.13 Basic Versus Non-basic Versus Default Values . 75 11.14 Null Tiles 76 11.15 Presentation Styles 76
12 Tools 78 12.1 ODA Toolkit 78 12.2 The ISO Development Environment (ISODE) 78 12.3 Free Value tool, ASN.l Compilers 79
13 Glossary 80
14 References 83
Appendix A ASN.l Definitions 85
Appendix B Test Chart 9 3
Appendix C AIIM Document: With Clipping and Number of Lines 95
Appendix D AIIM Document: Without Clipping and Number of Lines 102
Appendix E CALS: Tiled Example Minimum Parameters .... 108
Appendix F CALS: Tiled Example All Parameters 115
VI ' . , '
* ;\.-«k;suo'^ :* vx,.i.jl!* . 5
>':V' x:^. 'iV', ’i- 'iy; 3^ „ cr i t . >:*
' . . •'-;'• ' 't., . . » A r;x . iH
' ' - • *,'>. -- \ ':^ v’V>-: T . 'i<1'^v«T.o-:s'^ ,. .t.-tl , ’'4 ' ^ .
- " . ... I . . . iWO i . !>X V ;V,
. -r .. .-, .^i;iv,.f*. a;..- ^{ 1^1
... t- n.. •'7 <‘i'' • ' „ .', ^ . O.;
' • ' .« ' ’ ^ .
' . . :.!.fC.'^-il'.»iwl!3 ' '.J ^ - ‘i ... ' .i - H .xl.tiwT«aq£|A * ' ' - ' ’ - ^ ^ lu* '---'" * - --v. .,n'> - . jji- ... y<>-.btaiini‘^4.% '. ' ^ .,..., .:^b * ’ .. ’ .' w. - ^(xXJi, * • ®i' 5 T U3i - •% t.' ' ' ' '4 -r * . _ ‘r^ , /^r. ., ^A:iiv.V t ,.i:?.i'5a ! . rI)i7aq4Al k-. ., * - ‘i-;'’^' t Ta; 1 fXbiwquyt '' - ’.^'j ' ‘ - i^ ^ < . * ; '" •‘ .’i ' .' ’i ' . , ; i - T ". * yJX 4 - ? V •i* !6 X.,' •"^0. Ir - 'iM. (S' ^*- • ?*. . 6 'V-v. . . . . 1 Introduction The purpose of this tutorial is to give informal guidance and suggestions to those undertaking implementations of the Open Document Architecture (ODA) Raster Document Application Profile (DAP) . The intended audience is therefore system architects and programmers First, this tutorial provides an overview of the pertinent standards (section 2 ) , a discussion on the benefits of ODA (section 3) , and an overview of ODA (section 4) . Following the introductory sections is a discussion of the organizations involved with ODA and raster graphics (section 5) The tutorial examines the actual sequence of data elements found in a raster graphics file (section 6) and discusses various views of raster data (section 7) . This then leads into a detailed description of the ODA structure and its elements (section 8) and the technical specifications within the ODA Raster DAP (section 9) . It then explains the coding concepts used for the ODA interchange format. These are based upon the abstract syntax notation and basic encoding rules (section 10) In the latter portion of this document, the details of several technical concepts are explained (section 11) . A brief tutorial on the basics of raster graphics is presented at the beginning of section 11. Following section 11, this tutorial briefly discusses some tools that may be used by implementors (section 12) and provides a glossary (section 13) and a list of references (section 14) . Appendix A provides a complete list of the abstract syntax notation definitions representing an implementation of the ODA Raster DAP. Appendix B contains a test chart image used in building examples illustrated in the remaining appendices (C-F) . Information contained in all of these appendices as well as actual interchange files may be obtained from NIST (see Appendix A) This document is intended to be an aid to an implementor of the ODA Raster DAP and the requisite standards referenced in it. The guidance provided in this tutorial is for information only. In cases of technical errors or conflicts with the referenced standards, the standards will prevail. 1 2 Pertinent Standards There are several documents which serve as a basis for this tutorial. First of all, there are two military documents. Military Standard MIL-STD-1840 and Military Specification MIL-R-28002B. Secondly, there is the ODA Raster DAP developed by the Open Systems Environment Implementors' Workshop and a proposed ANSI/AIIM MS-53 document being developed by the Association for Information and Image Management (AIIM) . In turn, these documents reference other pertinent International Organization for Standardization (ISO) and Federal Information Processing Standards (FIPS) standards. 2.1 MIL-STD-1840 MIL-STD-1840, Military Standard. Automated Interchange of Technical Information [20], standardizes the format and structure of digital technical data files for the purpose of interchange between organizations or systems. For raster files, it describes a file header to be placed ahead of any raster data specified by MIL-R-28002B . One of the motivations behind the creation of MIL- STD-1840 was the need to capture the Hollerith information from aperture cards and deliver it along with the scanned raster data on magnetic tape or other media. 2.2 MIL-R-28002B MIL-R-28002B, Military Specification, Requirements for Raster Graphics Representation in Binary Format [19], defines the structure and encoding of raster data files to be delivered to the government. It was created with the storage and interchange of scanned engineering drawings in mind, but applies to other documents as well, such as technical manuals and illustrations in raster form. MIL-R-28002B can also serve as a means for standard interchange between private contractors. MIL-R-28002B restricts certain features of the ODA Raster DAP either because generality was desired in the DAP or because the mechanisms for these specific kinds of limitations are not available within ODA (see ODA Raster DAP, paragraph 2.3). Contracting Options There are a variety of parameters that are free to vary while still remaining within the bounds of MIL-R-28002B . These items are separated into two classes: 1. Those that must be specified by the contracting officer in order to avoid ambiguity or incorrect implementations, and 2 Pertinent Standards 2. Those that a contracting officer may wish to specify, but which, in the absence of compelling reasons to do so, are better left to the implementor's judgement. Some issues within MIL-R-28002B requiring additional clarification are discussed in the Technical Concepts section of this tutorial. Type I and Type II Data MIL-R-28002B discusses two different possible representations of raster data: Type I and Type II. Type I data is simply CCITT T.6 encoded data for an entire image representation enclosed within MIL-STD-1840 header information. The CCITT T.6 encoding of raster data is defined in FIPS PUB 150, Telecommunications: Facsimile Coding Schemes and Coding Control Functions for Group 4 Facsimile Apparatus [6] (CCITT Recommendation T.6 [4]). Type I data has no support for tiling, but has the virtue of simplicity. Type II data is a MIL-STD-1840 header wrapped around an ODA-style document as specified in the ODA Raster DAP, Appendix A to MIL-R-28002B . The ODA document may include tiled raster data or may include a single compressed block of raster data as in Type I, but with all ODA parameters and data structuring included. An article published in Inform [24] describes the use of a tiling scheme for large images. 2 . 3 ODA Raster DAP ODA DAPs describe a restricted subset of the wide range of objects available under the ODA base standard, IS 8613, Information Processing - Text and office systems - Office Document Architecture (ODA) and Interchange Format . As such, DAPs relieve implementors of having to support features not of use to their application. The ODA Raster DAP identifies the requirements suited for raster graphics applications. The ODA Raster DAP represents the state of work within the Open Systems Environment Implementors' Workshop (see Involved Organizations, section 5) as of the December 1992 workshop. It is being published as Part 23 of the NIST Special Publication 500-206, Stable Implementation Agreements for Open Systems Interconnection Protocols [22]. It is anticipated that the ODA Raster DAP will be proposed as a Federal Information Processing Standard (FIPS) . In addition, a group of international delegates have agreed to a plan for rapid harmonization of the ODA Raster DAP with the goal of 3 Pertinent Standards obtaining an approved International Standard Profile (ISP) by January 1994. 2.4 ANSI/AIIM MS-53 AIIM is also developing a related document, ANSI/AIIM MS-53 (Proposed), Bi-Level Image File Format [1]. It specifies a file format for the exchange of bi-level electronic images and is based upon the ODA Raster DAP. Using a series of tables from the AIIM document, the intent is that the user constructs an ODA data stream without understanding the details of ODA and its associated interchange format. It implements only a subset of the ODA Raster DAP. AIIM plans to publish this document in April 1993. 4 . *. 3 Benefits of ODA 3 . 1 Compound Documents Compound documents are those electronic documents consisting of multiple content types, e.g., text, raster graphics, vector graphics, voice annotation, etc. With the emergence of compound documents, raster will become more useful and widespread. Word processor vendors are developing ODA export and import converters to allow documents received over data networks to be refined, modified, and re-used. Within the OIW, there is an ODA Interoperability subgroup scheduling and registering ODA interoperability tests. Since the ODA Raster DAP is similar to other DAPs, the possibility exists that common platforms and raster editors will be used in the future for handling both large and small documents. 3.2 Relationship to Facsimile CCITT has advanced a recommendation for a very simple ODA document application profile to support the needs of low-cost Group 4 facsimile hardware. This is known as CCITT Recommendation T.503, A document application profile for the interchange of group 4 facsimile documents [ 3 ] Since the Group 4 facsimile world is adopting ODA, using ODA for the tiled representation of large document images offers certain advantages. It could be expected that the ODA orientation of the new Group 4 facsimile market will make the choice of an ODA approach in MIL-R-28002B beneficial to the smaller market for large-document systems . Provisions exist in the international Profile Alignment Group for ODA (PAGODA) DAPs (see Involved Organizations, section 5) for the packaging of ODA documents as X.400 electronic mail messages, and also for the exchange of ODA documents using the File Transfer, Access, and Management (FTAM) file transfer scheme for high speed networks. ODA is designed with interchange in mind. ^ ODA through ISO 8613-7 allows both T.4 encoding (commonly known as "CCITT Group 3") and T.6 encoding (often called "CCITT Group 4") In this discussion of machines for Group 4 facsimile, it should be made clear that current Group 3 machines do not use ODA, although the exchange of "CCITT Group 3" data via ODA is possible in principle. 5 Benefits of ODA 3.3 Using ODA The resistance some people have expressed after their first encounter with ODA and ASN.l [8] may come from the overwhelming avalanche of terms the standards appear to have generated. However, the terms more directly result from the complexity of automating the document and image environment than it is with the standards. For example, just take a look at the complexity of some of the word processors that are commonly used today. Luckily, it is only necessary to learn ODA at its most general level to complete an implementation of the ODA Raster DAP. There have been some recent developments that will expand the knowledge and use of ODA and ASN.l. First of all, this tutorial is intended to help educate users and reduce the fear of ODA and ASN.l. Second, the availability of an ODA Toolkit will help implementors who are implementing ODA. Third, the development of an AIIM document is intended to help ease implementors into ODA compliant image interchange without requiring a knowledge of ODA. Fourth, ASN.l is becoming more widely used in other standards and more ASN.l tools are becoming available. 6 . 4 Overview of ODA 4.1 ODA's Relation to OSI A new era of connectivity is beginning as the Open Systems Interconnection (OSI) standards are becoming popular. ODA is clearly in the mainstream of OSI development and uses the mechanisms, formalisms, and abstract syntaxes that other OSI protocols use. Version 2 of GOSIP [21] contains information required to transport any ODA document as a body part of a message or content of a file. Future versions of GOSIP will reference applicable DAPs which NIST plans to issue for Federal agency use. 4.2 ODA's Base Standard: IS 8613 Each realm of OSI standards development has at its nucleus the base standards that define the building blocks available for creating more complex protocols or services. IS 8613, Information Processing - Text and office systems - Open Document Architecture (PDA) and Interchange Format [9-15]^ is the fundamental standard for ODA. A general overview of ODA may be found in ODA and Document Interchange [5] and a more comprehensive description of ODA is contained in Document Architecture in Open Systems , The ODA Standard [2]. Other standards also affect ODA work in some degree, but we will not discuss them in this document. IS 8613 has several parts, each of which addresses some portion of ODA. The pertinent parts are discussed below. Part 1; Introduction and General Principles [9] gives a great many definitions of basic ideas. It describes the motivations and unifying design principles of ODA. Part 2 ; Document Structures [10] defines the basic elements of a document architecture and the conceptual models necessary to understand the layout and imaging processes. It also defines the different classes of allowed document architectures. Part 4; Document Profile [11] describes the purpose and attributes of a document profile. Part 5; Office Document Interchange Format (PDIF) [12] shows how to apply the encoding rules to ODA documents to prepare them for interchange as ODIF data streams (files) ^ The ISO 8613 ODA Standard is scheduled to be republished in March 1993 incorporating several addenda, including some not mentioned. It will be published as a joint CCITT and ISO document. 7 Overview of ODA Part 7 ; Raster graphics content architectures [13] is the portion of IS 8613 that defines raster graphics content (data) . All of the relevant attributes of raster data that need to be properly spelled out for successful interchange are identified. Allowed (permissible) values for those attributes and their defaults are all defined. Part 7 Tiling Addendum [14] contains the extensions to Part 7 necessary to implement tiling. Such attributes as tile size and tile type (how a tile is encoded) are specified. Part 7 Additional Bit Order Mapping Addendum [15]^ contains the extensions to Part 7 necessary to encode CCITT T.4/T.6 data in the down bit order sequence. 4.3 ODA Encoding The interchange format for an ODA document is a data structure described or expressed in a notation which is independent of any particular machine in which the structure might be represented. For example, problems with the particular manner in which an integer might be represented on two different machines can be avoided. This notation is called an abstract syntax. In recognition of the fact that many such syntaxes are possible, the notation used in ODA and elsewhere in the Open Systems Interconnection (OSI) family of protocols is called Abstract Syntax Notation One (ASN.l). ASN.l is defined in two standards: IS 8824, Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One f ASN.l) [16], and IS 8825, Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.l) [17]. ASN.l is further described in The Open Book, A Practical Perspective on OSI [23]. The first document describes ASN.l syntax without defining the encoding rules that actually permit a protocol or interchange format to be put "on a wire" or in a file. The encoding of the syntax is a separate issue entirely. ^ The addendum was approved by CCITT but was not approved by ISO. The text supporting this addendum will appear in the joint publication with a note added stating that it was not approved by ISO. PAGODA has submitted a defect report which requests that ISO reconsider its position and approve the addendum. Otherwise implementors will refer to the CCITT version of the publication. 8 Overview of ODA The encoding represents the elements of the syntax as actual machine-readable symbols. These so-called Basic Encoding Rules are defined in IS 8825. They are called basic because other encoding rules are possible. One other encoding called Office Document Language (ODL) is also defined in IS 8613-5. It is based on the Standard Generalized Markup Language (SGML) . ODL is not illustrated in this tutorial. 4.4 Document Application Profiles (DAPs) DAPs are well-defined profiles, or subsets, of the ODA standard. Each DAP is created by a user group to meets its own needs. DAPs greatly limit the knowledge of ODA required for specific applications. The ODA Raster DAP was initially created by the Tiling Task Group and then further developed through the efforts of the Open Systems Environment Implementors' Workshop. It has been simplified to meet the needs of the large-document and technical publications raster communities, particularly as they interact with the CALS program. It also includes specifications necessary to support AIIM's bi-level image file format. 9 . 5 Involved Organizations All of the organizations listed below have had some hand in either the format, the development, or the content of the hierarchy of standards embodied in the ODA Raster DAP. 5.1 Government Initiatives The Department of Defense Office for Computer-aided Acquisition and Logistic Support (CALS) , the National Institute of Standards and Technology (NIST) , and the industry-based Tiling Task Group (TTG) are the primary developers of the technical content of the ODA Raster DAP. 5.2 U.S. Initiatives The Open Systems Environment Implementors' Workshop (OIW) is hosted by NIST and the Institute of Electrical and Electronic Engineers (IEEE) and meets quarterly. The ODA Special Interest Group (ODA SIG) meets under its auspices and undertakes North American development of ODA-related items, primarily DAPs. The ODA Raster DAP was developed, voted on, and approved by this group. The American National Standards Institute (ANSI) X3V1 committee is the North American contributor to the development of IS 8613 within the International Organization for Standardization (ISO) 5.3 International Initiatives The international Profile Alignment Group for ODA (PAGODA) has developed a common set of ODA International Standard Profiles (ISPs) or internationally approved DAPs for world-wide use. These groups include the European Workshop for Open Systems (EWOS) , the Asia-Oceania Workshop (AOW) , the Open Systems Environment Implementors' Workshop (OIW) , and CCITT. PAGODA coordinated development of three related document processing applications DAPs. These are known as FODll, FOD26, and FOD36. Additionally, PAGODA has initiated action to develop image application DAPs including the ODA Raster DAP. At the PAGODA meeting of October 19-23, 1992, the delegations agreed to a plan for rapid harmonization of the ODA Raster DAP specification with the goal of obtaining an approved ISP by January 1994. The Association for Information and Image Management (AIIM) is coordinating the development of the ANSI/AIIM MS-53 document. It was initiated within the U.S. and is now progressing as a work item to its corresponding international body. The ODA Consortium was established in April 1991 to promote the electronic interchange of documents among different computer 10 . Involved Organizations systems throughout the world. It has developed an ODA Toolkit (see Tools in section 12) 11 6 File Structure This section discusses the actual sequence of items inside an interchanged raster file. The ordering of data elements within an ODA document is specified in IS 8613 Part 5, section 5.2, where use of the class A data stream is mandated for the ODA Raster DAP. The entire sequence of data items transferred is illustrated below in figure 1. Each of the ODA items is discussed in greater detail in the section 8, ODA Constituents and Attributes. 6.1 DoD Raster Header Information The DoD raster header information is required for interchange of raster data within DoD. The fields of this header are clearly spelled out in MIL-STD-1840 . This header information is not required to interchange an ODA document. 6 . 2 ODA Structure Document Profile The document profile is the first item in the representation of an ODA document. Presentation Styles The presentation styles are optional, but if they do appear, they must occur immediately following the document profile. Document Layout Root The dociiment layout root must occur next and serves as the root for all pages of the document that follow the root. Composite Page There can be one or more composite pages. The term composite is applied to these pages because they are layout objects containing subordinate layout objects, a single frame in the case of the ODA Raster DAP. Frame The frame is a rectangular area within the page and contains a single block. For the ODA Raster DAP, the frame is coincident with the page. 12 File Structure Block The block is a rectangular area within the frame. The raster image is always associated with a block. Each block (in the tiled case) may have the following optional entry among its sub-elements: Tile Index The optional tile index may be present only in tiled files. The order of its elements matches the order of the tiles. Content Portion The content portion is the actual raster data and its associated attributes for a single raster image. The raster data may be in either the tiled or untiled format. If tiled, the data for tiles occur within that content portion in an order that is primarily along the pel (picture element) path direction and secondarily along the line progression direction. The pages, frames, and blocks may occur as many times as necessary to represent all the raster images in the document. One image per block, one block per frame, and one frame per page. All of the associated content portion objects containing the actual image information occur as a group following the last block. Figure 1 shows the file structure of a file. Only DoD files require the MIL-STD-1840 header. 13 File Structure MIL-STD-1840 Header DoD Only Document Profile ODA Structure Presentation Styles (optional) Document Layout Root Page Layout Object 1 Frame Layout Object 1 Block Layout Object 1 Repeat as necessary Content Portion n Figure 1 - File Structure 14 . 7 Views of Raster Data There are different views of raster graphics data discussed in the ensuing sections. These views are related to one another and not everyone needs to understand the details of each view. This section will provide a brief overview of each view and how they relate to one another. See figure 2. Figure 2 - Views of Raster Data The views may be associated with how an implementor develops and implements a system supporting the ODA Raster DAP. If an implementor purchases an ODA system off the shelf which supports all of ODA, it is conceivable that he would not have to look past the section 8, ODA Constituents and Attributes. Taking this one step further, an implementation of ODA may be set up to process a specific DAP, i.e., the ODA Raster DAP. In this case, a thorough analysis of the technical specifications in the DAP, section 9, Technical Specifications of the DAP, may have to be reviewed If an implementor is implementing an ODA Raster DAP interchange capability without the aid of an ODA system, the implementor will likely have to take the development one step deeper and implement 15 . views of Raster Data it using ASN.l. See the ASN.l Coding Concepts, section 10, which discusses the interchange format. AIIM has taken this process one step further by describing a data stream through the use of tables. This resulting data stream is intended to be an ODA Raster DAP compliant data stream. Using the AIIM tables will result in a limited subset of the ODA interchange f ormat The following paragraphs provide a general overview of each of these views prior to diving into the details in later sections of this document. To do this, these views and relationships are based upon an elementary view of raster data. For example, when interchanging raster data, it is generally understood that the n\iniber of pels per line (line length) must be known and that the number of lines is helpful although not required. First of all, the number of pels per line must be known before a system can decode the compressed raster data. Although not required, sometimes it is helpful to know the number of lines to determine memory space allocation, etc. These attributes are grouped together within ODA into a set called raster graphics coding attributes. Another piece of information that needs to be known is how the data is encoded, e.g., CCITT T.6, CCITT T.4, bitmap, tiled, etc. This characteristic is determined by the type of coding attribute. Of course, the interchange would not be complete without including the actual raster data, the content information. All of this information is grouped together in ODA as an object called content portion. One important attribute required in ODA is the content identifier layout attribute. This attribute is used to identify each of the content portion objects separately from all of the other ODA objects that are present in the interchange. If we use these attributes, we could build an example of a raster graphics structure like the following: Content portion (raster graphics) Content identifier layout Type of coding Coding attributes (raster graphics coding attributes) number of lines number of pels per line Content information (the raster data) With this basic knowledge in mind, the first view is to look at requirements from a textual description viewpoint. This was begun in the paragraphs above but the complete raster graphics requirements are defined in section 6 of the ODA Raster DAP. These 16 views of Raster Data requirements are also discussed as a tutorial later in this document, see section 8, ODA Constituents and Attributes. Only a few of the attributes are introduced at this time in order to explain the general content and structure of this document. The second view looks at the raster data from a syntactical or notational standpoint. Here, the text from the first view is defined in a notation that computers can understand. See figure 3. The complete raster graphics technical specifications are defined in section 7 of the ODA Raster DAP. If you have a "DAP Reader" (DAP parser) that could read the DAP notation, then implementors and conformance testers would require no further views to understand the ODA Raster DAP. The DAP notation describes the data to an ODA system which can then generate data in the proper interchange format. Raster-graphics-content-portion { REQ Content-identifier-layout {ANY_VALUE}, - - PERM Type-of-coding { ASN.l {2 8 3 7 5} tiled encoding ASN.l {2 8 3 7 - T.6 encoding - MSB - 1 6} } PERM Coding-attributes { REQ #raster-graphics-coding-attributes { PERM #number-of-lines {>0}- REQ #number-of-pels-per-line {>0}}}/ PERM Content-information {RASTER} } Figure 3 - Technical Specification The third view looks at the raster data from an ODA interchange standpoint using ASN.l Definitions as depicted in figure 4. The complete set of ASN.l Definitions used in the ODA Raster DAP are found in IS 8613-5, IS 8613-7, and the IS 8613-7 Tiling Addendum. The ASN.l Definitions in figure 4 is a restricted subset of definitions extracted from these standards documents. Tracing through the ASN.l Definitions in figure 4 results in a hierarchical data structure. If you follow the arrows which point to the definition of the referenced name, you will end up with the same structure as shown in figure 3. The fourth view illustrates actual data instances of an image as shown in figure 5. The type of coding indicates that the data is 'T.6 encoded - MSB', the number of pels per line is 2,550, and the number of lines is 3,300 and these attributes are followed by 12,792 octets of T.6 encoded (MSB) data, content information. You should note that column one illustrates the same basic structure as 17 views of Raster Data illustrated in our original example of a raster graphics structure. Column two illustrates the actual encoded file in a hexadecimal representation using ASN.l Basic Encoding Rules. This second column illustrates the use of tags, lengths, and values that are needed to describe the interchange format for a specific raster data image. Text-Unit ::= SEQUENCE { content-portion-attributes Content-Portion-Attributes OPTIONAL, content-information Content-Information OPTIONAL } Content-Information ::= CHOICE { one-octet-string OCTET STRING, seq-octet-string SEQUENCE OF OCTET STRING } Content-Portion-Attributes 7:= SEtT content-identifier-layout Content-Portion-Identifier OPTIONAL, type-of-coding Type-Of-Coding OPTIONAL, coding-attributes CHOICE { raster-gr-coding-attributes [2] IMPLICIT Raster-Gr-Coding-Attributes, alternative-representation [3] IMPLICIT Alternative-Representation } OPTIONAL } Type-Of-Coding CHOICE { other-coding [6] IMPLICIT OBJECT IDENTIFIER “ or {2 8 3 7 5} 'tiled encoding' “ or {2 8 3 7 6} 'T6 encoding - MSB' } Raster-Gr-Coding-Attributes* Ti^ SET { number-of-pels-per-line [0] IMPLICIT INTEGER OPTIONAL, number-of-lines [1] IMPLICIT INTEGER OPTIONAL, } Figure 4 - ASN.l Definitions The remaining sections of this document describe each of these views in more depth. Section 8 describes the ODA Constituents and Attributes needed to support the characteristics in section 6 of the ODA Raster DAP. Section 9 describes the Technical Specifications in the DAP in a syntactical notation. Section 10, ASN.l Coding Concepts, describes the data interchange requirements using ASN.l and how to encode an interchange file based on example data. 18 views of Raster Data Specific Data Values Interchange Transfer Values a3 82 32 09 [3] constr <12825> content-portion { . 31 1b [UNIV 17] constr <27 > content-portion-attributes { content-identifier-layout "1 0 0 0 0", . . 40 09 [APPL 0] <9> 31 20 30 20 30 20 30 20 30 . . 86 04 [6] <4> type-of-coding other-coding { 2, 8, 3, 7, 6 }, 58 03 07 06 . . a2 Ob [2] constr <8> coding-attributes raster-gr-coding-attributes { number-of-pels-per-line 2550, ... 80 02 [0] <2> 09 f6 ... 81 02 [1] <2> number-of-lines 3300 } }, Oc e4 content-information one-octet-string . 04 82 31 f8 [UNIV 4] < 1 2792 > - '...'H - '< Figure 5 - Interchange Data Values 19 8 ODA Constituents and Attributes For the purpose of interchange, an ODA document is presented as a collection of constituents or objects. Each constituent is a segment or portion of the interchange which contains a set of interrelated attributes. Each attribute describes a certain characteristic of that specific constituent or segment of the document. Constituents are often defined in an incremental way, with references being made back to earlier definitions. No constituent is used before it is defined. The types of constituents used in the ODA Raster DAP are: document profile, presentation style, docximent layout description, and content portion description. This order is as specified in IS 8613-5, clause 5.2. The document layout description constituents consists of four types of ODA Raster DAP objects: document layout root, composite page, image frame, and specific block. For a multiple page document, the layout and content portion constituents repeat as shown in figure 1. In the discussion below, the constituent, attribute, and attribute set names are shown in bold face when each term is being introduced or defined. The hyphens normally found in the names of items in the DAP have been removed for readability. The order of the discussion below has been chosen to help those with raster graphics related background by starting with an area that they are probably already familiar with. The sequence of the discussion is in the order of: content portion description (the raster data), presentation style (presentation characteristics) , document layout description (layout on the media) , and document profile (global file information) . Note that this is not in the same order as the sequence of objects to be found in the interchange file. 8.1 Content Portion Description The content portion description is a constituent of the document which describes how the raster graphics data is represented in the file. The content portion description includes two parts: (1) the coding attributes, content portion attributes, needed to specify the properties of the content information; and (2) the actual content information (raster image) . For the ODA Raster DAP, each content portion will be laid out on a single page and will consist of only raster graphics content. 8.1.1 Content Portion Attributes The content portion attributes is a set of attributes consisting of content identifier layout, type of coding, and raster graphics coding attributes. 20 . ODA Constituents and Attributes The content identifier layout is a relationship attribute. As can be seen from figure 1 , there may be multiple content portion description objects within the data stream. It is the content identifier layout attribute that uniquely identifies a specific content portion description and associates that content portion description with a unique document layout description (specific block) . It is a sequence of non-negative integers which will be discussed later. Type of coding is an attribute which specifies the coding used to represent the content information. For the ODA Raster DAP, the allowable values are as follows: 'T.6 encoding' indicates that the entire raster data (image) is not tiled and is encoded in accordance with the CCITT T.6 algorithm using the up bit order sequence. See discussion on bit order in section 11, Technical Concepts. 'T.4 one dimensional encoding' indicates that the raster data is encoded according to the one-dimensional encoding scheme defined in CCITT Recommendation T.4 using the up bit order sequence. 'T.4 two dimensional encoding' indicates that the raster data is encoded according to the two-dimensional encoding scheme defined in CCITT Recommendation T.4 using the up bit order sequence. 'Bitmap encoding' indicates that the entire raster data (image) is not tiled and is in the uncompressed or bitmap form. 'Tiled encoding' indicates that the raster data is tiled and that each tile may then be represented in one of five possible ways: 'T.6 encoding', 'T.6 encoding - MSB', 'bitmap encoding', 'null background', or 'null foreground' (see Tile types below) 'T.6 encoding - MSB' indicates that the entire raster data (image) is not tiled and is in encoded in accordance with the CCITT T.6 algorithm using the down bit order sequence. 'T.4 one dimensional encoding - MSB' indicates that the raster data is encoded according to the one-dimensional encoding scheme defined in CCITT Recommendation T.4 using the down bit order sequence. 'T.4 two dimensional encoding - MSB' indicates that the raster data is encoded according to the two-dimensional 21 , ODA Constituents and Attributes encoding scheme defined in CCITT Recommendation T.4 using the down bit order sequence. NOTE; The only valid values for MIL-R-28002B are 'T.6 encoding - MSB', 'tiled encoding', and 'bitmap encoding'; the others are only valid outside of MIL-R-28002B. Raster graphics (gr) coding attributes is a set of attributes which provide information required for encoding and decoding the content information as well as other information that is intrinsic to the content portion and required to layout and image the content. All of the attributes in this set deal with how to interpret the content data stream (content information) not how the image is to be presented on the display media. The attributes are defined as follows: Number of pels per line specifies the number of pels in each line within the content information. This attribute must always be specified. Number of lines specifies the number of lines of pels within the content information. Tiling offset applies only to tiled content information. It specifies the location of the pel array within the tile space by defining the offset of the first pel of the pel array from the first pel position of the first tile. This is specified by a coordinate pair, consisting of two non-negative integers. Note that these integer values cannot be larger than the dimensions of a tile. Tile types applies only to tiled content information. It is a sequence of integer values where each integer indicates the type of coding for the respective tiles in the content information. For the ODA Raster DAP , the types of tiles allowed are: null background, null foreground, T6 encoded, T6 encoded-MSB, and bitmap. If the tile types attribute is used (it is optional) , there must be an integer value for each tile. If it is not used, all tiles must be T.6 encoded. For the ODA Raster DAP, the tiles are always square and are 512 by 512 pels in size. 8.1.2 Content Information The content information is that part of the content portion description which is composed of the raster data, that is, the raster graphics content that is to be displayed. 22 ODA Constituents and Attributes The raster data is a pel array which is a two-dimensional array used to represent a pictorial image. It consists of pels or picture elements which make up the smallest graphic element that can be individually addressed within a picture. The pels have a defined order. The array consists of an ordered seguence of rows of picture elements. Each row in the array contains the same number of picture elements and consists of an ordered sequence of pels that represents a line of the image. In a tiled encoding of the content information, the pel array is segmented into a two dimensional array of non-overlapping rectangular regions called tiles. The content information of each tile is coded independently of the content information of the other tiles of the same pel array. See figure 14. The content information or pel array is represented by one of the following encoded schemes as discussed above: (1) T.6 encoding, (2) T.4 one dimensional encoding, (3) T.4 two dimensional encoding, (4) bitmap encoding, (5) tiled encoding, (6) T.6 encoding-MSB, (7) T.4 one dimensional encoding-MSB, or (8) T.4 two dimensional encoding- MSB. It is important that the type of coding attribute discussed earlier accurate identify which encoding scheme has been used for the content information otherwise decoders will not be able to properly decode the content information. 8.1.3 Alternative Representation The alternative representation attribute may contain an ASCII character string that may be displayed in lieu of the content information when a receiver is not capable of decoding and/or imaging the raster data. 8.2 Presentation of the Image There is a set of optional ODA presentation attributes which guide the format and appearance of the raster image on a display media. See figure 14 and section 11 for a detailed discussion on the relationship of these attributes. There are four alternatives for specifying the presentation attribute values. One alternative is to not specify any presentation attributes at all and let them default to those values specified in the base standard. That is, the document layout description does not reference any presentation attributes, either directly or indirectly through a presentation style. A second alternative is to specify the appropriate attributes directly in the applicable block layout object. 23 . . ODA Constituents and Attributes A third alternative is to specify the set of attributes in a separate presentation style object and then refer to that presentation style from the applicable block layout object. The fourth alternative is to use a combination of the two. That is, a document layout description references one of the presentation styles and then specifies its own specific attributes that may override some of those attributes in the referenced presentation style. An additional discussion on the relationship of presentation attributes, presentation styles, and other objects is in section 11, Technical Concepts. All of the presentation attributes and general information about presentation styles are discussed in the following paragraphs. 8.2.1 Presentation Attributes Content architecture class is an attribute which specifies the class of content contained in the content portion. It implicitly identifies a set of presentation attributes, control functions, and coding attributes which are applicable to that specific type of content. For example, raster graphics content requires a different set of attributes than does character content. For the ODA Raster DAP, this attribute will always contain an object identifier of {2 8272} designating the contents as raster 'formatted processable content architecture' Pel path specifies the direction of progression of successive pels along a line and is expressed as a direction relative to the horizontal axis of the page coordinate system. Pel path is one of two attributes used to reflect the proper viewing orientation of the image Line progression specifies the direction of progression of successive lines and is expressed as a direction relative to the pel path. Lines of pels are positioned such that the first pel to be positioned on each line falls on an imaginary line which passes through the initial point in the direction of line progression. Line progression along with pel path are the two attributes used to reflect the proper viewing orientation of the image. There are a possibility of eight different orientations. See section 11, Technical Concepts. Clipping is used to determine the subregion of the entire pel array, as described by the content portion, which is to be considered by the content layout and imaging processes. It consists of two coordinate pairs. The first pair specifies the 24 . ODA Constituents and Attributes first pel that is part of the selected array. The second pair specifies the last pel that is part of the selected array. Pel spacing specifies the distance between two adjacent pels along a line, in the direction of the pel path. Pel spacing is the distance measured using the Basic Measurement Unit (BMU) . There are 1200 BMUs per inch. Pel spacing is expressed as a ratio. Thus a pel spacing of 6/1 is a ratio of a distance of 6 BMUs to one pel interval. Since 6 BMUs/pel * (1 inch / 1200 BMUs) = (1 inch / 200 pels) , this corresponds to 200 pels per inch along the pel path direction. Spacing ratio is the ratio of line spacing to pel spacing. The normal situation is for the spaces between the pels along a line and between successive lines to be the same, i.e., a ratio of 1/1. The default value is 1/1. In those situations where the spacing between the pels in one direction is different from the spacing in the other direction, the spacing ratio may be used. The spacing ratio is synonymous with aspect ratio. 8.2.2 Presentation Style The presentation style is an optional constituent of the document which guides the format and appearance of the document content (raster image) . If present, it must be referred to from a block layout object. A style serves to group together sets of attributes which could alternately be applied directly and individually during the layout and imaging process. A presentation style contains an attribute, style identifier, which identifies the presentation style uniquely within the context of the document. It is a sequence of two non-negative integers, the first of which is always '5' to signify a presentation style constituent. Since a document may contain more than one presentation style, a second integer is used to uniquely identify each presentation style within the interchange document. The value selected for this second integer may be any non-negative value as long as the integer sequence (integer pair) is unique for each presentation style. All other constituents using a specific presentation style must reference it using the integer sequence corresponding to the style identifier for that presentation style. In this way, a specific block layout object may refer to the presentation style needed to lay out the corresponding raster image For example, a document may consist of six pages (containing six frames and specific blocks) requiring two different presentation styles. The first style would have an identifier of '5 0' and the second a '5 1'. Specific blocks 1 and 5 could reference style '5 25 ODA Constituents and Attributes 0' Whereas all of the other blocks 2 , 3, 4 , and 6 might reference style '51'. A block need not necessarily reference a presentation style. 8.3 Dociiment Layout structure To provide for a compound document, it must be capable of containing raster graphics, geometric (vector) graphics, and character content. ODA provides this capability through its document layout structure as illustrated in figure 6. Pages Frames Document Blocks Page Sets Figure 6 - ODA Layout Structure The document layout structure consists of a series of layout objects. Each layout object has an associated set of attributes which specifies how the document content is to be laid out and presented to the viewer. You will note from figure 6 that an ODA document structure may consist of page sets with each consisting of multiple pages. Pages are made up of any number of frames and frames are made up of any number of blocks. The ODA Raster DAP, however, has a simpler structure. See figure 7. For the ODA Raster DAP, the specific layout structure is a simple four-level hierarchy consisting of a document layout root. 26 ODA Constituents and Attributes composite basic page(s) , image frame, and specific block objects. See figures 7 and 8. The term "specific" is used to contrast with generic layout structure, an ODA feature omitted for simplicity from the ODA Raster DAP. Each of the layout object types has some attributes in common with other layout object types and some distinct attributes. The content information consisting of a raster graphics image, representing an engineering drawing, illustration, or other raster scanned image, can only be associated with a specific block. This content may contain either untiled or tiled raster graphics data. Figure 7 - ODA Layout Structure (ODA Raster DAP) 8.3.1 Dociunent Layout Root The document layout root is at the highest level of the hierarchy in a document layout structure. Its basic purpose is to identify the subordinate objects that exist at the second level of the hierarchy. For the ODA Raster DAP , these subordinates can only be a sequence of one or more composite pages. 8.3.2 Composite Page The composite page is a layout object that corresponds to the rectangular area representing the page and is used for presenting the raster image. 27 ODA Constituents and Attributes 8.3.3 Image Frame The image frame is a layout object that corresponds to the rectangular area within a page, For the ODA Raster DAP, there can be only one frame per page and the frame is coincident with the page. Figure 8 - Specific Layout Structure 8.3.4 Specific Block The specific block is a layout object that corresponds to the rectangular area within a frame. For the ODA Raster DAP, there can be only one block per frame. The block area will typically be synonymous with the area of the frame, however, the block area may be smaller than the frame area. This later case can be the situation when the clipping attribute is used. The dimensions and position attributes discussed later in this section are also used in this situation. The content portion may only be associated with a specific block. 8.3.5 Relationship Attributes and Layout Objects Figure 9 illustrates the layout structure and associated contents for an example document consisting of three composite pages. This illustration is used to describe several of the relationship 28 ODA Constituents and Attributes attributes that are discussed in the remainder of this section. Relationship attributes are used to describe the relationship between all of the objects contained in an interchange file. Figure 9 - Illustration of Layout Structure Every layout object must include an object type attribute which is an integer specifying the type of object as being either the root, page, frame, or block. The object type is then used to identify the set of attributes that may be specified for that respective object. Because of the hierarchical nature of the layout structure, every layout object must be identified with an attribute, object identifier, which identifies the object uniguely within the context of the document and within the layout hierarchy. An object 29 . ODA Constituents and Attributes identifier consists of a sequence of integers. Each integer in the sequence corresponds to a hierarchical level and identifies one particular object instance at that level. For the three page example in figure 9, the document layout root, the first level of the hierarchy, is always identified with a '1'. The object identifier for the second level of the hierarchy must include two integers separated by a space. For this example, the identifier on the first page contains a '1 O', the second page a '1 1', and the third page a '1 2'. The first integer in the sequence, '1', always indicates the object belongs to the specific document layout hierarchy. The second integer within the sequence uniquely identifies the page within that second level of the layout hierarchy, in other words, a 'O', '1', or '2' for pages 1, 2, or 3 respectively This same logic then applies in assigning object identifiers to frames and blocks. That is, the third integer is used to identify the frame within a page and the fourth integer to identify the block within a frame. Since there can be only a single frame and block to a page, the third and fourth integers are always zero. Using this scheme for the object identifier, every layout object in the document structure can be uniquely identified. No two objects will have the same identifier. The four levels of hierarchy create additional encoding that does not provide any material benefit for the ODA Raster DAP. However, the four levels are necessary in order to be upwards compatible with other DAPs. The document layout root additionally contains a relationship attribute, subordinates, which identifies the set of composite pages that are immediately subordinate to the document layout root. The value of this attribute is a sequence of one or more integers. Each integer corresponds to an immediately subordinate page. In our example, the value for subordinates would be '0 1 2' which corresponds to the second digit in the three composite page object identifiers. In other words, it identifies the pages 0, 1, and 2 as being subordinate to the root. The composite page and image block must also include the subordinates attribute. However, it will always be a single integer of zero(O). This is because there is only one frame per page and one block per frame; consequently, we will assign a value of zero to each of them. The specific block has a different relationship attribute, content portions, which functions similar to the subordinates attribute. 30 . ODA Constituents and Attributes It is used to specify which content portions are associated with the specific block. Since there is only one content portion associated with each block, this value will always be a zero (0) Although not a part of the layout description, the content portion must be associated with a specific block. This will be discussed at the end of this section. 8.3.6 Specific Layout Attributes Specific layout attributes are used to describe each specific layout object. An optional attribute on the composite page is medium type. It is used to specify the nominal (physical) page size of the output media. It specifies the rectangular size of the output media in both the horizontal and vertical directions without any allowances for border margins. Another optional attribute is dimensions which may be used on either the composite page or specific block objects. It specifies the rectangular size of the page or block, respectively, in both the horizontal and vertical directions and is specified in BMUs. The dimensions for a page should be, wherever possible, smaller than the nominal page size to allow for unused border space. In the ODA Raster DAP, the dimensions of the frame cannot be specified and the values default to the page dimensions. Similarly, if the block dimensions are not specified, the block dimensions default to the frame/page dimensions. When both page and block dimensions are present, the block dimensions may be smaller but not larger than the page dimensions. Another optional attribute is page position which specifies the location on the nominal page to position the page. It also is specified in BMUs. The page position can only be used on the page layout object. If the page size dimensions are the same as the nominal page size, then the page position should be zero (0) so that the edge of the page and the edge of the nominal page coincide. If the page size is smaller than the nominal page size, then a page position value should be selected that provides approximately equal margins (border space) in the vertical direction and equal margins in the horizontal direction. IS 8613- 2, clause 7.3, describes the general rules for positioning pages on the media. Another optional attribute for the specific block is position which specifies the location of the block within the frame. This is the location to start laying out the raster graphics content. It also 31 ODA Constituents and Attributes is specified in BMUs. It is particularly useful in conjunction with the clipping attribute. The optional application comments may be used when the content contains tiled raster graphics data. It contains a sequence of positive integers, one for each tile in the content portion. The sequence of integers is a set of indices representing the octet offsets to the beginning of the respective tiles, starting from the beginning of the content information. The offsets will be sequenced in the same order as the tiles. Other optional attributes associated with the layout objects are: presentation style (specific block only) , user visible name, and user readable comments. The presentation style was discussed earlier. It contains the identifier, i.e., '5 O', linking it to a specific presentation style constituent previously defined in the document. The user visible name and user readable comments are textual information attributes and are permitted on all layout objects. 8.4 Document Profile The document profile consist of a set of attributes which specifies the characteristics of the document as a whole. Some of these characteristics include: the DAP identifier, class of the specific document, basic structure of the document, and default values for attributes if they differ from the IS 8613 default values. Many of the attributes in the document profile are also used in other constituents but their use in the document profile is in a different context. The relationships between the use of these attributes in different constituents will be explained. Some of the attributes are mandatory and others are optional ("non-mandatory") . The attributes applicable to the document profile are defined for easy reference in Table 1 at the end of this section. This table is a copy of Table D.3 from the ODA Raster DAP. In the discussion that follows, each of the attributes from Table 1 is defined and described in the order in which it appears in the table. If it is desired to use a default value for any given attribute other than the normal ODA default value, the default value must be specified in the document profile. Otherwise, the only default available for that attribute would be that default value specified in IS 8613. 32 ODA Constituents and Attributes 8.4.1 General Attributes Specific layout structure: An attribute used if and only if the document contains any specific layout descriptions. It specifies that specific layout objects are 'present' in the document. For the ODA Raster DAP, there will always be layout object descriptions so this attribute must always be present. Presentation styles: An attribute used if and only if the document contains any presentation style constituents, that is, the presentation style (s) is (are) 'present' in the document. 8.4.2 Document Characteristics The document characteristics are a set of attributes which describes the characteristics of the document. Most of the attributes in the document profile are included within this set. Document architecture class: An attribute which specifies the architecture class of the document. For the ODA Raster DAP, this can only be the 'formatted' form which facilitates the reproduction of a document exactly as intended by the originator. Document application profile: An attribute which specifies the Document Application Profile (DAP) that pertains to the document. Each DAP is assigned a unique identifier. This identifier is a number registered with the appropriate authorities to distinguish this DAP from any other. The object identifier assigned to the ODA Raster DAP is {1 3 14 11 1 1}. AIIM is using an object identifier of {1 2 840 10012}. Content architecture classes: An attribute which specifies the different classes of content allowed in the document. For the ODA Raster DAP, only 'formatted processable raster content' is permitted. This is content (raster data) which carries some of the formatting intentions of the originator, but which still contains enough of the original information to be further manipulated by the receiving party. Interchange format class: An attribute which specifies one of two types of Office Document Interchange Formats (ODIF) to be used, either 'A' or 'B'. Only class 'A' is permitted in the ODA Raster DAP. This means that the order of the constituents is as follows: document profile, presentation styles (optional) , layout objects, and content portions, see figure 1. The rules for using each class and specifying the order of the data stream are defined in IS 8613-5, clause 5. 33 ODA Constituents and Attributes ODA version: An attribute identifying the standard and version to which the document conforms. For the ODA Raster DAP, the values are 'ISO 8613' and '1991-12-31', respectively. Document architecture defaults: A set of attributes that specifies the default attribute values for the document if the values are to be different from the default values specified in IS 8613. The attributes in this set are listed below: Content architecture class: An attribute which specifies the default value for the contents of the document. IS 8613 specifies the default value as 'formatted character content architecture' which is not allowed in the ODA Raster DAP. This value has no meaning in the context of raster data. Therefore, the ODA Raster DAP has specified that this attribute is mandatory and the value must be an object identifier of {2 8 2 7 2} for raster 'formatted processable content architecture'. Type of coding: This attribute is mandatory. The default encoding specified in IS 8613-7 for raster graphics data is 'T.6 encoding' which is the up bit order. MIL-R-28002B only allows down bit order for encoding of T.6 data and therefore does not allow the DAP permitted 'T.6 encoding' value. If the default encoding for the document is to be tiled raster data, then this attribute will contain a value of 'tiled encoding'. If the default encoding for the document is to be T.6 encoding in the down bit order, then the value will be 'T.6 encoding - MSB'. The DAP does not allow the less useful default of 'bitmap encoding' to be applied to the entire document. Page dimensions: An attribute which specifies the default value of the "dimensions" attribute for the page layout object. This attribute must be specified only if the default is to be a value other than NA-A size page. Mediiim types: An attribute which specifies the default value of the "medium type" (nominal page size) attribute used in the document. This attribute must be specified only if the default is to be a value other than NA-A size page. Page position: An attribute which specifies the default value of the "page position" attribute used in the document. Clause 7.3 of IS 8613-2 describes the rules for positioning pages on presentation surfaces. 34 ODA Constituents and Attributes 8. 4. 2.1 Raster Graphics Content Defaults Raster graphics content defaults is a set of attributes which specifies the default attribute values for the specific raster graphics content within the document if the values are to be different from the values specified in IS 8613-7. None of the attributes in this set are mandatory. The ODA Raster DAP allows the use of five attributes: Pel path: The normal default is 0 degrees, it must be specified if the default is to be 90, 180, or 270 degrees. Line progression: The normal default is 270 degrees, it must be specified if the default is to be 90 degrees. Pel spacing: The normal default is 4 BMUs (300 pels/in.), it must be specified if the default is to be 16, 12, 8, 6, 5, 3, 2, or 1 BMU. Spacing ratio: The normal default value is 1/1, it must be specified if the default is to be other than 1/1. Compression: The normal default value is 'compressed'. This should be the normal situation. It must be specified as 'uncompressed' if the default is to allow the T.6 algorithm to escape to the uncompressed mode. MIL-R-28002B has specified that the 'uncompressed' mode will never be used, therefore this attribute is not used within DoD. 8. 4. 2. 2 Non-basic Document Characteristics The non-basic document characteristics is a set of attributes used to specify the attribute values for the specific document if the values are non-basic. A non-basic value is a value for an attribute that is only allowed by the governing DAP (in this case the ODA Raster DAP) to appear in the document interchange if its use is declared in the document profile. All vendors supporting the DAP would commonly be expected to support all the basic values, but vendors may not commonly be expected to support the non-basic values. Before processing a document, a receiving implementation should look at the non-basic document characteristics to ensure that it can continue processing the document. For example, a fall- back procedure might be invoked rather than simply quitting, e.g., displaying an image at half-size. The specification of the values of the attributes in this set is mandatory only if non-basic values are to be used. For the ODA Raster DAP, the allowable attributes are: page dimensions, medium types, pel path, line progression, pel spacing, and compression. 35 ODA Constituents and Attributes Note that the pel path, line progression, pel spacing, and compression attributes are grouped within a set called Raster Graphics Presentation Defaults. The medium types attribute must always be specified. There are no basic values. Table 1 and the technical specifications of the DAP show this attribute as being non-mandatory (permitted) . However, the text (section 6) and a comment in the technical specifications (section 7) indicate that all nominal page sizes must be identified as non-basic values. This approach was taken in the ODA Raster DAP to be consistent with other international standard profiles. If the image size is larger than the North American A size (spelled out as basic in the DAP) , then the page dimensions attribute has to be declared in this section of the document profile. Any user's choice of an image size up to NA-A size is declared as basic in the DAP. If a pel path of 180 or 270 degrees is to be used, then pel path will have to be included in this section of the document profile. If a line progression of 90 degrees is to be used, then line progression will have to be included. If a pel spacing of other than 16, 12, 8, 6, 5, 4, 3, 2, or 1 BMU is to be used, then pel spacing will also have to be included in this section of the document profile. If the uncompressed mode of the T.6 algorithm is to be used within the encoded data, the compression attribute must be included in the document profile with a value of 'uncompressed'. This is not applicable to MIL-R-28002B. 8.4.3 Document Reference Attribute The dociuaent reference attribute contains a character string and is used to identify the document. It is the only attribute out of a set of document management attributes that is permitted for use in the ODA Raster DAP. 8.4.4 Summary In summary, the document profile has several attributes that may be used. Many of them are optional and defaultable so they do not always need to be specified. Table 1 contains the complete list of 36 ODA Constituents and Attributes these attributes. The following notation is used in the class column of this table: m mandatory attribute nm non-mandatory attribute d defaultable attribute Capital letters (M, NM, and D) are used for groups of attributes. 8.5 Relationship of Objects As stated earlier, the document profile must occur first in the interchange and it will occur only once. It will be followed by the presentation styles (if present) , document layout descriptions, and then the content portion descriptions. See figure 1. Because the presentation styles, document layout descriptions, and content portion descriptions may have multiple occurrences in the interchange file, the relationship identifiers play an extremely important role in uniquely identifying each of the objects. The object identifier in the document layout descriptions, the style identifier in the presentation styles, and the content identifier layout in the content portions are used for this purpose. They all consist of a sequence of non-negative integers as previously discussed. The style identifier consists of two integers with the first being a five and the second uniquely identifying the presentation style. The object identifier and content identifier layout all start with a one as depicted in figure 9. There is only one document layout root but all other objects have a second integer which uniquely identifies the page in the document. The number of integers making up the remainder of the identifier depends upon the level of the object in the hierarchy but will always be zeros for the ODA Raster DAP. Note that although the content portion is not considered a part of the document layout description, the structure of content identifier layout is the same as the structure of the object identifier, it has one more integer than the specific block. This is done so that each content portion can be uniquely assigned to a specific block in the document layout description. 37 ODA Constituents and Attributes Table 1 - Document profile attributes Attribute Class Permissible values Specific-layout-structure m present Presentation-styles nm present Document-characteristics M Document-architecture-class m formatted Document-application-profile m {131411 1 1} Content-architecture-classes m {2 8 2 7 2} Interchange-format-class m A ODA-version m ISO 8613, 1991-12-31 Document-architecture-defaults M Content-architecture-class m formatted processable raster graphics Type-of-coding m T.6 encoding, tiled encoding, T.6 encoding - MSB Page-dimensions nm See list in table 1 of ODA Raster DAP, (Default value is NA-A, 9240 x 13200 BMU) Medium-types nm See list in table 1 if ODA Raster DAP, (Default value is NA-A, 9240 x 13200 BMU) Page-position nm any coordinate pair within page (normal default is 0,0) Raster-gr-content-defaults NM Pel-path nm 0, 90, 180, 270 degrees (0 is normal default) Line-progression nm 90, 270 degrees (270 is normal default) Pel-spacing nm 16, 12, 8, 6 5, 4, 3, 2, 1 BMU, (Normal default is 4 BMU) Spacing Ratio nm Any value (normal default is 1/1) Non-basic-doc-characteristics NM Page-dimensions nm See table 1 in ODA Raster DAP Medium-types nm See table 1 in ODA Raster DAP 38 ODA Constituents and Attributes Table 1 - Document profile attributes (concluded) Attribute Class Permissible values Raster-gr-presentation-features NM Pel-path nm 1 80, 270 degrees Line-progression nm 90 degrees Pel-spacing nm Any value except 16, 12, 8, 6, 5, 4, 3, 2, or 1 BMU Document-management-attributes M Document Reference m Any string of characters 39 9 Technical Specification in the DAP 9.1 Genealogy The ODA Raster DAP was created by direct reference to CCITT T.503 [3], an extremely simple DAP which allows only a single piece of T.6 encoded raster content. Its simple structure formed an appropriate basis for the ODA Raster DAP. 9.2 Simplifications Many unnecessary items found in more fully-featured DAPs were intentionally left out. Primary among these items are elements of logical structure such as descriptions which allow for chapters, sections, and paragraphs. The layout structure of page sets was also omitted. 9.3 DAP Narrowed by MIL-R-28002B Although some parameters in the DAP allow for great flexibility, several of these are further limited by MIL-R-28002B. For example, the DAP follows the ODA convention that specifies a default pel spacing of 4 Basic Measurement Units (BMUs) . This equates to 300 pels per inch. MIL-R-28002B requires 300 pels per inch for technical manuals and illustrations, but 2 00 pels per inch for large-format engineering drawings. This means that the defaulting mechanism inherent in the DAP cannot be used with engineering drawing scans. MIL-R-28002B requires systems to export images with sizes which are multiples of eight; the DAP has no similar restriction. Using a checklist in MIL-R-28002B, other parameters are left to the determination of the contracting officer and may be narrowed by restrictive language in the contract document. These could include disallowing bitmapped tiles except in the case of reverse compression, requiring rotation of the image to proper viewing orientation (rather than merely describing the proper viewing orientation) , and requiring the zeroing of the unused portions of tiles. These issues are further considered in the Technical Concepts section. (See also MIL-R-28002B section 6.2.) The DAP uses the notion of pel spacing rather than pels per unit length (the reciprocal) . The pel spacing is thus a distance measured using the unit BMU (basic measurement unit) . There are 1200 BMUs per inch. Pel spacing is expressed as a ratio, rather than simply as a number. A pel spacing of 6/1 is a ratio of a distance of 6 BMUs to one pel interval. Since 6 * (1/1200) = (1/200) , this corresponds to 200 pels per inch. 40 . . Technical Specification In the DAP 9 . 4 Proforma and Notation The proforma and notation for ODA DAPs is defined in Annex F of IS 8613-1. It describes in detail the format for a DAP. It also specifies a meta-language to be used in writing a DAP, specifically the technical specifications in section 7 of the ODA Raster DAP. The meta-language may be thought of as a higher level language similar to the high level programming languages such as COBOL, Pascal, etc. The ASN.l Definitions may be thought of more like a lower level assembly programming language. However, in either case, the meta-language and ASN.l Definitions define the structure of the Raster Interchange Format (RIF) The intended purpose of using the proforma and notation is to aid clarity and remove ambiguity, ensure that all necessary information is included, aid comparison between DAPs, and aid verification and conformance testing. As verification and conformance testing of the DAP proceeds, section 7 of the DAP may have to be revised. The following discussion of the section 7 is intended to provide general guidance on proforma and notation, not a detailed tutorial. As experience grows in using proforma notation, verification, and conformance testing, this section may be expanded. The following terms are used in document application profiles. They are the reserved keywords of the DAP proforma and notation. Their definitions, as found in Annex F, are: REQ Required. PERM Permitted. DIS Disallowed. DEFINE Defines a macro. MUL A group of parameters that may be repetitive. PMUL A group of parameters that may be optional. SPECIFIC: Announces attributes specified for objects FACTOR: Announces a common set of constraints. $ Begins a macro invocation. { } Used as a pair of symbols to delimit a syntactical unit or grouping. {ANY_VALUE} Any attribute or parameter value permitted by IS 8613. # Indicates parameter or control function name. [•] Indicates an optional syntactic item. 41 , Technical Specification in the DAP 9.5 Elements of the DAP The remainder of this section of the tutorial discusses a technical view of the different elements of the DAP and how they arise from the standards. A DAP Technical Specification section is an unambiguous definition that can be read by automated systems such as compilers and test suites. These suites could check for consistency and implementability of the DAP. This is the objective of the ODA Conformance Test (ODA-CT ) a testing tool developed jointly by the Canadian Department of Communications, the United Kingdom National Computing Center, and Japan's Interoperability Technology Association for Information Processing (INTAP) . ODA-CT will also check ODA Office Document Interchange Format (ODIF) data streams for conformance to IS 8613. 9.6 Format of DAP Technical Specification Section In section 7 of the DAP, there is a description for each type of constituent that is allowed in a document conforming to the DAP. Each description may include three primary elements of information: macro definitions, factor constraints, and constituent constraints. Macro definitions provide a shorthand mechanism for use later in the notation. Factor constraints describe the attributes and their associated values which apply to all constituents within that specific category, i.e., factor constraints for the layout structure apply to all the layout objects. Constituent constraints describe the attributes and their associated values which apply specifically to each constituent in that category, i.e., for the layout structure, there is a constituent constraint for each of the document layout objects. 9.7 DAP Technical Specification All of the DAP notations and name references below in the smaller font illustrate examples extracted directly from the ODA Raster DAP. Much of the detailed discussion concerning the constituents and associated attributes was done in the earlier section, ODA Constituents and Attributes, and will not be repeated in this section. Again, the order of the discussion that follows has been chosen to help those with raster graphics related background by starting with an area that they are probably already familiar with. 42 Technical Specification in the DAP 9.7.1 Content Portion Constraints The content portion constraints section shown below (extracted from section 7.6 of the ODA Raster DAP) describes the content portion. The Raster-graphics-content-portion describes the content portion description. The Content-identifier-layout is a required attribute consisting of five integers as discussed in section 8 of this document. The {ANY VALUE} means any value permitted by ISO 8613. Type-of-coding is optional but when used must be one of the listed ASN.l object identifiers. The default value is 'T.6 encoding' (down bit order) unless specified differently in the document profile. Raster-graphics-content-portion { REQ Content-identifier-layout {ANY_VALUE}, “ - PERM Type-of-coding { ASN.1{2 8 3 7 0} T.6 encoding ASN.1{2 8 3 7 - T.4 one dimensional - I 1} ASN.1{2 8 3 7 - T.4 two dimensional -- I 2} ASN.1{2 8 3 7 - bitmap encoding -- I 3} ASN.1{2 8 3 7 - tiled encoding — 1 5} ASN.1{2 8 3 7 - T.6 encoding - MSB — I 6} ASN.1{2 8 3 7 - T.4 one dimensional - MSB - 1 7} ASN.1{2 8 3 7 - T.4 two dimensional - MSB - 1 8} h PERM Coding-attributes { REQ #raster-graphics-coding-attributes { PERM #compression {ANY VALUE}, PERM #number-of-lines {>0}/ REQ #number-of-pels-per-line {>0}» CASE Raster-graphics-content-portion (Type-of-coding) QF { {$TILED}: (PERM #number-of-pels-per-tile-line {512}, PERM #number-of-lines-per-tile {512}, PERM #tiling-offset {ANYVALUE}, PERM #tile-types {'null background' | 'null foreground' | 'T.6 encoded' | 'bitmap encoded' | 'T.6 encoded - MSB'}}}}, PERM Alternative-representation {ANY_STRING}, PERM Content-information {RASTER} } The Coding-attributes for raster graphics always requires the number-of-pels-per-line attribute and it must always be greater than zero. The compression and number-of-lines attributes are permitted at any time. 43 . , Technical Specification in the DAP The compression attribute is not permitted in MIL-R-28002B. The pound (#) character in front of the attributes is used by the DAP notation to indicate that it is a parameter. For purposes of this tutorial, only the attribute term is used. The CASE structure indicates that the number-of-pels-per-tile-line number-of-lines-per-tile , tiling-offset, and tile-types attributes are permitted when Type-of-coding is 'ASN.1{2 8 3 7 5}'. Note that the CASE structure references the macro TILED which was defined in the paragraph 7 . 6 of the DAP as: DEFINEITILED," ASN.l {2 8 3 7 5}") . The number-of-pels-per-tile-line, and number-of-lines-per-tile, if specified, can only contain the value of 512 which is the default value specified in ISO 8613-7. Consequently, these attributes never need to be specified. For the tile-types attribute, any one of the five listed values is allowed. The raster data is contained in the Content-information. Although it is shown as permitted, it is not logical to omit the raster image from the interchange. The Alternative-representation attribute is permitted and may contain an ASCII character string for display by a receiver if the raster image cannot be displayed. 9.7.2 Presentation Style Constraints The Factor Constraints description, FACTOR shown below, specifies the attributes and their associated values that apply to any of the presentation style constituents, ANY-PRESENTATION-STYLE, regardless of the number of occurrences that may exist in the interchange file. The Presentation-style-identifier attribute is always required and consists of a sequence of integers as discussed in the earlier section, ODA Constituents and Attributes. FACTOR ANY-PRESENTATION-STYLE { REQ Presentation-style-identifier {ANYVALUE}, PERM User-readable-comments {ANY STRING}, PERM User-visible-name {ANY_STR1NG} } The PStyle description (shown below) specifies the attributes and their associated values that apply to only raster presentation style constituents. It contains any of the factor constraints listed above in the ANY-PRESENTATION-STYLE plus any of the raster graphics Presentation-attributes; pel-path, line-progression, pel-spacing, spacing-ratio, clipping 44 Technical Specification in the DAP PStyle: ANY-PRESENTATION-STYLE { PERM Presentation-attributes { PERM #raster-graphics-attributes { PERM #pel-path {ANY_VALUE}, PERM ^line-progression {ANY_VALUE}, PERM #pel-spacing {REQ ^length {ANY_VALUE}, REQ #pel-spaces {ANY VALUE}}, PERM #spacing-ratio {REQ #line-spacing-value {ANY VALUE}, REQ #pel-spacing-value {ANY_VALUE}}, PERM ^clipping {ANY_VALUE}}} } 9 . 7.3 Layout Constituent Constraints A single macro definition is defined and referenced within the specific block. DEFINEIRAST," CQNTENT_ID_QF(Raster-graphics-content-portion)") The FACTQR in the case below describes the attributes that may be specified in ANY-LAYQUT. The Qbject-identifier is required, the values consist of a sequence of integers and were described in the ODA Constituents and Attributes section. The Qbject-type attribute shows a value of VIRTUAL which means its value is specified in a later constraint, e.g., DocumentLayoutRoot, CompositePage, ImageFrame , and SpecificBlock. FACTQR ANY-LAYQUT { SPECIFIC: PERM Qbject-type {VIRTUAL}, REQ Qbject-identifier {ANYVALUE}, PERM Subordinates {VIRTUAL}, PERM User-visible-name {ANYVALUE}, PERM User-readable-comments {ANYVALUE} } In the DocumentLayoutRoot, the Qbject-type attribute identifies the object as a document-layout-root. The Subordinates identifier is used to uniquely identify each page under the DocumentLayoutRoot. The plus sign indicates an incrementing subordinate identifier is associated with each succeeding page. 45 } Technical Specification in the DAP DocumentLayoutRoot: ANY-LAYOUT { SPECIFIC: REQ Object-type { 'document-layout-root'}, REQ Subordinates {SUBJD_OF(CompositePage) -i- } In the CompositePage , the Object-type attribute identifies the object as a page. The Subordinates attribute operates basically the same as above except it identifies the frame associated with the page. Note that there is not a plus sign, so there can be only one frame per page. The CompositePage includes additional attributes for describing the page, e.g.. Dimensions, Page-position, and Medium-type. The Dimensions attribute uses a macro PermissiblePageDimensions which is defined in the document profile. CompositePage: ANY-LAYOUT { SPECIFIC: REO Object-type {'page'}, REQ Subordinates {SUBJDOFdmageFrame)}, PERM Dimensions {$ PermissiblePageDimensions}, PERM Page-position {ANY_VALUE}, PERM Medium-type {PERM #nominal-page-size {$NominalPageSizes}, PERM #side-of-sheet {ANY_VALUE}}, PERM Application-comments {ANY_VALUE} } ImageFrame: ANY-LAYOUT { SPECIFIC: REQ Object-type {'frame'}, REQ Subordinates {SUB_ID_OF(SpecificBlock)}, PERM Application-comments {ANY_VALUE} } The SpecificBlock refers to two macros, RAST and Content-architecture-class which are defined in the content portion and document profile, respectively. The Position and Dimensions attributes describe the positioning and size characteristics of the block within the frame. Note that presentation attributes may be specified by either of two alternatives. The attributes could be listed directly in the block or there could be a reference to a presentation style. It is even possible to have both. An implementor could refer to a presentation style which specifies certain characteristics for presenting the image. In turn, there could be a specific presentation attribute in the block which overrides the same 46 . Technical Specification In the DAP attribute in the presentation style. This does make the encoding more complex but does allow for greater flexibility. SpecificBlock { SPECIFIC: REQ Object-type {'block'}, REQ Object-identifier {ANY_VALUE}, REQ Content-portions {$RAST}, PERM Position {REQ #fixed-position { REQ ^horizontal-position {ANY VALUE}, REQ #vertical-position {ANY_VALUE}}}, PERM Dimensions {REQ ^horizontal-dimension {REQ #fixed-dimension {ANY VALUE}}, REQ #vertical-dimension {REQ #fixed-dimension {ANY_VALUE}}}, PERM Content-architecture-class {$FPR}, PERM User-readable-comments {ANY_STRING}, PERM User-visible-name {ANY_STRING}, PERM Application-comments {ANYVALUE}, PERM Presentation-style {STYLEJD_OF(PStyle)}, PERM Presentation-attributes { PERM #raster-graphics-attributes { PERM #pel-path {ANY_VALUE}, PERM #line-progression {ANY_VALUE}, PERM #pel-spacing {REQ ^length {ANY VALUE}, REQ #pel-spaces {ANY_VALUE}}, PERM #spacing-ratio {REQ #line-spacing-value {ANY_VALUE}, REQ #pel-spacing-value {ANY VALUE}}, PERM ^clipping {ANYVALUE}}} 9.7.4 Doctment Profile Constraints At this point, practically every DAP proforma and notation construct used in the ODA Raster DAP has been discussed above. Therefore, the document profile constraints are not shown in this tutorial It might be worth discussing four macros: BasicPageDimension, NonBasicPageDimensions , PermissiblePageDimensions, and NominalPageSizes. The BasicPageDimension macro identifies the range of allowable basic values (up to ISO AO and NA A) for the page dimensions. The NonBasicPageDimensions (only a partial list included in this document) identifies the range of allowable non-basic values (larger than ISO AO and NA A size) for the page dimensions. The PermissiblePageDimensions macro identifies the total range of permissible page sizes. The 47 .• Technical Specification In the DAP NominalPageSizes macro identifies actual nominal page sizes permitted by the ODA Raster DAP. DEFINEIBasicPageDimension," REQ #horizontal-dimension {REQ #fixed-dimension { 1..9240 }}, REQ #vertical-dimension {REQ #fixed-dimension { 1.. 12400 }} REQ ^horizontal-dimension {REQ ^fixed-dimension 1.. 12400 I { }}, REQ #vertical-dimension {REQ #fixed-dimension { 1..9240 }} DEFINEINonBasicPageDimensions," {REQ ^horizontal-dimension {REQ #fixed-dimension {1.. 39680}}, REQ #vertical-dimension {REQ #fixed-dimension {1 2401 ..561 20}}} {REQ ^horizontal-dimension {REQ #fixed-dimension {9241 ..39680}}, I REQ #vertical-dimension {REQ #fixed-dimension {1.. 561 20}}} - up to ISQ AO portrait -- ... etc DEFINE(PermissiblePageDimensions," {REQ #horizontal-dimension {REQ #fixed-dimension {1.. 39680}}, REQ #vertical-dimension {REQ #fixed-dimension {1.. 561 20}}} - up to ISQ AO portrait -- • • • etc DEFINEINominalPageSizes," REQ ^horizontal-dimension {7015}, REQ #vertical-dimension {9920} - ISQ A5 Portrait - ... etc 48 . . . 10 ASN.l Coding Concepts 10.1 ASN.l Notation ASN.l provides a very formal and rigidly defined notation for describing protocols and standards. A good working knowledge of ASN.l and the Basic Encoding Rules is essential to a successful implementation of the ODA Raster DAP encoding or decoding program at least until more ODA tools become available. ASN.l is a formal description language based on the concept of tags, data types, and values for those types. All objects to be interchanged are either primitive or constructed data types. Primitive types are simple elementary types such as an integer or octet string. Constructed types are those that have been built up from various simple types or other constructed types. A large set of predefined data types exists and application specific ones may be created. ASN.l provides powerful mechanisms for expressing the restriction of types to other types or to ranges of values. Recursive definitions are permitted. It would seem possible to implement the ODA Raster DAP in several ways: (1) compile section 7 of the DAP with a "DAP Compiler", which directly generates C code from the DAP (nothing like this is known to exist), (2) compile the ASN.l Definitions describing the DAP into C code using an ASN.l compiler (these do exist), or (3) directly write C code or use any other programming language to implement the structures in the ASN.l Definitions describing the DAP. It should be noted that there are certain semantical descriptions in the DAP that are not present in the ASN.l Definitions; therefore, these semantical meanings are lost when using an ASN.l compiler versus a DAP compiler. Similarly, when generating C code versus using an ASN.l compiler, some of the rigidity and restrictions may be lost if the implementor is not careful 10.2 Sample of ASN.l Definitions The following discussion is based upon the ASN.l Definitions which represent the source statements for the implementation of the ODA Raster DAP. The entire listing of the ASN.l Definitions appears in ASN.l Definitions, Appendix A. Excerpts are included below to aid in the discussion. Comments may be used in ASN.l and are identified with a double hyphen ( — ) This tutorial also uses additional comments which are interspersed within the ASN.l Definitions and appear in a different font 49 ASN.l Coding Concepts Any set of ASN.l Definitions must be enclosed within an ASN.l shell structure as follows. Rif-Module DEFINITIONS :: = BEGIN -- ASN.l Definitions for a module called Rif-module. END The Rif-module, Raster Interchange Format module, is the name given to this particular set of ASN.l definitions. All of the definitions must be within the BEGIN and END block. The first group of definitions list the allowable objects, called Interchange Data Elements, that may be selected. Rif-Module DEFINITIONS :: = BEGIN Interchange-Data-Element ::= CHOICE { document-profile [0] IMPLICIT Document-Profile-Descriptor, layout-object [2] IMPLICIT Layout-Object-Descriptor, content-portion [3] IMPLICIT Text-Unit, presentation-style [7] IMPLICIT Presentation-Style-Descriptor } An interchanged document can consist of several Interchange-Data-Element objects. Which and how many of them are used will depend upon the contents of the specific document. For the ODA Raster DAP, a single page document requires the selection of a document-profile, optionally a presentation-style, the layout-object four times (once each for document layout root, composite page, image frame, and specific block) , and a content-portion. All of these objects to be interchanged are further defined as constructed (built up of other types) . The Rif-Module itself is the first such object definition which is a constructed type. It begins with a DEFINITIONS ::= and is contained within a BEGIN ... END block. The Rif-Module has the rules to create each interchange data element that the DAP might specify. For this reason, it is a CHOICE. A different recipe applies depending on which type of item is to be interchanged next. Each choice must be uniquely tagged, and is identified with a number in brackets. For example, the document-profile has a tag of zero [0] whereas the content-portion has a tag of three (3). The content-portion is further defined by a reference to Text-Unit. 50 ASN . 1 Coding Concepts Text-Unit :;= SEQUENCE { content-portion-attributes Content-Portion-Attributes OPTIONAL, content-information Content-Information OPTIONAL } The Text Unit is a SEQUENCE consisting of the items within the braces. The order must be preserved, that is, content-portion-attributes comes first followed by content-information. In a sequence, there does not need to be any tags. Among those items, the ones listed as OPTIONAL are not mandatory. The content-information is further defined by Content-Information (below) which is a CHOICE between one-octet-string or seq-octet-string . The one-octet-string is a primitive of OCTET STRING. This octet string is designed to contain an untiled raster image. The seq-octet-string is a SEQUENCE OF OCTET STRINGS where each octet string will contain a single tile of the raster image. Content-Information ::= CHOICE { one-octet-string OCTET STRING, seq-octet-string SEQUENCE OF OCTET STRING } In returning to the Text-Unit to examine the Content-Portion-Attributes, we can see that it is a SET (below) . That means that the items within braces may occur in any order. Content-Portion-Attributes ::= SET{ content-identifier-layout Content-Portion-Identifier OPTIONAL, type-of-coding Type-Of-Coding OPTIONAL, coding-attributes CHOICE { raster-gr-coding-attributes [2] IMPLICIT Raster-Gr-Coding-Attributes, alternative-representation [3] IMPLICIT Alternative-Representation } OPTIONAL } The content-identifier-layout is further defined by Content-Portion-Identifier and the type-of-coding by Type-Of-Coding . The coding-attributes must be a CHOICE between raster-gr-coding-attributes or alternative-representation which have tags of [2] and [3], respectively. IMPLICIT is a keyword which saves space when the data is reduced to bytes in the encoding process. It indicates that in building the tag for a given object, the type for the object is not needed. Content-Portion-Identifier ;:= [APPLICATION 0] IMPLICIT PrintableString The Content-Portion-Identifier is a primitive (simple, elementary) type that is not further defined. It is specifically defined for the ODA application as a printable string. 51 . . . ASN . 1 Coding Concepts ::= Type-Of-Coding CHOICE { other-coding [6] IMPLICIT OBJECT IDENTIFIER {2 8 3 7 0} 'T6 encoding' ” or {2 8 3 7 1} 'T4 one dimensional encoding' ” or (2 8 3 7 2} 'T4 two dimensional encoding' “ or {2 8 3 7 3} 'bitmap encoding' - or {2 8 3 7 5} 'tiled encoding' " or {2 8 3 7 6} 'T6 encoding - MSB' - or {2 8 3 7 7} 'T4 one dimensional encoding - MSB' ” or {2 8 3 7 8} 'T4 two dimensional encoding - MSB' } The Type-Of-Coding is also another primitive type. In this case, it is a CHOICE between one of the object identifiers which determines the type of encoding of the content information (raster image) Raster-Gr-Coding-Attributes SET { number-of-pels-per-line [0] IMPLICIT INTEGER OPTIONAL, number-of-lines [1] IMPLICIT INTEGER OPTIONAL, compression [2] IMPLICIT Compression OPTIONAL, - number-of-pels-per-tile-line [6] IMPLICIT INTEGER OPTIONAL, number-of-pels-per-tile-line is always a constant 512 - number-of-lines-per-tile [7] IMPLICIT INTEGER OPTIONAL, number-of-lines-per-tile is always a constant 512 tiling-offset [8] IMPLICIT Coordinate-Pair OPTIONAL, tile-types [9] IMPLICIT SEQUENCE OF Tile-Type OPTIONAL } The Raster-Gr-Coding-Attributes structure type defines all of the raster graphics coding attributes. Note that the number-of-pels-per-line and number-of-lines are primitive types of INTEGER. The tile-types is a sequence of Tile-Type. Each Tile-Type is an integer value (below) The allowable values are 0, 1 , 2 , 5 , or 6 Tile-Type INTEGER null-background (0), null-foreground (1), encoded-t6 (2), bitmap (5), encoded-t6-msb (6) - } T.4 not supported in tiled encoding There is one other definition that has not been discussed and that is the enumerated data name. This is illustrated by the document- architecture-class (below) within the Document-Characteristics of the Document- 52 . ASN.l Coding Concepts Profile-Descriptor, The code that follows describes the usage formatted (0) for document-architecture-class. This indicates that the interchanged value is a zero, but that zero is simply the defined representation for the formatted type of document architecture class. The word 'formatted' is used in ODA ASN.l Definitions as an enumerated data name. The data stream will contain an integer with the value of zero (0) which signifies that it is a formatted document. document-architecture-class [1] IMPLICIT INTEGER { formatted (0)} OPTIONAL All of the other ASN.l Definitions use the same basic data types as those discussed above. For a complete list of the ASN.l Definitions for the ODA Raster DAP, refer to Appendix A. 10.3 The Basic Encoding Rules The Basic Encoding Rules define one way to actually encode ASN.l objects into binary values for interchange (transfer values) using a syntax called Office Document Interchange Format (ODIF) . ODA permits other encoding rules to be used. The Basic Encoding Rules are the only rules discussed in this document. A detailed understanding of the Basic Encoding Rules is not required to understand the ODA Raster DAP. In fact, users of a library of ASN.l routines would probably never need to understand encodings at the bit or byte level. Only a programmer of elemental ASN.l input and output routines would need such a detailed understanding. These individuals should refer directly to ASN.l (IS 8824) and Basic Encoding Rules (IS 8825) standards to assure a proper implementation. This section provides a brief introduction to the Basic Encoding Rules. The key idea is that these codes are best left to programs to read and write. One would not wish to read a business letter by viewing hexadecimal ASCII codes; one would use a word processing program The Basic Encoding Rules are similar to many file formats in that for each object they encode, they specify a type, a length, and then a value. Each type is specified by a tag identifier. These tag identifiers are specified in the ASN.l Definitions inside the brackets, i.e., [3]. Each tag identifier belongs to one of four classes of tags, defined by a two bit pattern. A tag identifier also has a five bit tag number which was chosen in each case to be unambiguous in the context of other tags. A one bit flag, which indicates whether the 53 ASN.l Coding Concepts value to which the tag identifier refers, is constructed or primitive is also present in the tag identifier. Constructed values or objects are built up from other objects. Figure 10 indicates how the tag identifiers are built up from the class, tag number, and constructed flag of a given ASN.l object. Tag identifiers also have a long form for handling tag numbers greater than 30. We show only the short form. 7 6 5 4 3 2 1 0 Bit Number In Byte 1 0 Tag Class - cont-spec 1 Constnjcted Rag 0 0 0 1 0 Tag Number - 2 Assembled 1 0 1 0 0 0 1 0 Tag Identifier 1 I Hexadecimal Version Figure 10 - Constructing Tag Identifiers. There are four classes of tags. Shown below are their names, their two-bit codes used in constructing tag identifiers, and their use: Universal 00 Types that are defined in IS 8824, e.g., INTEGER, OCTET STRING. [13] Application 01 Types that are defined for the specific application, e.g. , ODA has defined APPLICATION 0 to be a string containing only digits and spaces. Context-specific 10 Types which are defined only for a specific context such as SET or SEQUENCE which were illustrated earlier. Private 11 Not used in the ODA Raster DAP. 54 ASN.l Coding Concepts The length associated with an object includes the length of all objects contained within it. Figure 11 shows the two length encoding schemes: definite and indefinite length. The definite length method can have either a short or a long form. The short definite form is only valid for contents with a length of 0 to 127 whereas the long definite form is valid for any definite length, including small values that could use the short definite form. For primitive objects and simpler constructed objects, it is relatively easy to anticipate their length. In this situation, the definite length encoding is used. Short definito form: 1 i n I 1 1 i 1 (toriflin ) Long definite form: 1 ... Ill'll I 1 I 1 I 1 1 I 1 (« of suosaquont (langih ) ( ( octets ) indefinite form: 1 0 0 0 0 0 0 0 constructed contents octets ••• (indefinite length) 00000000 00000000 I ' I ' i J-L I,.I. 1, 1 I III (endofconteno ) Figure 11 - Definite and Indefinite Length Encoding. This figure is extracted from Gaudette [7]. For complicated tagged objects, it might not be possible to determine their lengths until the lengths of their sub-elements are known. In this case, indefinite length encoding becomes useful. This method begins the object without specifying its length. A sequence of sub-elements then appears. The end of the object is marked by appending an end-of -contents flag, two bytes of zeros. Indefinite length encoding may be easier for a writing program when it encounters complicated objects, but it makes a reading program's job more difficult. If the length is not known, it is not possible to simply skip over the large object even if it is not of interest. The object must be parsed in detail in order to find the end-of-contents flag. This parsing examines only the type and length of each sub-element. Each sub-element which is not an 55 ASN.l Coding Concepts end-of -contents flag can then be skipped over by use of its length information. 10.4 Transfer Values Transfer values are hexadecimal listings that specify the actual binary octets (bytes) placed in an interchanged file. They are the result of applying the Basic Encoding Rules to the ASN.l Definitions. A standard indenting scheme makes it easier to understand the nesting of objects. Although the DAP notation and ASN.l Definitions describe the entire range of all possible interchanged files, the transfer values listing is very specific — it describes a single instance of an interchanged file. Using the ASN.l Definitions from Appendix A and a full page test chart from Appendix B, interchange examples of transfer values were developed in Appendices C-F. The ASN.l Definitions were read into the Free Value (Freeval) tool (see Tools, section 11) to evaluate and verify the correct ASN.l syntax. The tool was then used to insert values for attributes specific to the test chart document and to encode the transfer values for the different interchange examples illustrated in Appendices C-F. The first column of Appendices C-F shows the source data for each of the attributes to be included in the interchange file. The second column contains the resulting output from the Free Value tool after encoding the source data. Appendix C is used for the remainder of this section to describe the transfer values. However, only an excerpt, specifically the content-portion will be used to describe the transfer values in detail. The relevant ASN.l Definitions from Appendix A is extracted and shown below. = Interchange-Data-Element :: CHOICE { document-profile [0] IMPLICIT Document-Profile-Descriptor, layout-object [2] IMPLICIT Layout-Object-Descriptor, content-portion [3] IMPLICIT Text-Unit, presentation-style [7] IMPLICIT Presentation-Style-Descriptor } Text-Unit SEOUENCE { content-portion-attributes Content-Portion-Attributes OPTIONAL, content-information Content-Information OPTIONAL } 56 ASN.l Coding Concepts Content-Portion-Attributes ::= SET{ content-identifier-layout Content-Portion-Identifier OPTIONAL, type-of-coding Type-Of-Coding OPTIONAL, coding-attributes CHOICE { raster-gr-coding-attributes [2] IMPLICIT Raster-Gr-Coding-Attributes, alternative-representation [3] IMPLICIT Alternative-Representation } OPTIONAL } Content-Portion-Identifier :: = [APPLICATION 0] IMPLICIT PrintableString Type-Of-Coding ::= CHOICE { other-coding [6] IMPLICIT OBJECT IDENTIFIER - {2 8 3 7 6} 'T6 encoding - MSB' } Content-Information ::= CHOICE { one-octet-string OCTET STRING, seq-octet-string SEOUENCE OF OCTET STRING } Alternative-Representation ;:= OCTET STRING Raster-Gr-Coding-Attributes SET{ number-of-pels-per-line [0] IMPLICIT INTEGER OPTIONAL, number-of-lines [1] IMPLICIT INTEGER OPTIONAL, compression [2] IMPLICIT Compression OPTIONAL, - number-of-pels-per-tile-line [6] IMPLICIT INTEGER OPTIONAL, number-of-pels-per-tile-line is always a constant 512 - number-of-lines-per-tile [7] IMPLICIT INTEGER OPTIONAL, number-of-lines-per-tile is always a constant 512 tiling-offset [8] IMPLICIT Coordinate-Pair OPTIONAL, tile-types [9] IMPLICIT SEQUENCE OF Tile-Type OPTIONAL } Tile-Type ::= INTEGER! null-background (0), null-foreground (1), encoded-t6 (2), bitmap (5), encoded-t6-msb (6) - } T.4 not supported in tiled encoding Ra-Gr-Coding-Attribute CHOICE! compression [0] IMPLICIT Compression } 57 ASN . 1 Coding Concepts ::= Compression INTEGER {uncompressed (0), compressed (1 )} -- The 'Compression' attribute is supported by AliM but not by CALS. -- CALS data streams always uses the default value of 'compressed'. Inserting the source data transfer values for the content-portion resulted in the structure illustrated below. The type-of-coding object identifier value of {2 8 3 7 6} indicates that the image will be encoded as 'T.6 encoded - MSB' data. The number-of-pels-per-line will be '2550', the number-of-lines will be '3300', and the compression is '1' indicating that the T.6 escape mechanism is not used. content-portion { content-portion-attributes { content-identifier-layout "1 0 0 0 0", type-of-coding other-coding { 2, 8, 3, 7, 6 }, coding-attributes raster-gr-coding-attributes { compression 1, number-of-pels-per-line 2550, number-of-lines 3300 } }, content-information one-octet-string '...'H - '< } This results in the interchanged transfer data values as follows: <12832> a3 82 32 1c [3] constr <12828> . 31 1e [UNIV 17] constr <30> . . 40 09 [APPLO] <9> 31 20 30 20 30 20 30 20 30 . . 86 04 [6] <4> 58 03 07 06 . . a2 Ob [2] constr < 1 1 > . . . 82 01 [2] <1 > 01 . . . 80 02 [0] <2> 09 f6 . . . 81 02 [1] <2> Oc e4 . 04 82 31 f8 [UNIV 4] <12792> - 12792 octets of compressed data (T.6 encoded - MSB) The only items which actually appear in the interchanged data are the octets shown as hexadecimal values. Words, decimal points, or items in angle or square brackets are placed in the listing by the Free Value tool to aid readability and do not occur in the interchanged data. 58 ; ASN . 1 Coding Concepts Items in angle brackets are decimal lengths of the values that follow. Items in square brackets are decimal tags corresponding to the ASN.l Definitions. Items occurring in pairs are hexadecimal digits. Each pair of hexadecimal digits represents one octet. The octet values are a part of the interchange file whereas the other inf oirmation, such as decimal points and numbers contained in angle brackets and square brackets, are not a part of the interchange file but are used to aid the discussion and understanding of the file contents. The decimal points are included to show the structure of the data and make it easier to follow the example. Referring to the interchange object represented in the sixteen ' lines above and beginning with 'a3 82 32 Ic [3] constr < 1 2828> , we see that it is a constructed object made up of smaller objects. The word "constr" inserted by the Free Value tool is actually redundant. We could have come to the same conclusion by several other means: (1) the indenting structure using the decimal points below that line shows other objects; or (2) the bit structure of an 'a3', binary of '10100110', by the Basic Encoding Rules indicates a constructed type (third bit is a 1) . In the discussion below, binary values are shown in parentheses. While going through this encoding, it is helpful to refer to the ASN.l Definitions describing the Interchange-Data-Element in the Rif-module (see relevant ASN.l Definitions above). <12832> a3 82 32 1c [3] constr <12828> Each Interchange-Data-Element, interchange object, in the transfer values listing begins with a decimal number in angle brackets showing the length in octets of the entire Interchange-Data-Element. In this example, the entire length of the content-portion object is 12,832 octets. Encoding the third CHOICE, content-portion, of the Interchange-Data-Element results in the a transfer entry 'a3 82 32 Ic' . The tag identifier 'a3', refer to figure 10, stipulates a context-specific (10), constructed (1) transfer value with a tag number of three (00011) (10 ) ( 1 ) ( 00011 ) (10100011) = a3 hexadecimal. From the ASN.l Definitions, we see that the item having the tag [3] in the present context is the content-portion. From this, we see that the content-portion is of type Text-Unit. 59 , , ,. ASN . 1 Coding Concepts The '82' uses the long definite form of length and specifies the number of octets in the length value of the structure that will follow. That is, the first bit of the octet (1) designates a long definite form and therefore the following bits (0000010) is a length (length of a length) indicating that two octets follows which in turn contains the length of '32 1c' for the content-portion. The actual length of the value for the content-portion is '321c' or 12,828 octets. . 31 1e [UNIV 17] constr <30> Encoding the first element in the SEQUENCE of the Text-Unit, content- portion-attributes, results in the second entry '31 1e'. The '31' stipulates a universal type (00), constructed (1), transfer value having tag number (10001) representing decimal 17. The resulting encoding is a constructed type, universal type 17 which indicates a set. The length of the transfer value (structure that follows) '1e', is 30 octets shown in the short definite form. . . 40 09 (APPL 0] <9> 31 20 30 20 30 20 30 20 30 Encoding the first element in the SET of the content-portion-attributes, content-identifier-layout, results in the third and fourth entry '40 09' and '31 20 30 20 30 20 30 20 30', respectively. The '40' stipulates an application type (01) , primitive (0) tag number of zero (00000) In this instance, the tag number identifies the application class tag. The application class tags are defined within the ODA realm of "application." They are shown in IS 8613-5, Annex B, to be: Application 0 Content-Portion-Identifier Application 1 Object-or-Class-Identif ier Application 2 Content-Type Application 3 Character-Data Application 4 Date-and-Time Application 5 Style-Identif ier Again, the length of the transfer value, '09', is nine octets in the short definite form and the value is '31 20 30 20 30 20 30 20 30' which is the encoding for the Printable String '1 0 0 00'. . . 86 04 [6] <4> 58 03 07 06 Encoding the second element in the SET of the content-portion-attributes, type- of-coding, results in the fifth and sixth entry '86 04' and '58030706', respectively. The '86' stipulates a context-specific (10) , primitive (0) tag number of six for object identifier (00110) 60 . , ASN . 1 Coding Concepts The '04' again is a short definite form with the length being four. The type-of-coding value of {2, 8, 3, 7, 6} is encoded as '58 03 07 06'. Clause 20 of IS 8825 describes the encoding process for object identifiers . . a2 Ob [2] constr < 1 1 > Encoding the third element in the SET of the content-portion-attributes, coding-attributes, results in the seventh entry 'a20b'. The coding-attributes consists of a CHOICE, in our case it is the raster-gr-coding-attributes . The 'a2' stipulates a context-specific (10), constructed (1), transfer value with a tag number of two (00010) for tag [2]. The length of the transfer value, 'Ob' is 11 octets shown in the short definite form. . . 82 01 [2] <1 > 01 Encoding the first element in the SET of the raster-gr-coding-attributes, compression, results in the eighth and ninth entry '8201 01 '. The '82' stipulates a context-specific (10) , primitive (0) transfer value for compression (00010), tag [2]. The length of '01' indicates that the following transfer value is contained within the one octet. The transfer value, '01', is an integer value of one to indicate compression. This means that the encoded data is compressed and that the T.6 escape mechanism is not permitted, which is the default value. As stated earlier in this document, this attribute may be used by AIIM but is not used by DoD. . . 80 02 [0] <2> 09 f6 Encoding the second element in the SET of the raster-gr-coding-attributes, '80 02' number-of-pels-per-line , results in the tenth and eleventh entry and '09f6', respectively. The '80' stipulates a context-specific (10), primitive (0) , transfer value for number-of-pels-per-line (00000) , tag [01. The length of '02' indicates that the following transfer value is contained within two octets. The transfer value, '09 f6', is an integer value of 2,550 for the number-of-pels-per-line. . . 81 02 [1] <2> Oc e4 Encoding the third element in the SET of the raster-gr-coding-attributes, number-of-lines, results in the twelfth and thirteenth entry '81 02' and '0ce4', respectively. The '81' stipulates a context-specific (10), [1]. primitive (0) , transfer value for number-of-lines (00001) , tag The 61 . ASN.l Coding Concepts length of '02' indicates that the following transfer value is contained within two octets. The transfer value, '0ce4', is an integer value of 3,300 for the number-of-lines . 04 82 31 f8 [UNIV 4] <12792> Encoding the second element in the SEQUENCE of the Text-Unit, content- information, results in the fourteenth and last entry, '04 82 31 f8', the '04' raster data. The stipulates a universal type (00) , primitive (0) , transfer value having tag number (00100) . The resulting encoding is a primitive type, universal 4 which indicates an octet string, one-octet-string. The length of the transfer value, '82 31 f8', is 12,792 octets shown in the long definite form. Following the '8231 f8' is 12,792 octets of CCITT T.6 encoded-MSB data which was previously stipulated by the type-of-coding attribute. If you compare the encoding example discussed above with a complete example in the appendices, you will find that tag identifiers, such as 'a2' and 'a3', may occur several times in the data stream. They have a common characteristic in that they are context-specific tag identifiers. This is valid because the tag identifiers are located in a different area of the data stream. This illustrates why the term "context-specific" is used to describe a type of tag. This context sensitivity means that another object of a completely different type may also have the same tag, but one can tell them apart because both will never appear in the same context. The above example could have been encoded using the indefinite length encoding of the ASN.l Basic Encoding Rules. The following encoding illustrates that the content-portion may be encoded as 'a3 80' . The '80' with the first bit a one and the remaining seven bits a zero indicate indefinite length. The content-information encoded as '04 80' also illustrates indefinite length encoding. For every occurrence of an indefinite length encoding, there must be a corresponding pair of octets containing zeros to terminate the encoding. Therefore at the end of the encoding, there are four octets of zeros, the first pair indicate the end of the content- information and the second pair indicate the end of the content-portion. 62 ASN.l Coding Concepts <12832> a3 80 [3] constr < Indefinite length > . 31 1e [UNIV 17] constr <30> . . 40 09 [APPL 0] <9> 31 20 30 20 30 20 30 20 30 . . 86 04 [6] <4> 58 03 07 06 . . a2 Ob [2] constr < 1 1 > . . . 82 01 [2] <1 > 01 . . . 80 02 [01 <2> 09 f6 . . . 81 02 [1] <2> Oc e4 . 04 80 [UNIV 4] < Indefinite length > -- 12792 octets of compressed data (T.6 encoded - MSB) . 00 00 00 00 63 . 11 Technical Concepts This section discusses questions likely to arise in the minds of implementors in the course of reading the ODA Raster DAP. Much of the explanation given in this section would have been inappropriate to include in the DAP, which is intended to be brief. 11.1 Raster Graphics Basics Raster graphics provides the capability to process, store, and exchange images in a digital format. This technology plays a significant role in systems development as we move toward the elusive goal of the paperless office and work environment. Raster graphics has been used for several years to exchange documents by facsimile. Currently, elements of the Department of Defense (DoD) are using this technology to store and exchange engineering documents. Similarly, the Patent Trademark Office digitizes and stores patents using raster graphics, thus making them available for on-line review. Organizations are also using this technology to store and retrieve scanned office documents. Raster graphics technology is absolutely necessary for applications that interchange and store pictorial data such as photographs and logos Raster graphics is a method of representing a two-dimensional image by dividing it into a rectangular two-dimensional array of picture elements (pels) . Each element of the pel array comprises data indicating the color and the brightness of the corresponding picture element of the image. To produce a raster image from an existing document, the hard copy paper or microfilm media must be processed through a raster scanning device. The data which determines the image of a pel specifies one of two states, named "set" and "unset." The set state is used to identify the foreground color and the unset to identify the background color. In black and white images, the foreground is represented by a "1" and background by a "0." For reproduction on paper, the background color will normally be white and the foreground color black. The array is often referred to as the bitmap image. In the electronic data capture and conversion of existing images to digital form by an optical scan process, the scanner superimposes an imaginary grid or raster over the image to be scanned. Each of the grid squares represents an individual pel in the pel-array. Scanning is performed from left to right along each line beginning at the top of the page. The scanner evaluates each pel and assigns a corresponding binary value of "0" for mostly white or "1" for mostly black. 64 Technical Concepts Figure 12 - The Raster Scan Process NOTE: The boundary of each pel is directly adjacent to its neighboring pel without any space between them. The dimensions of the array or bitmap are determined by the size of the document or image being represented. The image detail that can be illustrated is dependent upon the resolution density of the raster grid. The resolution density is the specific number of pels per inch which is normally the same for both directions of the image dimensions. Image detail can be improved by increasing the grid density but this also increases the storage and data processing requirements. Consequently, there is a trade-off between the image detail required for the application and the costs associated with the higher density requirements. One of the costlier aspects of raster graphics processing is the large amount of data generated by the process. For example, the actual letters "Me," as illustrated in figure 12, require only 16 bits, or two bytes, to represent using ASCII character coding. 65 Technical Concepts 000000000000000000000000000000000000000000 000000000000000000000000000000000000000000 000000000000000000000000000000000000000000 000000000000000000000000000000000000000000 000011100000000001110000000000000000000000 000011100000000011110000000000000000000000 000011110000000011110000000000000000000000 000011110000000111110000000000000000000000 000011110000000111100000000000000000000000 000011111000000111100000000000000000000000 000011111000001111100000000011111110000000 000011001100001101100000000111111111000000 000011001100001101100000001111000111100000 000011001110011001100000011110000011110000 000011001111111001100000011100000001110000 000011000111110001100000011100000001110000 000011000111110001100000111100000001110000 000011000011100001100000111111111111110000 000011000001100001100000111111111111110000 000011000000000001100000111000000000000000 000011000000000001100000111000000000000000 000011000000000001100000011000000000000000 000011000000000001100000011100000000110000 000011100000000011100000001111000001110000 000011100000000011110000000111111111100000 000011100000000011100000000011111110000000 000000000000000000000000000001110000000000 000000000000000000000000000000000000000000 000000000000000000000000000000000000000000 000000000000000000000000000000000000000000 Figure 13 - Raster Data The bitmap image, as shown in figure 13, requires a total of 1260 bits, or 158 bytes, to represent these same two letters in a raster image format. To help reduce the storage requirements, there have been several encoding schemes developed to compress raster data. In the world of facsimile transmission, the CCITT Recommendation T.4 (Group 3) is currently used for compressing the documents during transmission. It is anticipated that future systems will 66 Technical Concepts use the CCITT Recommendation T.6 (Group 4) compression algorithm. DoD Military Standard 184 0 stipulates the use of CCITT Recommendation T.6 (Group 4) as the DoD standard to be used for the interchange of raster data between DoD installations and their vendors. Compression ratios can typically range from 10:1 to 50:1 depending upon the complexity of the image. Raster graphics images can be integrated into office documents through the use of IS 8613, Office Document Architecture (ODA) and Interchange Format. ODA provides for open interchange of structured compound documents containing text, vector graphics and raster graphics. It provides the rules for partitioning and organizing (structuring) the document and the encodings for this structure using ASN.l. ODA also provides a scheme for subdividing a large raster graphics image into non-overlapping regions called tiles. This scheme provides a format that supports operations on portions of a large image without requiring other portions of the image to be accessed. It also allows parallel compression and decompression of the individual tiles. 11.2 Encoders and Decoders It is worth noting that encoders (writers) and decoders (readers) of ODA Raster DAP files have differing needs for generality. Programs which create ODA Raster DAP files may be relatively simple because they may be hard-coded to produce a specific file that meets the specifications of the contract and that still remains compliant with the document application profile (DAP) . This allows a simpler conversion of data out of a given system format for export to other organizations. For example, encoding programs may use definite or indefinite length encoding, may or may not include the optional tile index, may or may not zero out unused portions of partial tiles, may or may not create documents with sizes divisible by eight, etc. Writers may freely rely on default values for as many parameters as they are allowed according to the DAP. Programs decoding ODA Raster DAP files must be more general in that they must be prepared to receive data from a wide range of writers, each of which is producing files in the manner simplest for them. 11.3 Converters Versus Native Systems Systems that store data internally in a format close to that of an ODA document are called native systems. There is some advantage to 67 . Technical Concepts having a native system, although differing implementation requirements may make it impractical in many cases. Non-native systems must implement file converters for translation of interchanged documents. This can add some overhead at import and export time. 11.4 Bit Order The proper ordering of bits within bytes (octets) is a subject of industry-wide dispute. The traditional method in facsimile equipment for compressed data is to pack code bits into bytes in up fashion, that is, least significant bit (LSB) to most significant bit (MSB) . The most widespread method used in sending bitmapped (uncompressed) data to computer display adapters is with a down ordering (MSB to LSB) . This MSB to LSB bit ordering has also become a common representation for compressed data in many PC and workstation implementations. A Proposed Technical Corrigendum (PTC) Number 47 to ISO/IEC JTC1/SC18/WG3 proposed that additional type of coding attribute values be added to CCITT Recommendation T.417 and ISO 8613-7. This change would allow support in either bit order sequence. The PTC was approved by CCITT but not by ISO. However, the revised text will appear in the joint publication of CCITT Rec. 417 ISO 8613-7 | with a note that it is approved only for CCITT. The consequence of this is that the DAPs may refer to the CCITT Recommendation T.417 instead of ISO 8613-7. Thus, the indication of this as being for CCITT only has no effect on current implementations. PAGODA has asked that ISO review its position and approve the PTC 47 before publication of the joint document. In the design process, it might be prudent to plan for reading both compressed bit orderings, especially if such support comes more cheaply during the early development phases. 11.5 Padding/Byte Boundaries Some systems may derive efficiencies from handling documents which have sizes which are multiples of eight. MIL-R-28002B requires an encoding program to export documents having such sizes. Decoding programs may be required by contract to import documents from other systems which allow for arbitrary dimensions. They may do this either natively, or by padding out lines with zeros to dimensions which are multiples of eight, or by truncation (since it is unlikely that this will lose significant data) 68 Technical Concepts A related issue is whether compressed data has byte boundary constraints. The T.6 standard assumes that a T.6 compressed data block will have zeros (called pad bits) placed after the valid bits in the last, partial byte. The next data item begins on a byte boundary. Byte boundaries are a major issue only for T.4 compression, which is not permitted under MIL-R-28002B. 11.6 Partial tiles In ODA Raster DAP tiled files, a document's size along either dimension will generally not be a multiple of 512 pels. This means that some unused data can exist in tiles around any or all of the document's four edges. In IS 8613 Part 7, this unused data is not considered to be information. Please refer to figure 14. Decoding programs should therefore behave as if garbage data will exist in those pels and guard against its presentation. Unless specified in the DoD contract that the un-imaged pels be set to background, encoding programs have the option of leaving garbage in those pels or zeroing them out prior to compression. It is understood that compression will improve if zeros are in the unused portion of the tile. It is further understood that some systems may get a needed price or performance benefit from not zeroing that data. For example, at a quality assurance (QA) workstation, an operator may perform dynamic clipping of scans of poorly registered aperture cards. Leaving garbage in the partial tiles and simply changing the clipping parameters in the file would avoid having to recompress the peripheral tiles. Referring again to figure 14, we notice it shows only one band of partial tiles around the periphery of the tile grid. This is because the tiling offset measure pair coordinates must be less than or equal to 512. What is particularly useful is the clipping function illustrated in figure 14. This feature allows an intelligent scanning subsystem to identify the borders of the "good" region of the scan and merely paste the appropriate clipping coordinate pairs into the file. It does not need to recompress the tiles to remove the trimmed areas. 11.7 Tile Ordering During interchange, the tiles must appear in the file in an order which is primarily along the pel path direction and secondarily along the line progression direction. 69 Technical Concepts Many systems have to internally store tiles in random order because the tiles leave parallelized hardware in unpredictable order or because a series of tile-local editing sessions have occurred. At interchange time, however, these tiles must be properly ordered. 11.8 Orientation For ODA Raster DAP documents, the manner in which the ODA raster architecture deals with orientation requires the use of two attributes, pel path and line progression. The pel path and line 70 Technical Concepts progression directions specified for the document at interchange time guide the reader during the imaging process. To get proper viewing, a reader will take pels from a compressed or uncompressed data stream (file) and place them on the screen or paper in the directions indicated. The decoding program will lay down the first line of pels along the pel path direction and the second line along a path parallel to the first, but displaced from it along the line progression direction. The decoding system knows its own requirements. If the target device is a display, the pels may be placed in memory in one organization. If the target device is a narrow printer, the pels may be placed in memory by the decoding program in a different way. The point is that the orientation parameters found in the file are purely descriptive, not prescriptive. The pel path direction may have any of four values and the line progression direction can be at either of the two possible right angles to it. Therefore, this model can describe images which are not only rotated, but also mirrored either vertically and/or horizontally. This allows the orientation parameters to describe how to image a file which might have resulted from scanning the back side of an aperture card or paper sepia. This procedure might have been done in order to improve image quality. Refer to figures 15 and 16 for an illustration of the possible orientations. If a mix of scans is done as a batch and the file writer assumes all of the scans have a certain orientation when in fact they do not, then a QA post-process will be necessary. The QA operator would view each scan, check its quality, perhaps perform a clipping operation, and then identify which direction would be "up" for proper viewing orientation. The orientation parameters would end up in the file, which until that point would have had incorrect orientation parameters. No other changes or actual rotation would be required. It is worth noting that the DAP requires all tiles to have the same orientation. 71 Technical Concepts Figure 15 - Position of Pels, Portrait Document 4 ALL FED TTH POLICE SCANNER IN THIS DIRECTION Pel Path = 270 270 o N. = CM Vi Progression Vi 2 ? 0. Line o c 270 - Progression Line Note 1: The pel path direction is measured in degrees counterclockwise from the positive horizontal axis (east). Note 2: The line progression direction is measured in degrees counterclockwise from the pel path direction. 72 Technical Concepts Figure 16 - Position of Pels, Landscape Document ALL FED IHROUQH SCANNER IN THIS DIRECTION Pel Path = 90 Pel Path = 0 270 = Progression Line 270 - Progression Line U. Note 1: The pel path direction is measured in degrees counterclockwise from the positive horizontal axis (east). Note 2: The line progression direction is measured in degrees counterclockwise from the pel path direction. 73 Technical Concepts 11.9 Rotation to Proper Viewing Orientation MIL-R-28002B allows the contract to optionally specify that all documents be rotated where necessary to achieve proper viewing orientation with pel path direction set to 0 and line progression direction set to 270. If this option has been specified, the QA process described above would require an additional step of rotating any document which was improperly scanned. This contracting option would be specified in systems where the viewing subsystem is not powerful enough to perform at display time any rotation which may be required because of earlier random-orientation scanning. 11.10 Uncompressed Bit Sense Raster data represents each pel in the source document by a zero or a one. Differing conventions exist in industry as to whether a one represents a light or a dark picture element. The situation is further confused by the existence of both photographic positive and photographic negative source documents, , aperture cards, blueprints, blue lines. MIL-R-28002B states that an uncompressed image or tile shall represent the "information" in a source document by one bits and the "background" by zero bits. The "information" pels in an image are those which make it differ from a blank image. Such pels are typically (though not necessarily) grouped into run lengths shorter (on average) than are "background" pels. This representation assures harmony with T.6 encoding when such images or tiles are later compressed. T.6 coding best compresses short runs of ones and longer runs of zeros. In T.6, the correct use of ones and zeros in compressed data is not open to confusion. It specifies the coding unambiguously. 11.11 Database Issues In ODA Raster DAP files, a document may contain multiple pages (as pages are defined within ODA) . These pages may contain several images of a multiple frame aperture card. They may also contain the original image and a scaled down overview image. In this latter case, the main image appears as the first page. The sheets of a multiple sheet paper drawing or multiple card aperture card drawing may also appear as pages within the same document. This requires a prior agreement between the exchanging parties or in the contracting document. This agreement identifies the allowed uses of this mechanism and how these uses are to be distinguished from each other. 74 Technical Concepts 11.12 Definite Versus Indefinite Length When encoding various data objects in ASN.l, a choice exists between using definite length encoding and indefinite length encoding. Definite length encoding has an explicit length specified for an object. This applies to the entire containing object, even if it is constructed of many smaller objects. A reader that may be uninterested in the internal details of the object can safely skip ahead a known number of bytes. This will not work for writers. A writer must have foreknowledge of the size of the entire object before even writing out any of its contained objects, which may themselves have variable sizes. An enormous stack may be required in order to buffer pending objects. This contrasts with indefinite length encoding, where an explicit length is not given. Instead, a flag indicates the end of the object. A reader is then required to parse all the contained objects in order to not miss the flag. This slows down readers. It does, however, remove the need for a writer to have a large stack as described above. This becomes particularly important when creating interchange files containing tiled raster data. It may be more advantageous for the creator to use indefinite length encoding for the content-portion and the content-information (see Appendices D and E) . 11.13 Basic Versus Non-basic Versus Default Values Basic values are those commonly used values that may be placed by encoders into a parameter without any explicit statement of the intent to do so. Decoders are expected to be able to deal with all basic values. Non-basic values are non-commonly used values which may appear in the associated parameter and must be called out by encoding programs in a section near the beginning of the document (document profile) , well before they are used. This allows decoding programs to quickly discern if they are able to process the file. The non-basic values are specified in the non-basic document characteristics portion of the document profile (see ODA Constituents and Attributes, section 8, and ASN.l Definitions, Appendix A) . Decoders may not be able to support non-basic values; however, ISO encourages implementors to support both basic and non- basic values. A value not listed as basic or non-basic is not permitted, unless it occurs via a default. This is not always as restrictive as it might seem—{ANY_VALUE} is sometimes listed as non-basic. 75 Technical Concepts The defaulting mechanism operates as follows. If a parameter is not specified where it occurs, the parameter assumes the corresponding value specified for an object up in the hierarchy of objects. These defaults, if not stated in the document profile, are found in IS 8613. For example, the presentation attribute, pel spacing, has a default value in ISO 8613-7 of 4/1 BMUs (300 DPI) . If not specified anywhere in the data stream, then the '4/1' BMU value is used. However, it could be specified in several different manners in the data stream, that is, directly in the presentation attributes of a specific block, in a presentation style which is referenced by a specific block, or in the raster graphics content defaults of the document profile. If the attribute is specified in the presentation attributes of a specific block, then that value will be used regardless of any referenced presentation styles or of an entry in the document profile. If the attribute is not specified in the presentation attributes of a specific block, then an implementor must look for the possibility of it being specified in a presentation style that is referenced by the specific block. If it doesn't exist here, then the defaults in the document profile are evaluated for a pel spacing entry. If it is not present in the document profile, then the IS 8613 default of '4/1' is used. 11.14 Null Tiles Each tile in a ODA Raster DAP file may be of a different type. It may be a T.6 encoded, T.6 encoded-MSB, bitmap, null foreground, or null background tile. A tile that has a tile type of "null background" will have a null pointer in the tile index, if the tile index is present, and will be imaged as background without a need to draw raster content from the file— in fact it has none. 11.15 Presentation Styles There are two alternatives for designating the proper presentation attributes which are to be used in presenting raster graphics information on a page. These attributes include pel path, line progression, clipping, and pel spacing. As can be seen in the ASN.l Definitions (Appendix A), the presentation attributes are used to describe the Layout-Object-Description-Body; in our case, the layout object is the specific block. One alternative is to assign the presentation attributes (with a tag of 6) directly to the specific block. A second alternative is to use a presentation style (having a tag of 17) . Of course, if all the ODA default values are used, then no presentation attributes will have to be designated at all. The default values for these attributes are a pel path of 0 degrees, a 76 Technical Concepts progression degrees, a line of 270 pel spacing of 4 BMUs (300 dpi) , and a clipping rectangle marked by the two points (0,0; N-1,L-1). N is the number of pels per line and L is the number of lines. If a document consists of only a single page or if a document has multiple pages each with one unique presentation attribute requirement, then the presentation attributes, if required, may be assigned directly to the specific block. The presentation style constituent need not be used. If, on the other hand, a document consists of multiple pages with several pages sharing the same presentation attribute description (same pel path, line progression, etc.), then it may be more practical to use the presentation style constituent. The use of presentation style is illustrated in Appendix F. Note that the style-identifier in the interchange data element for presentation style is '5 0' and that the presentation-style attribute in interchange data element for document layout block contains a value of '50'. This identifier serves as a linking mechanism between the presentation style constituent and the appropriate specific block constituent. If the document illustrated had many pages, all consisting of the same presentation characteristics, then all of the additional block descriptions would reference the same presentation style of '50'. If a document consisted of many pages with three different presentation styles, then there would have to be a presentation style described for each: the first with a style-identifier of '50', the second with '51', and the third with '52'. Then each block would reference the appropriate presentation style with its presentation-style attribute containing either '50', '51', or '52'. In a multiple page document, the use of presentation styles allows the user to define a set of presentation styles with each one being unique. Then a block description refers to the appropriate presentation style. If styles are not used, then the presentation attributes would have to be repeated on every page even though they may contain identical descriptions. 77 . 12 Tools 12 . 1 ODA Toolkit An ODA toolkit is available from the ODA Consortium. The toolkit is designed to aid in the development of ODA applications. The ODA toolkit is new technology that could speed the development of computer applications that promote the electronic interchange of documents among different computer systems throughout the world. The technology involves Application Programming Interfaces (APIs) that the ODA Consortium includes in the toolkit. The toolkit is software with consistent, published specifications that is openly licensed to companies. The ODA Consortium now has defined an ODA-Level API which provides common services that define how data is stored and structured so it can be formatted efficiently into a document. It also has defined a DAP-Level API that helps structure documents according to well defined ODA functional subsets. More information can be obtained by writing to the: The Secretary, ODA Consortium, Avenue Marcel Thiry 204, 1200 Brussels, Belgium. 12.2 The ISO Development Environment (ISODE) An ASN.l tool that is publicly available exists within the ISO Development Environment (ISODE) . ISODE can be used to generate routines to encode and decode structures given the ASN.l definitions as input. Although ISODE is an openly available implementation of the upper-layers of Open Systems Interconnection (OSI) , it is primarily a development environment. As such, it contains many tools and libraries to aid the application development process. Section 4 of the User's Manual, "The Applications Cookbook" [18], has several ASN.l abstract syntax and transfer notation tools for development of ASN.l based applications It should be noted that this tool would primarily benefit the applications developer. ISODE need not be installed prior to use of this tool, only the specific programs for processing the ASN.l Definitions. ISODE is publicly available. To access the files, log onto a system with access to Internet and FTP software. The host is: uu.psi.com. The file isode/ isode-8 . tar should be retrieved in BINARY mode. 78 . . Tools 12.3 Free Value tool, ASN.l Compilers The Free Value Tool is a set of development tools for working with ASN.l defined protocols or profiles. It can improve the programmer's understanding of ASN.l syntax by allowing parsing, transformation of profile structures into actual C language data structures, and conversions into and out of transfer format. Because it is highly general, it is not suited to production implementations The term "free value" comes from the fact that the result of running the tool is not a particular representation of one document, but rather a set of data structures and operations capable of properly encoding any of the defined class of documents. The variables of the data structure are "free" to assume any one value out of the allowed range of values. The Free Value tool comes as part of the OSIkit which is a collection of tools for the application of Estelle and ASN.l that were developed by NIST. Documents for these tools are distributed by the National Technical Information Service (NTIS) of the U.S. Department of Commerce. This software is not supported. The manual with the Free Value tool [7] (which is also available without the program) contains a valuable introduction to ASN.l notation. ASN.l compilers are also available commercially from several vendors 79 . 13 Glossary All definitions are taken from IS 8 613, Part 1 , except where otherwise specified. Attribute . An element of a constituent of a document that has a name and a value and that expresses a characteristic of the constituent or a relationship with one or more constituents of the document Basic value . An attribute value that is unconditionally allowed in document interchange in the context of a given application profile. Bitmap . A two- or three-dimensional data field representing a pel array. Block. A basic layout object that corresponds to a rectangular area within a frame and consisting of only a single type of content, i.e., raster graphics content. Clipping . The actual pel array to be imaged as determined by applying all clipping parameters. Constituent . A set of attributes that is one of the following types: a document profile, an object description, a presentation style, a layout style, or a content portion description. Composite page . A page that is subdivided into subordinate frames consisting of blocks. Compression . An operation performed on raster image data to remove redundant information and thus reduce the stored or interchanged size. Negative compression is the case where this operation results in an increase rather than a decrease in size. Constraints . Restriction conditions that are placed upon the use of attributes within constituents. Document Application Profile (DAP) . The specification of a combination of features defined in IS 8613, intended to form a subset to fulfil the requirements of an application. Decoding . The process of parsing a file, extracting content information, and deriving a bitmap from an octet string by translating any compression algorithm used to create the octet string. Default value . An attribute value that is the standard value in the document interchange in the context of a given application profile. 80 . . Glossary Document profile . A set of attributes which specifies the characteristics of the document as a whole. Document layout root . The composite object of the specific layout structure at the highest level of the hierarchy. Encoding . The process of deriving compressed data from a bitmap by applying a compression algorithm to the bitmap. Formatted document architecture . A form of representation of a document that allows the presentation of the document as intended by the originator and that does not support editing and (re) formatting. Formatted processable content architecture . This is intended to be laid out, reformatted and imaged by the recipient in accordance with the originator's intent. (Part 7) Frame. A type of composite layout object that corresponds to a rectangular area within a page. Image Frame A frame used in the context of the ODA Raster DAP where the frame is coincident with the page. Layout characteristics . The attributes which guide the layout structure of a layout object. Line progression direction . The direction of progression of successive lines of pels within a basic layout object. Non-basic value . An attribute value that is only allowed in document interchange in the context of a given application profile if its use is declared in the document profile. Octet . A subdivision of eight bits numbered from 8 to 1 where bit 8 is the most significant bit and bit 1 is the least significant bit. (Also known as a byte.) Page . A type of layout object that corresponds to a rectangular area used as a reference area for presenting the content of the document Partial tiles . In a tiled image of a document, the incomplete tiles which may occur on any or all of the four sides of the tile array when the image has been positioned and clipped. Also known as runt tiles. Pel (picture element) . The smallest graphic element that can be individually addressed within a picture. Synonymous with pixel. 81 Glossary Pel array . A two-dimensional array of pels used to represent a pictorial image. Pel path direction . The direction of progression of successive pels along a line within the basic layout object. Pel spacing . The distance between any two successive pels along a scan line of an image. It is the inverse of such often used terms as pel density, transmission density, or resolution. Presentation attributes . Attributes which guide the format and appearance of an object's content. Presentation style . A constituent of the document, referred to from a basic logical or layout component, which guides the format and appearance of the document content. Raster graphics . The electronic data processing medium used to depict any arbitrary assemblage of text characters, graphical figures, or pictorial images with a pel array. Raster graphics content . The raster graphics portion of a document that is intended for human perception. Spacing ratio . The ratio of line spacing to pel spacing. Specific Block . A block used in the context of the ODA Raster DAP. Tile . A rectangular region in a layout object in which all such regions have the same dimensions, no part of any region overlaps any other region, and regions are positioned in a fixed grid, determined by partitioning the layout object into region-sized areas. Tile index . An application comment in ODA Raster DAP files which contains a list of byte offsets from the beginning of the content information (first tile) to the beginning of each tile in the page. 82 14 References 1. ANSI/AIIM MS-53 (Proposed), Bi-Level Image File Format Level 1.1 (All), 199X. 2. Appelt, Wolfgang, Document Architecture in Open Systems, The ODA Standard, Springer-Verlag, New York, 1991. 3. CCITT Recommendation T.503, Document Application Profile for the Interchange of Group 4 Facsimile Documents, 1984. 4. CCITT Recommendation T.6, Facsimile Coding Schemes and Coding Control Functions for Group 4 Facsimile Apparatus, 1988. 5. Dawson, F., and F. Nielsen, 1990, ODA and Document Interchange, Unix Review, vol.8, no. 3, March 1990, p.50. 6. FIPS PUB 150, Telecommunications: Facsimile Coding Schemes and Coding Control Functions for Group 4 Facsimile Apparatus, 4 November 1988. 7. Gaudette, P. , S. Trus, and S. Collins, 1989, The Free Value Tool for ASN.l, Technical Report NCSL/SNA-89/ 1 , National Computer Systems Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899, February 1989. 8. Hobgood, A., CALS Implementation— Still a Few Questions, Advanced Imaging, April 1990, pp 24-5. 9. IS 8613-1, Information processing - Text and office systems - Open Document Architecture (ODA) and interchange format - Part 1: Introduction and General Principles, 1989. 10. IS 8613-2, Information processing - Text and office systems - Open Document Architecture (ODA) and interchange format - Part 2: Document structures, 1989. 11. IS 8613-4, Information processing - Text and office systems - Open Document Architecture (ODA) and interchange format - Part 4: Document profile, 1989. 12. IS 8613-5, Information processing - Text and office systems - Open Document Architecture (ODA) and interchange format - Part 5: Office Document Interchange Format (ODIF) , 1989. 13. IS 8613-7, Information processing - Text and office systems - Open Document Architecture (ODA) and interchange format - Part 7: Raster Graphics Content Architectures, 1989. 14. IS 8613-7 Addendum, Information processing - Text and office systems - Open Document Architecture (ODA) and interchange format 83 References - Part 7 : Raster Graphics Content Architectures Tiled Raster Graphics Addendum (ISO SC18 WG5 Draft Addendum), 1990. 15. IS 8813-7 Addendum, Information processing - Text and office systems - Open Document Architecture (ODA) and interchange format - Part 7: Raster Graphics Content Architectures Additional Bit Order Mapping Addendum, Proposed Technical Corrigendum (PTC) Number 47, ISO/IEC JTC 1/WG 3, dated July 1991. 16. IS 8824, Information processing-Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.l), 1987. 17. IS 8825, Information processing-Open Systems Interconnection - Specification of basic encoding rules for Abstract Syntax Notation One (ASN.l), 1987. 18. ISO Development Environment; User's Manual, Volume 4: The Applications Cookbook, August 12, 1988. 19. MIL-R-28002B, Military Specification, Requirements for Raster Graphics Representation in Binary Format, November 1992. 20. MIL-STD-1840B, Military Standard, Automated Interchange of Technical Information, 3 November 1992. 21. NIST Special Publication 500-192, Government Open Systems Interconnection Profile Users' Guide, Version 2, October 1991. 22. NIST Special Publication 500-206, Stable Implementation Agreements for Open Systems Interconnection Protocols, Version 6, Edition 1, December 1992. 23. Rose, M.T. , The Open Book: A Practical Perspective on OSI, Prentice Hall, Englewood Cliffs, NJ. , 1990. 24. Sharpe, L. , Tiling; Turning Unwieldy Drawings into Neat Little Packets, Inform, Association for Image and Information Management, March 1989. 84 . Appendix A ASN.1 Definitions This appendix contains the complete listing of the ASN.l Definitions of an implementation of the ODA Raster DAP. The ASN.l Definitions are defined in a single module referred to as "Raster Interchange Format (RIF) Module." The ASN.l Definitions are a subset of the ODA ASN.l Definitions defined in IS 8613-5, IS 8613-7, and the Addenda to IS 8613-7. These definitions were developed by the National Institute of Standards and Technology using the Free Value tool. Some constructions which may seem peculiar exist in order to work around limitations in those tools such as their lack of support for macros. For example, if macros were available to process object " " identifiers, the commented-out line --{ 2 8 2 7 2 } found below could have been properly pasted in without the use of a comment. The files used in constructing the examples illustrated in the appendices of this document are publicly available via anonymous FTP on the Internet. The files are on speckle.ncsl.nist.gov in the directory /pub/oda_raster **'W*****************************'** — * Interchange Data Element * — ” * ASN.l Definitions for Raster Interchange Format (RIF) * - Rif-Module DEFINITIONS :: = BEGIN = Interchange-Data-Element :: CHOICE { document-profile [01 IMPLICIT Document-Profile-Descriptor, layout-object [2] IMPLICIT Layout-Object-Descriptor, content-portion [3] IMPLICIT Text-Unit, presentation-style [7] IMPLICIT Presentation-Style-Descriptor } DOCUMENT PROFILE DESCRIPTOR *************** .. ::= Document-Profile-Descriptor SET { specific-layout-structure [1] IMPLICIT NumericString OPTIONAL, document-characteristics [2] IMPLICIT Document-Characteristics OPTIONAL, document-management-attributes [3] IMPLICIT Document-Management-Attributes OPTIONAL, presentation-styles [6] IMPLICIT NumericString OPTIONAL } 85 Appendix A - ASN . 1 Definitions Document-Characteristics ::= SET{ document-architecture-class [1] IMPLICIT INTEGER { formatted (0)} OPTIONAL, non-basic-doc-characteristics [2] IMPLICIT Non-Basic-Doc-Characteristics OPTIONAL, document-application-profile [4] IMPLICIT OBJECT IDENTIFIER, -{1314111 1}, content-architecture-classes [5] IMPLICIT SET OF OBJECT IDENTIFIER OPTIONAL - { 2 8 2 7 2 }-, - Raster Formatted Processable - interchange-format-class [6] IMPLICIT INTEGER {if-a (0)}, - Class A - oda-version [8] IMPLICIT SEQUENCE { standard Character-Data, publication-date Date-and-Time) OPTIONAL, doc-appl-profile-defaults [10] IMPLICIT Doc-Appl-Profile-Defaults OPTIONAL } Doc-Appl-Profile-Defaults SET { document-architecture-defaults [0] IMPLICIT Document-Architecture-Defaults, raster-gr-content-defaults [2] IMPLICIT Raster-Gr-Content-Defaults OPTIONAL } Document-Architecture-Defaults SET{ content-architecture-class [0] IMPLICIT Content-Architecture-Class OPTIONAL, - {2 8 2 7 2} Raster Formatted Processable - page-dimensions [2] IMPLICIT Measure-Pair OPTIONAL, medium-type [6] IMPLICIT Medium-Type OPTIONAL, page-position [9] IMPLICIT Measure-Pair OPTIONAL, type-of-coding [10] Type-Of-Coding OPTIONAL -{2 2837 6} 8370 I 28375 | - T6 encoding, tiled encoding, OR - T6 encoding - MSB - See note under Type-Of-Coding } Non-Basic-Doc-Characteristics ::= SET{ page-dimensions [2] IMPLICIT SET OF Dimension-Pair OPTIONAL, ra-gr-coding-attributes [3] IMPLICIT SET OF Ra-Gr-Coding-Attribute OPTIONAL, ra-gr-presentation-features [4] IMPLICIT SET OF Ra-Gr-Presentation-Feature OPTIONAL, medium-types [8] IMPLICIT SET OF Medium-Type OPTIONAL } 86 Appendix A - ASN . 1 Definitions Document-Management-Attributes ::= SET{ document-description [7] IMPLICIT Document-Description OPTIONAL } Document-Description ::= SET{ document-reference [5] Document-Reference OPTIONAL } Document-Reference ;:= CHOICE { unique-reference OBJECT IDENTIFIER, descriptive-reference Character-Data } Character-Data :: = [APPLICATION 3] IMPLICIT OCTET STRING Date-and-Time :: = [APPLICATION 4] IMPLICIT PrintableString ,_*************** layout OBJECT DESCRIPTOR *************** Layout-Object-Descriptor SEOUENCE { object-type Layout-Object-Type OPTIONAL, descriptor-body Layout-Object-Descriptor-Body OPTIONAL } Layout-Object-Type ::= INTEGER { document-layout-root (0), page (2), frame (3), block (4) } Layout-Object-Descriptor-Body ::= SET{ object-identifier Object-or-Class-ldentifier OPTIONAL, subordinates [0] IMPLICIT SEQUENCE OF NumericString OPTIONAL, content-portions [1] IMPLICIT SEQUENCE OF NumericString OPTIONAL, position [3] IMPLICIT Measure-Pair OPTIONAL, dimensions [4] IMPLICIT Dimension-Pair OPTIONAL, presentation-attributes [6] IMPLICIT Presentation-Attributes OPTIONAL, user-readable-comments [8] IMPLICIT Comment-String OPTIONAL, user-visible-name [14] IMPLICIT Comment- String OPTIONAL, page-position [15] IMPLICIT Measure-Pair OPTIONAL, medium-type [16] IMPLICIT Medium-Type OPTIONAL, presentation-style [17] IMPLICIT Style-Identifier OPTIONAL, application-comments [25] IMPLICIT OCTET STRING OPTIONAL ” 'application-comments' defined according to IS 8613-5, the ASN.1 87 Appendix A - ASN . 1 Definitions — type definition for the containing tiling indexes within a block -- layout object is: 'SEQUENCE OF INTEGER'. See ODA Raster DAP. } Object-or-Class-ldentifier :: = [APPLICATION 1] IMPLICIT PrintableString Style-Identifier :: = [APPLICATION 5] IMPLICIT PrintableString Comment- String ::= OCTET STRING Dimension-Pair ::= SEQUENCE { horizontal [0] IMPLICIT INTEGER, vertical CHOICE { fixed [0] IMPLICIT INTEGER, variable [1] IMPLICIT INTEGER} } Medium-Type SEQUENCE! nominal-page-size Measure-Pair OPTIONAL, side-of-sheet INTEGER { unspecified (0), recto (1 ), verso (2) } OPTIONAL } *************** presentation STYLE DESCRIPTOR ************** Presentation-Style-Descriptor ::= SET{ style-identifier Style-Identifier, user-readable-comments [0] IMPLICIT Comment-String OPTIONAL, user-visible-name [1] IMPLICIT Comment- String OPTIONAL, presentation-attributes [3] IMPLICIT Presentation-Attributes OPTIONAL } Presentation-Attributes ::= SET{ content-architecture-class Content-Architecture-Class OPTIONAL, raster-graphics-attributes [1] IMPLICIT Raster-Graphics-Attributes OPTIONAL } Content-Architecture-Class OBJECT IDENTIFIER -{28272} Raster Formatted Processable - 88 Appendix A - ASN . 1 Definitions ** 4^*******^**** TEXT UNITS *************** „ Text-Unit ::= SEQUENCE { content-portion-attributes Content-Portion-Attributes OPTIONAL, content-information Content-Information OPTIONAL } Content-Portion-Attributes ::= SET{ content-identifier-layout Content-Portion-Identifier OPTIONAL, type-of-coding Type-Of-Coding OPTIONAL, coding-attributes CHOICE { raster-gr-coding-attributes [2] IMPLICIT Raster-Gr-Coding-Attributes, alternative-representation [3] IMPLICIT Alternative-Representation } OPTIONAL } Content-Portion-Identifier :: = [APPLICATION 0] IMPLICIT PrintableString Type-Of-Coding CHOICE { other-coding [6] IMPLICIT OBJECT IDENTIFIER {2 8 3 7 0} 'T6 encoding' - or (2 8 3 7 1} 'T4 one dimensional encoding' - or (2 8 3 7 2} 'T4 two dimensional encoding' - or {2 8 3 7 3} 'bitmap encoding' - or {2 8 3 7 5} 'tiled encoding' - or {2 8 3 7 6} 'T6 encoding - MSB' - or {2 8 3 7 7} 'T4 one dimensional encoding - MSB' " or (2 8 3 7 8} 'T4 two dimensional encoding - MSB' } — CALS supports only the bitmap(28373), tiled(28375), and T6-MSB(28376) encodings. — AIIM does not support tiled encoding. Content-Information ::= CHOICE { one-octet-string OCTET STRING, seq-octet-string SEQUENCE OF OCTET STRING } — NOTE: Content-Information ::= OCTET STRING is defined in IS 8613-5 (1989), but an eratta has been submitted to change the description to a choice to support tiled raster graphics. Alternative-Representation ::= OCTET STRING ” NOTE: String of characters from the sets designated by the document profile attribute "alternative representation character sets", plus carriage return and line feed. 89 1 Appendix A - ASN . Definitions __ ************** definitions supporting raster graphics ********** * * * - ###### RASTER GRAPHIC PRESENTATION ATTRIBUTES ###### - = Raster-Graphics-Attributes SET { pel-path [0] IMPLICIT One-Of-Four-Angles OPTIONAL, line-progression [1] IMPLICIT One-Of-Two-Angles OPTIONAL, clipping [4] IMPLICIT Clipping OPTIONAL, pel-spacing [5] Pel-Spacing OPTIONAL, spacing-ratio [6] IMPLICIT Spacing-Ratio OPTIONAL } One-Of-Four-Angles INTEGER { dO (0), - 0 degrees d90 (1 ), - 90 degrees d180 (2), - 180 degrees d270 (3) - 270 degrees } One-Of-Two-Angles ::= INTEGER { d90 (1), - 0 degrees d270 (3) -270 degrees } Measure-Pair ::= SEOUENCE { horizontal [0] IMPLICIT INTEGER, vertical [0] IMPLICIT INTEGER } Clipping ::= SEOUENCE { first-coordinate-pair [0] IMPLICIT Coordinate-Pair OPTIONAL, second-coordinate-pair [1] IMPLICIT Coordinate-Pair OPTIONAL } Coordinate-Pair SEOUENCE { x-coordinate INTEGER, y-coordinate INTEGER } Pel-Spacing ::= CHOICE { spacing [0] IMPLICIT SEOUENCE { length INTEGER, pel-spaces INTEGER }, null [1] IMPLICIT NULL - [1] null not supported } Spacing-Ratio SEOUENCE { line-spacing-value INTEGER, 90 Appendix A - ASN . 1 Definitions pel-spacing-value INTEGER } - ###### RASTER GRAPHICS CODING ATTRIBUTES ###### - Raster-Gr-Coding-Attributes ::= SET{ number-of-pels-per-line [0] IMPLICIT INTEGER OPTIONAL, number-of-lines [1] IMPLICIT INTEGER OPTIONAL, compression [2] IMPLICIT Compression OPTIONAL, " number-of-pels-per-tile-line [6] IMPLICIT INTEGER OPTIONAL, number-of-pels-per-tile-line is always a constant 512 - number-of-lines-per-tile [7] IMPLICIT INTEGER OPTIONAL, number-of-lines-per-tile is always a constant 512 tiling-offset [8] IMPLICIT Coordinate-Pair OPTIONAL, tile-types [9] IMPLICIT SEQUENCE OF Tile-Type OPTIONAL } Tile-Type ::= INTEGER { null-background (0), null-foreground (1), encoded-t6 (2), bitmap (5), encoded-t6-msb (6) - } T.4 not supported in tiled encoding ::= Ra-Gr-Coding-Attribute CHOICE { compression [0] IMPLICIT Compression } - The tag value used above preserves compatibility with Group 4 - Class 1 facsimile data streams. Compression ::= INTEGER {uncompressed (0), compressed (1)} - The 'Compression' attribute is supported by AIIM but not by CALS. ” CALS data streams always uses the default value of 'compressed'. “ It is not supported by CALS. - ###### RASTER GRAPHICS PRESENTATION FEATURES ###### - Ra-Gr-Presentation-Feature ::= CHOICE { pel-spacing [5] Pel-Spacing, spacing-ratio [6] IMPLICIT Spacing-Ratio, pel-path [9] IMPLICIT One-Of-Four-Angles, line-progression [10] IMPLICIT One-Of-Two-Angles } 91 Appendix A ASN . 1 Definitions - ###### RASTER GRAPHICS CONTENT DEFAULTS ###### - Raster-Gr-Content-Defaults SET { pel-path [0] IMPLICIT One-Of-Four-Angles OPTIONAL, line-progression [1] IMPLICIT One-Of-Two-Angles OPTIONAL, pel-spacing [5] Pel-Spacing OPTIONAL, spacing-ratio [6] IMPLICIT Spacing-Ratio OPTIONAL, compression [8] IMPLICIT Compression OPTIONAL } END 92 , Appendix B Test Chart This appendix describes a test chart to be used in illustrating examples of ODA Raster DAP interchange files. The illustrations are included in separate appendices where specific data values for each attribute have been inserted into the ASN.l definitions as shown in Appendix A. The test chart is illustrated in figure 17. The test chart image used was created by the CALS Test Network and was prepared and placed into the proper format by the National Institute of Standards and Technology using the Free Value tool. The bitmapped raster file representing the image is 2560 pels by 3584 lines and therefore has exactly 5 by 7, or 35 tiles. The image of interest is actually 2550 pels by 3300 lines which will fill an 8.5 by 11 inch page at 300 pels per inch with no margins. Within this inner image are border lines at all its edges. Since the containing bitmapped raster file comprises full tiles, there is an excess white space of 10 pels per line to the right of the inner image. Similarly, there are 284 unused (white) lines below the inner image. In figure 17, the hard copy illustration of the test chart has been reduced for reproduction purposes. If we imagine the tiles to be sequenced from left to right and top to bottom (the proper tile ordering according to MIL-R-28002B) every tile but 13, 14, 19, and 24 has its number rendered in text in its upper right corner. Tile 1 contains text which displays the size in inches, the resolution in dpi, the width in pels, and the height in lines. Tile 19 is an all white tile. Tile 24 is an all black tile. Tiles 8, 9, 13, and 14 have an X between them, running from the upper left of 8 to the lower right of 14, and from the lower left of 13 to the upper right of 9. There are also 3 wedges in these 4 tiles, one between 8 and 13, one between 9 and 14, and one between 13 and 14. The 24 other tiles are mostly white with each outlined in black. 93 Appendix B - Test Chart Data Figure 17 - Test Chart Appendix C AIIM Document: With Clipping and Number of Lines This appendix demonstrates the insertion of specific data values, representing the image in Appendix B in an untiled format, for each attribute into the ASN.l definitions as shown in Appendix A. It represents an AIIM example that is illustrated in Annex B.2 of ANSI/AIIM MS-53. It is an illustration showing the use of clipping and number of lines. The data values inserted are shown in column one and the transfer values are shown in column two. 95 1 <• 1 1 .• . * 1 1 .1 —» 1 *I H4 1 • i • ^ CM OQ U o A 00 A V A m a> 00 r— ;h i-H V V 4J Cu CO A E V-i S-i C v£) nJ V •u o A V CO to CJ 1— A u C C A A V 00 A o A o >— CM CM A V 4-) 10 O o m o VD V V 1— A VO to (U 1—1 A A 1—! r— CM on c 3 A V — CM CM V <— • » r— V V 4J o rH CSJ VO V V VO > o o > A CO o cd A A m u u I-H •— oo o 1— Sh A )H A 1-H c > CM V •u >— .— •u 2 'O ON z •u 1—1 4J 1— V o 1— in 1^ to > o o CO > 2^ to V to V o o CU i“< u C 1— 00 i— O c I-H CM CM cn •— c C •— •U V V u o 2; T3 C7\ o 2 O CM O m o .— o «— o 1— n) CO o 2 o 2 CJ o u ON 1—1 in Q %4 )-4 A c '— CN CM rO •— 00 O o r— o 1— 4..^ •— VO 4J V t-H 0 1— O CM O CO 1— O 00 00 o o 1— .— o to to V o CM 00 on -4' (1) C A C >—< oo o O * < t3 o CM •— I-H 1—1 r-H o 1—1 oo o iw 1—1 1 • o o — o 00 CO O on O o o o o o O o CtJ CO o V o 1—1 CN C •—> CtJ o <4-1 O on o o a^ cd in 1 r—» i nJ — — O CO o on O CO t“H CO CO CtJ o f— CM H 1— I—* <— o CM 00 on • o o m ca ttj ct) cd • • • 00 rH 1— m I-H CM Ov o cn 00 CtJ A 1-H 1—1 CM inm 00 00 CtJ T— o V ttJ • 2 0) tu 2 rH •U 2 •iH C CtJ o t4H a; E r-- O CO 2 CM Sh (U O Ph Sh 2 2 1 4-) 1 — CO 1 c 1 1 0) - - CM tu 1 to — 2 • P o o o - 3 CQ 3 •2 o o CO 2 - CJ 2 CM CM o 0) P O CO Sh o - CO - CO 0) o o 2 P 2 — O Q O •2 O I-H CM i2 CM 3 * 2 C tw - 2 o •2 CO o 2 — 1 1 o oo v.^ Sh 5 CO 0) OM -Td CO i2 1— •rH P • •2 p O I-H CO 2 O 0) 1 Cd 2 2 2 O CO •2 0) t4H : CtJ a r2 X — OJ 2 f-H (1) 2 •iH w P I-H I-H CtJ cn •iH 00 p Cd 0) 2 P 2 p P (2 4-) — tj 2 c I-H 2 cd o o 2 Cd o P O 2 2 E C OJ 1 CtJ o CtJ 2 M •fH to 1 ‘rH 2 00 P CtJ 0) Sh to 0) 2 •rH 2 I-H to 1 •r^ 1 oo to P 2 O X E 3 o 2 o w P Cd 0) 1— 2 u 2 p to P 2 2 OO td tu 4-) •iH 3 1 C O a 2 cd O d) O •2 (1) M P 2 P O 4J 2 o a; tsl •fH P 2 > 1 2 2 P 2 1 •iH to Cd 3 to O o e •fH 2 2 •iH 0) O 2 2 I P o QJ Sh •iH CD 2 *rH 2 2 1 E 2 O E 2 2 P p 3 CtJ 4J Sh 2 1 2 O 0) E o •iH 1 o I 0) •fH 2 4J to tu •rH o 1 2 > 3 p M 2 O 2 2 I-H P 1 4J • iH 1 cd CtJ — 2 •fH 0) 00 00 > Q 4J U o to oo 2 1 2 0) 3 CtJ 2 CtJ CtJ 0) p P P CtJ (U r-H O Sh CtJ 2 2 E 2 2 2 4J W) •n4 CtJ 1 1 ttJ C CtH Cd 2 2 c Q CtJ O 1-1 o P o JZ Sh 1 1 0) c 0) o 2 U 4J E O Sh 1 c 3 Sh 96 J i• 1 » 1i * —1 *« I .• 1i * 1 . 1 1 . - •1 1 1• . •. .1 1 > . 1 1 1 . 1 1 1) LO 1—1 X CO VD CO CO CT* A A CO VD CM 1^ • V V m x) 1—1 o CQ ro CM A VD CM 1— *— O P CNJ CSJ 1—1 CM V A CM . 1 00 •— CM p— CO 1— OV — — CO VO VO c VO T— CM p CM 1^ (P • • <— o 1 1— m CO o o UO O CO o • 1—1 VD VO CO u fp >d* m CO 1—1 o > CO > > < VO CO CO X CM T—1 • • 03 C A O o CO 03 in U 1-1 H V - p .— o p r— o o CM z o 1^ CO - X p CM *. O rH 3 p 1 VD 3 o * 3 m p T— 00 CM VD o 3 r vD 3 o O P VD 3 3 o CO r^ 3 1-H biO Z 3 CM r*^ 03 1— P VD 3 1— •V - 00 > 3 Q E P 1 i •rH 3 CO if CM CO P VD iJ 1 t ON 3 3 CM _ - 3 vD p E 3 - CM 1 r CO CO > O w 3 E '—>• •» 1 1—1 •rH CM 3 3 - 1— . CO — p <3- P O 3 s 1—1 CO 1 CM CM — z Q O fp w- CO CM w •iH CO P P X r CO 1— 1—1 p p M 3 O Q) CD W fO 1 f—l oo (D 3 uo P P 1 O f—l (U vD 1—1 3 CO p P W VD to 1 P Ml" 01 »iH w o rO o^ — CO CO •rH 3 3 v P 3 *1—1 •rH P O •rH 1—1 •rH c 97 1' * > 1 I ) I . 1 1 •> i1 > 1' *1 1^' A CO V p A p CO CO A A A c V rH A CO o A A V A V \o A T-^ o r—i m p CO V 00 V A A V V 1— p A V f— V ^—4 CM CM 00 w CO CO p p V V u C V p p A A p A A p r— CM p A A o u w rH p CM CM CO 1—1 U1 > 00 o CO > c V V CO V V c > o o > ' c M V c o c o H- —' CO o o z V o 2 u «— o f—. »— o 2 2 On 2 o o r-- hJ o 2 o o o o o 2 2 u CSJ r— CL, o •— 1.^ k_p CO .— o 4 . 1— CM CM CO »— p pL, CO r— m .— T3 o^ O O CM o CO o w > > 4-> 3 o cfl QJ •P bO C to cu O- 1 (U o u • •• — o •iH O O O a to o — O o o rH - CM CM o p 2 s -s OO 03 o o p o £ o rP N rH CM 3 - s Ip o z o • P CO 3 o o U O CM 2 W rH rH 2 - p 0) r o 03 1 3 w 1 •fH — i-H 1 3 - o o rH X 03 P t— — (U 1 — 4_l — •r^ bO Cd 2 £ fH C 1— rH 2 — 3 O o O CO (U p CO o td — Cd 2 tsl •fH 1 - > 0) rH 2 C a; •p p 2 u rH 0) • iH 3 p u Csl O 0) 4J P 3 3 W c 3 2 *2 p 2 td 2 2 Cd •p o O 3 o 03 3 o 98 .• 1 1 1i1 A A A T— VO V V V A 00 U CM CM A A A V 4J CM VO CO > > T— A oo O A !m P hM 1— V 1—1 V ro f— A A V 4J o Z z A V A V CM CO CJ Z z !-i m )M O cn LfO V !m A A p 4-1 A V r— 4J A CM V 1— V 4J fH iH o 1— V) m CO CO CO 1—1 CO V V O o P V o !m t— C V O u 1— H VO CM C 1—• 1— iH iH . A A O m 4J A A o CO 4-1 4-) o o 1 r— —— o o O o T— o r— W > f— 1—1 o •— CO > W > CJ O rH LO 1—1 V 1—1 o C M V rH o c HM c hM r*^ VO CM CM V t— CM O Z V 1— CM O z 0 z o — o O O 1— . hJ O r-' ,-! CJ z a z rH CVJ r-4 Pm O '—' !m CM Pm O •— '— CM iH o rH CO CO o 4-> i 1 4-i i r— Pm CO — Pm CO — O O o o o o CCJ W > > < o ^n > > < rH c M 1— '— O — 1—1 O P h-1 1— '— o • (— O 1 ' CO a o rH m O S z; CM o CO o Z CM o CO o lO CM CO CO cc3 O o i— vn r— m CM «— 1—1 CO CM VO f— 1— o CO o 1^ . i O ro O 1— ro O cd CM CM I • 1—1 ' — CJ I— O — rH 1— 1—i MD o O o <0- cO o o m <3“ ca cd • • 1—1 CM 1— CM fH A 1-1 O on A vo O cn ov ro i-l CM Ov CM V to • V CO CM 4J 3 o Layout o CCl r-- z CM CM 4J OO p , (J 1 p: CM Document o 3 O - 0) O O r O •• E Q O w CO Z cO I-M CO CJ W) - )M z !m O — cd 4J 1 ro p iH C4-4 . for O — iH 3 ' •1— 4M z O CO o Z o - 1 o o z Q) • »H C ccJ to 1 0) r 4J o r— O 4J (1) u O Z 99 1 4 » —11 * 1 >' . 1 * •» 1 '. .• * -I 1 . . ' . .• 1> *1 . ’» A A A A A rH rH A CN CN VO V V CO V V o A A A V V ro « A rH 00 «— — I— «— VO V V rH 5-1 CM CM 5-1 CM CM O V V iJ •U A A CM 1— 1— cn > > W > > CO O u CsJ CM 5-1 C 1— M c hH HH CM OO o u 4J o z Z o z CO V CO A V) > p> W V z CJ A A CM rH «— • C M M C — m OO CO VO rH 5-1 o rH o z z o •— '— 4H 0) V V V 4J A CM V o X o o I— W (Jv '— rH o rH o — CM a^ CM o l-i A A !-i A A 5-1 C V o 5-1 t— <— o o o o o o O O u> CM CM 4-i rH rH O) O m •U VO to V V W V V M O — W «— r— rH rH rH — VO CM CM CO CM CM p C c o o A VO C o o o o o O O o O O o «— «— o .— .— O (— CM o o a o o a o O a 0^ kJ V o • VO CM CM CM o I— CO o — T“H Cl^ o • < ' 1 O O O *— CO CO — TJ — 1— eu CO •— o 4 OO OO > < v£) CM VO vd- •— CM CN ro — rH o rH o t— l-H o OO cO • CO • • o CM O ro o o o o z CM o OO o o ^ o o o «— o^ rH 00 X) O OO 00 O 00 CO rH o CO o in o <)• OO CM QJ o \o CM . • cc A CO rH CO cd CM m Csl rH CO CO CO • CM rH OO V CC • • OT VO QJ c O) o d XI r-~- p •rH • p - - p - o^ o z ro p - . CL, O p - T-^ 5-1 - •rH UO CM cO t— • rH o o cd CM CO p O 00 1 CO p- c bO - (U a 1 OO o d d cu 1 QJ 0) 0) Q) 0) p CM rH r—l d 0) P u 4J 4H u c o TO CO rP p cO cd Cd Cd cd o — O > CO CO c C P P P o tP O 1 > C •rH iH •rH •rH •rH z bO 1 bO 1 TJ X3 TO TO TO p d P •p S bO T) 5-1 P P P P o bO •rH C U O O o O o p — P TO 1 o •i—t O O O o o o o d O P — CO o o CJ O o O u o p CO o O cu a cO o 1 1 1 1 1 CM c cu Op 1 p - O CO P- 1 x T3 X ;>v CO cu p CO P CO •rH 1 CO p d o rH £ d ip CU CO •P cu 1 CO o o cu X 1 X p CO C T— u o CM T3 rH •rH P p U •rH cu •rH 0) o o; X p cu o w •p 1 r-H a bO to X > o p- 1 cu 1 d •rH o p 1 p p (U •rH TO a cu p d d Cu TO p C cu o OP O C (U p o p O p p d c o o o o 100 n i » > » VO H 4-i cS TJ 0) W W OJ a A e CM o crv o CM M-l V O A A A W CM CM 4J V V V > QJ h-l 4J r— •— »— s; O CM o ;3 o 4_^ VO (4-1 (U CM 1— CM Cv CM o 00 o^ o o O O O o 4-1 pq CM CO CM o f— t-M S CO 00 00 ro CSJ 00 X) 0) X A A ucfl Xn3 o o CQ in o CO m CO S CM m bO C • (U 5-1 X C 4J 0) •rH V) X 1 O 1 u a 5-1 m t t •iH • 0) 5-1 5-1 •u u (U 0) ca o- XI E E £ 5-1 X o 3 p O ' o c c Cw . C • C (U J-) C o o 101 Appendix D AIIM Document: Without Clipping and Number of Lines This appendix demonstrates the insertion of specific data values, representing the image in Appendix B in an untiled format, for each attribute into the ASN.l definitions as shown in Appendix A. It represents an example that is illustrated in Annex B.3 of ANSI/AIIM MS-53. It is an illustration without clipping and number of lines. The data values inserted are shown in column one and the transfer values are shown in column two. 102 1 1 11 1 »• . > t 1 ^ I •1 1 ^ — i -1 1 1• • • * 1 CO OQ U O A iw 00 V A a> 00 >-i V u A a in A 1—1 s>4 C VO V iJ o V X in o A Cd C A A 00 5-1 CM A o A CM CM A V 4J m o o m VO V V A VO CO 0) A A rH CM CO U C 3 A V ' cs CM V V V u O r-M CM VO V V VO > o o > A CO o < » 1—1 CO A A in t— ;-i f-H M oo — o M Vm A }-i A C rs. f— « -) -> 1—1 f > CN V U — 4J •o ON 4 1-M 4 V O — m rH CO > O o CO > 5 CO V CO V o o -^ 1 1— <— r— * * 1—1 CO T— 1 c M 00 — o C M CM CM en C c — ON — *— 1—1 U V V u o 2; XJ o 2; O CM O m o o o o cO in O o o o o On 1-M in i 1.^ • Q 5-1 A C CM ro 00 o o 1^ o — — VO CM u 4J 1—1 o 1— o C^J O CO 1— o 00 00 o o 1— >—t o O ;-i CO CO V u CM 00 CO 0) C A C 1—t 00 o O •—• ’O o CM 1—1 !— 1—1 *—1 1—1 o 1—1 CO 00 o • CH o 1— o 1— 1—t o 00 00 o cn O o o O o O O o cO CO V V o 1—1 CM C •— CO o M-l o CO o o ON cd in 1 1— • • cO — -1 1— O CO • • O CO • • O 00 i-M 00 00 cO o I— CM - H 1— 1— o <0 CM 00 CO O o CO CO • • CO • • • • • cO cO • • • 00 iH t-l m I—I CM cjv o CO 00 cd A CM in 00 00 co- in I i-H o I V CO • • . -o 0) U p ) c 1 1 3 0) 1 1 o . 1 B. § o o CM o o — O O o - CO bO •u , (for a - o rr rH CM (0 d - o CO CM ro — P o CO •fH 4 £ - r- o CO (1) f-H rH d TJ o •iH - cO o rH CO o 1— N CO CO p d C4-I r CO P o •H P r-H o (0 r- cO 1 o cu cO CO CM CO C CO p (0 1 •rl CO J length 4 rH •iH O 0) > o O p d rH 4h CO ) 1 CO Example c 0 o P rH X (0 CM mH (0 bO X > (1> }H CO 0) •rH bO -H P 0) •rH d d IV d W' •^ s d o 0) p rH 4H cO P P X p o o o p 0) •u •iH p o CO Cu O CO in p •iH •rH bO o cO cn 1 cO rH o p d P rH • X > p CO p X O u d CO p P C c cO rH 4h cO CO cO P P cu •fH u CO c o o CO O 1 (0 P cO CU CO •p 1 1 1 CO P 0) X •r^ N •H CO d bO p d Cu Values +J CO 0) p V CO •rH P <0 •r^ (0 C cu <0 1 (V rH cO 1 p *r^ 1 S p P a- B d) *1^ E CO rH d (V Q I I 103 1 1 11 1• 1 —1 I 1 1 1 »1 1 1» 11 1* 1 —4 1 1'1 I .* 1 1 1 1) ' VO VO VO eo ov A m 1-^ VO V 1— O m eg A VO CM vO eg eg V A CM -d m A A CSI > -d 5-1 -d eg A M VO A A r— 4-) A VO CM V O CO 00 z A A A CO o m VO V CO -d O A V CM V A CM 00 tH C V VO 1—1 VO CM 00 'd 5-1 CM o CM 5-1 cn •o cn S-i V V V V A 1— V V ro eg 4-) -d O o o A V 4J VO VO 4J 1— r— • — 5-1 CO V VO 00 CO CO r™l rH o S-i VO CM S-I CO O <1- 4-1 C 1—1 i—1 CO CM 5-1 C (14 CJv -d c o o rH 4-» O 4-) eg ro CO o — o o O V 4-) o PM VO A A o CO > CO H-J C o o r-4 CQ u _< m 1—1 o eg A 0) c M A c D-i i+g PLi On o — CM 1— -d 00 5-4 C <7v O m rH V o m o o z o P-i CO CJ 1— m 4-» 0 — VO CM vD o o O V 1— V o 5 V o < < o CO o m r- *— ' ' ' « • 00 CM — CO — ON — — •d 00 VO VO C — VO t-4 CM 5-1 eg 1—4 • 1 »— »—1 1 1 4.) — o — LO o o m O 00 o — 1 VO n- v£) CO LO VO 00 t— o > > VO *— 00 • 1 00 OV d — d o d <—• 00 CO c M (—1 • 00 o m o o cn o 00 d •— 1— -d o 2: z CO o :=> m d VO VO 1-g o VO CO d" o o 1 • d in •— • o CM o O o o 1— -d T— d • • f— d >— CM m VO 00 d o •—• f— o 00 • 00 d • 00 d d • • • f— d • • o o O CO t3 eg 1—4 mA O O r-l CM V • - — 4J 4— 0 0 4— - X CM --- 4J 4J 10012 CO in d 0 - 1— CM 05 VO 0 0 VO VO 0 r- 5-1 03 00 - 3 vo 3 1 - I-- 05 1—4 bO 4J 840, CM 5-1 VO d 3 o 4J d CO - 05 Q e 0 - 1 1— CM rt^ C4-I VO •^g C cn 0) 00 C4-I 05 O' d - 1—4 2, •H 1 5-1 VO 4J - 1 1 00 00 1 0 CO CM 1 05 CM 3 0 4J - 0 1, 1 — > •d 4J 3 CM eg 1-1 Q 3 CO 4J cn 5-1 S { - M z 4-» CO CM r- 3 /«N 3 Vi^ 1— 1 •ig 4J — tiO 05 /I 1 3 X m '+H CO CO 3 CO c 4J 5-1 VO CO 0 - -3 0) CO 1 — d CO •rg 3 0 -d d 4J CO o CO eg C4-I d •o X CO n- 5-1 C CO 1—1 1—4 CO 1—4 •H 05 1 1 *3 4-) d Cl) i 0) 05 05 CM 3 cn cd 0 U e -d gj QJ 4J 4J bO S 1-1 C4-I Q 0 1—4 0) u CO CO 1—1 ‘rg •i-g C 05 5-1 3 X 4-) o in -o •H X X •iH bO CJ 5-1 VO 0) 3 1 •1-4 C*-l 1 C4-4 1 4J 5-4 —• C7V CJ CJ ts d CO CM bO CM 1 4J pi -d c 0 5-1 5-1 0 3 Cl) c 0 ?n 0 4J 4J O CD C - 0 5-4 d d 0 d TJ 3 0 cd 3 ' 1 1 1-) 1 u bO o •H 0- e • 3 CM CM C -Ml •iH d C •H TS 4J 1 4J 4-5 4-I 1 4J P Q 0 JD 1 d CO 5-1 CO 1-1 C c 0 4-) 3 3 VO u 0 3 54 i-i Xi 5-1 d o PM 0) 05 1 3 0) 0 C3N document- 1— •3 05 5-1 > C < d 3 3 £ 3 cri C 3 X 3 a 4— *3 4-) CD > d ' 0 0 Jn 3 CJ VO M 0 0 C 4J d 4J 3 0 0 0 4J CJ 0 1—4 O c TO CO PM 0 ’O 0 TJ VO 1 d CJ •H O •3 d) - 1 1—4 104 1 1 «1* .• 1 • 1 t 3 1• 1* 1 1 * 1 1< 1• * —* A CO V u A p CO Vi A A A c V f-H A CO o A A V A V VD A rH o CO U CO V oo V A A V A V 1—• 4-> A V 1—1 V 1—1 CM CM 00 m CO 00 u p VO V V 1—1 V C V 1-^ •p A A U A A p T—l CM •—* * U A A o 4-) (0 rH P CM CM CQ — 1— i 1 U > 00 o — (0 > c V V CO V V c > o o > rH S l-l Mt- V c 1—1 0 C o M 00 • • o M o z V (— o Z O — 1—1 O 1— 1— o z ON z o .— o o o o o o z z PLi CM 1—1 pLi o 1— •— W— •— 00 «— o •— *— CM CM CO I—* pLi f— 4-) (Xi CO .— UO i—I -o On vO o CM O CO < o m > > o 1—1 <} 1—1 «— t-l o C 1— 1— o 1— T—l O •— 1—1 o iH o 1— CM CM CO •— 00 o o 1—1 o O CO o z Z Csj o CO o o O o O CM o CO O 00 00 o o o r— CO CM CO CO CM VO o o 00 O o T) O CM • O m o 1— O CO O 1—1 o 00 00 o 00 oo O CO o CM t 1—1 C4-1 o — I—1 CM XI O 4J 13 O c« hJ 4J c 0) O o 04 Q tiO cd U CM o 04 O M-l P o •P z o CM •. 4J CO o o — O <— s c o CM P 13200 1—1 I 105 1 ) 1 1 1 « - 1 H 1 ^ 1 ^^ 1 —^ . 1 1 A A • v£) V A A <8> CM 00 !— A O A CM V V ro f— A A V A V A V CM <1- constr u ro }-l o cn cn V Vi A A iJ A V 1—* 4J A CM V •—I V •U rH CO in 00 CO 00 r— CO V V C V o S-i C V o Vi Vi VO CM C A A o m iJ A A o 00 4J 4J O o 1— ^—1 •— [5] p'. o -» CO > ro T— o 1— CO > CO > y o rH V tH o c M cn V rH o C M C M 1—^ V 1— CM o z V CM o z o z o 1— f—-» hJ o 1—• p y p y p «—* •—* CM Pli O !-l CM CL, O CM 1 o t— 08 4J PLI m 1— 4J Cu m •— »— O o o o CO > > < o > > < rH VO C M M o o c M M o <—« o 00 00 o t— 0 z CM O cn o z z CM o cn o m 00 00 a5 o ;=• y p p m t— m C^J t— >—• cn CM o VO r—\ 1—• o m o 1— o cn o 1— CM o cO • • CM CSJ rH fO o 1—) o r™l .... rH CM m CM 1-^ O ro • mA CO o cn • CM lA CM CC V ^ p 3 . o Layout CM CO P - P c y CM o a • CM Document 3 y 00 'O o 1 Q CM 1 . p ~ for O - b cp CO CO O { b CO y tJ y o cO p » a P o .. rP 3 CO y ,—1 C y P ' VI r CO 1 •iH y y o spacing CVJ Element a o = y y p 3 s y rH ,p o p p p O 1 P O rP p r E 3 3 p •P 1 y w P p cO CO •H 1 •p y 1 CO (p 1 P P y cn o y ^ •H cO y n P p y p P •p •p •p Data P CO 3 P bO cO > c y — Cp o cO P P P o CO •U y p Q p •p 1 y CL P p O "0 cO - >o P p 3 p CO cO CL pel-spacing — A •P C y —' 'O’ T3 3 p O cO P CL y 1 1 *H bO o y o *P 1 bO 1 y •P Qu P P •n c p p t! CL P P 1 iP 3 y ^ o y p cO y y 1 •H 1 CO 3 p y H y y p p y o y CL p 1 p P y y CL rH H •r-) 1 O* ’’—1 p y •c-) O P 3 3 p p Interchange CC! P P •p P 3 p P P p y y y 3 CO Vi o y P o CO y O 1 CL y p CO o cO 1 y y p • p 3 y y p P "T— CO c p y p P o p 3 P y — M 3 y y o y CL o o T3 y O •’—) CO fA o >oP y cfl 1 rP cO O T3 1— Cd ?p 106 —1 1 1 •1 1 t* 1 .i 1 «< —>• t 1« VO H wcd tfl •o •o A V 0) 0 1— E r— A CM 0 2] vO 05 CO VO 3 SH 4J 0 - 3 •r^ r-- 42 X •U 1-4 . . - - 5-1 54 A 0 r CO 4-5 A Cl4 0 44 - cd - 3 44 u 0 00 1 3 c bO . "3 1, 05 0 « C bO 4-5 CM •H 0 3 CQ 1-M C 0 3 m •H CO 0 0 m ^4 s 0 1—1 0 CM 44 CO 3 0 54 •r4 44 03 1 4-1 05 0 0 3 1-4 C4 0 { bO C 4-5 >o 1 4J 1 0 0 C 05 3 cd 54 3 54 • 3 -spacing- •H e 42 1—1 05 3 3 3 3 C5 05 •f-l 1 42 54 O. 3 Cd 1-^ 5-1 5-1 4-5 1 0 VO a u 4-5 05 0 3 •L 3 . 4J •1-4 -^ 1-4 CO 3 1 3 H 1 cd Cd 4-1 4-5 3 0 V f— 4J 1 •r4 bO 3 3 a i4 V spacing-ratio line 05 cd — C 4J 3 XI 0 1 u - CX a 0 c •H t4 •i4 44 3 C ‘H 05 T2 54 3 0 E cu 0 4J •3 0 44 3 1 54 bO •H 44 •iH 0 44 3 U 0 C 4J 0 1 1 3 54 3 44 cd 54 O. 4J 4-1 1 D. 42 3 42 0 i c 0 bO E •H ac 0 O. 4-5 05 1 C 0 1 5-1 C 4-5 3 0 3 44 • 05 4J 05 C D. •3 3 • 4-5 C 4J 0 0 3 • S2 05 C 0 4-5 0 44 ~ 1— 4J 0 3 C 0 0 1 0 0 1 C5 107 Appendix E CALS: Tiled Example Minimum Parameters This appendix demonstrates the insertion of specific data values, representing the image in Appendix B in a tiled format, for each attribute into the ASN.l definitions as shown in Appendix A. It represents a CALS example using the minimum number of attributes in the ODA Raster DAP. The data values inserted are shown in column one and the transfer values are shown in column two. 108 1* 1 * 1> * 4 I1 '1I ^< » ^ 1 * - .• 1 •1 1• * 1 1 1 1• 1 A 00 A V CO ro 5-1 CO V •U CO n 5-1 C m •d 4-) o A CO CNJ -^ W o 1 C A A V 1—1 CM A O r— CM CM CO CO A m CJ VO V V 1— Parameters fH fH CM VO A rH A rH A V I— 1— 1—1 A A A CO O CO VO V Values VO > o o A mJ- CM 00 iH «_• > iH 5-1 rH M 00 o M VO V CM V oo V V p A CM A V 4-) t3 o^ 2 V V CO CM p O CO 1 1— 1 CO Image CM > — — p V 5-1 5-1 <} of A 00 c M CVJ r- CM CO tH 5-1 VO CM CO o iH p C CM V 40 o O CM O CO o •P o P CM CO CO o 1— O rH to O 10 > CO hJ hJ C o o 1—— 1.^ tH 5-1 A S 00 O O rH o A iH c M A C Oi tP Cm Ov o CM Transfer Set V 4-> rH o I— o 00 00 o o uo o o 2 O rH O Cm Mt Cm CO o 1— o Test m V o 00 V o V o _< _< o 5-1 A C 1— XJ o CM XI CM fO ON 1— — 00 1 • • r— 1 *— I 4-) 1 o I— — o CO O o — o — m CO o o in tfl V o rH CM m VO 00 1-M C 1— t4-l o 0) 1— vt 00 1— t— 00 ov CO iH 1—1 05 o *— • • • • Minimum O — O CO o O m o O CO O 00 Raster o rH ------I-I o V CO . . . Td cn 05 (U rP CM H P p VO Image H c p CO - (p <0 to o CO a 0) O p (U p •p CO - CP p o (p CO M CM Test CM Cp •p 1 - p o tp 1 C 1 1 CO CM — tp 3 Parameters cp - Tiled r CO p H CO o fp fH 3 fp 4—1 •v to CO - - — tp to CO 1 CO •3 3 p rP •p o — o cO CO VO fH p 1 1 c P CO 1 0) CM o CM o cO 00 3 P P Elements •v for a 3 o (U p 0) o o 1 fp CO fH 3 3 3 •p s tp of 0> P p o N iP CM 3 rH <1> CS] o O P P 1p CJ p 3 to •P CO o O p 1 CM 3 CJ 3 •V -3 Ed 3 CO p p — CO Ip 1— •H 3 p Ei4 0) 3 3 p •p o CO CO p fH P to -O' 4J 1 P P Set cO P p 0) x: ~- OJ P Ip 0) cd rH o a CO Cd 3 •H *H Values P — CO 05 p bO cO 05 •V p in x) iP x: x: Data o C O o •V cO 1 p •p 1 CO cO O O x: H p CM o 109 •t 1» i 1 1 » 1. 1 1 11 1 i1 1 1 1t 1 41 1 1^ 1* 1 1 1 m m VD o m CM VO A A A vo VO A VO CJv A o V A m V (V r—J 00 A CM A <) o A V VO VO V V u V A V A V A 4-> CM }-i ro C3V TO 5-1 m 5-1 CO 00 m r—« o A V 4-) VO VO 4J A V 4J A V 1— V C VO cn CO CO 00 CO CO 00 o en CM i-i C 04 o <3V C V T-^ C V 5-1 r-4 5-1 o O V u o Pl, VO VO A A o 4-> A A o 4-) 4-> CO o CO o r— CO > m o r— CO > CO 1— cn •o CM T— C3V CM rH • • • • • • • • * cO A O O cn A >—1 o cn in <-l CM CM CM V cC V «0 • 4-5 p CO p O 3 •p 45 O O p P • cd So p 3 CCS CO CO 4-5 4J P CO 3 05 3 O c CCS Pi O o O •rH bO C Jn 5-1 P P i c3 45 1 3 •rt W 3 4-5 4) 5-1 P 4) P 3 E 45 3 E 45 CCS 4-5 (4-1 O 3 bO E O 4J P 45 —1 o P VO •rH c Q H 45 P C 4J Q 45 cp CO - CO CO 3 CO 110 <• ( — .* 1 »< 1 . > < «1 ^1 '>1 )1 1 1 I 1 1« 1 • o eo ro CO aio u bO C 0) A CTi 1-^ CJ •— CO > o 4-> o 1—1 O c M 1—1 !— O C M CO 1—1 V V •—* r— V 1— cvj o 2 V 1—^ CM O Z c r— o o r— f'' hJ CJ 2 r— C'' l-J CJ o * ro — CO o CM Ph O 5-1 CM tH Pm O CJ 1—1 -o On 4J Pl. m 1— 4J Pm CO 1— cn > > o CO > > 1— > CM 1^ CM cn C 1— M o «— 1—1 o C M 1— o •— rH O VO M CM cn o tH CM t— CO CM r-4 CO 82 1—1 • • A 1—4 O CO • • • A >—1 o CO • 'O' ro CJN CM CM CM cO V Cfl 4J 4-) 3 o o a cO c H-) o •H 4^ 4J 4-> c c o 0) (U Pm " § § _ 4-5 o — o b <3 o o <1> .— Q Q o 4J ,— c - o 5m o o o o s o = u CM M-l O (H rM o •* CO s s 5m o iH (1) O O — o U e 4J O cw CM •o C cO tH C O Cm CO O OJ 0) 5m r .—. OJ rH OJ CO 4J <3 rH X B I4M 6 x> •H c C 4-) •H 0) r 0) (H O OJ :3 iH C4-I rH 1 5m O iH 1 •H •H E X CO IjJ 1 OJ r Cd 1 •U 4-> OJ *H 4J rH •H C 5m iH 5m c CO tw OJ O Cd X CCJ cO o CJ ' "H x5 Or X rU 4-) N •H 4J CO •H 1 cO cO cd - cO 1 •rH 4-5 c OJ >v ' 4J 4-) 5-1 Q CO T) OJ •u Q -O' •o 4-) c Cfl G O 0) o -o CO o o OJ Q O JD .H — OJ 4J c •H X > 0) C (1) XJ bO OJ 1 1 •H bO 0) 1 1—) c <3 o X 4-1 a 5m 4J 73 4J (X 5m X o bO •H X p d 4J cd CJ O O 5m CO O O O CJ C o iJ 4J cfl CM Or a) 05 ,4-) 0) O rC (1) -U ' 1 S •I—) 1 di -r-) XI O ^ 1—1 1 a X o cO 4J •H 4-> CJ- rO Xi d V4 O -D •H o X 5m 5m 5m 5m 1 ^ C O 1 cO 1 CO 1 O 1 rH 1 iH 1 CJ 111 « 1 » i ^ 1< 1 . o 1 1 1 H 1 1• . •« Ooi 4J bO S 0) A VO 0) o 4J <} •rH cd Cd cd cd cd CO c cfl cd cd cd cd Cd cd cd Cd 4J 4.) 4J 4J 4J data •H 4J 4.) i-> u 4J 4-) 4-) 4J 4J Cd cd cd cd cd o V iw cd cd cd cd cd Cd cd cd Cd Z Z Z z z CO 0) A T3 z z t3 TJ Z •d A •d z A u •o A VO A 03 A CQ 03 A 03 -d- 03 o u C CO CQ CO oo co 03 in OQ CC3 CM bq 00 03 CO VO CO CO CO o CO -MSB CM ro M Ov CO CO CO CO CO CO CO CO "d- CO a 00 a a 00 a VO a c V f*-l s A Z A a A a A a CM a A a iH a r- a A 1 CM 1 A 1 1 rH 1 A o 0 V 1 1 O 1 1 CO 1 V 1 m 1 V 1 V 1 VO V VO V V CM CO r) Ml m VO m CO CM "d z m z z z CM A 4-> TJ 1-^ 13 z "O CM z r— •d 1^ •d Td r—<1 •d CM d d iH d 1— d 1— d CM ’0 <»• o 'd' n (l> V Cl> V (V V (U V 0) 0) V 0) -d- d d V •d" z V z 'd- z z V A CM V \o C T) •o TJ o T) Td z -d T5 o o o o o encoded f— r •— *— »— r *— a> o > o O — O r— o o > o o > o > o CJ > o — V > o > o V o U A o M o o <) O o o M o -d" o M CJ M o mJ- c M c 'd- c M c M c -d’ CO U CM z c c c c c c c c c d d d d d > f— z CO V z (U > ID > 0) > 0) 5 <0 > (U 5 d 5 d > 5 > 5 z > »—— o o A in t: VO M M M M M M VO VO M VO i— VO VO M CM o o VO z VO z VO z VO Z VO VO z VO VO VO z • • z • • • z V o o • • • • • • • • H H H T.6 z •—z z Z z z H H z «—z CM o VO > CO H H H H H CO H H d H o H d ro -d" CM CO •— o r—-1 CH M o Z d O rH rH CM rH cn -d 15 VO CM z T— CM CO <1- in VO oo CTv rH rH rH iH iH < 0) o CO '— CM CJv z> T) o TJ 0) r-H rH VO CM CM t— o ro VO d CM o O O o 0) (U cd a> C3N 0) 0) 0) o 0) CJV 0) o d O d d d o d C3V d O d O d z r— i-H f-H iH rH rH rH rH rH 00 4-) 00 4J 00 4-> 00 4J 00 4J 00 4J 00 00 CM <1* 1 1 1 , 1 1 1 1 1 o VO CM O -d- 30 CO m 0) z3 a a a a a a a a a a a a a a a •H •V •V Ml A A A A A A A A A A A A A A A s cn 4-> A A A A A A A A A A A A A A A o U - « z z z z Z z Z z Z Z z z z z •» cd ^ CO CO z z Kn z c/3 z z z z z z z z o 00 1 a a a a a a a a a a a a a a a 00 ~ oo 1 1 1 1 1 1 1 1 1 1 t 1 1 o •V c c CM 1-4 O •H z z z z z z z z z z z z z z z o Z in VO z d d d d d d d d d d d d d d d W- O in z z z z z z z z z z z z z z z z z rH O CM 1 CO o o o o o o o o o o o o o o o s 00 1 t3 1 o o o o CJ c; o o o o CJ o o o CJ c Ml d z c c c c c c c c c c c c p c c H bO (U -13 d d d d d d d d d d d d d d d d 4J z C O z 3 o M4 1-1 O o VO VO z z z z z z z z z z z z z O o d I-I c o • >v t Z 1 d 1 H H H h’ H H H H H H H H H H H Cd Ml CO Ml cr tH d cd d CO d 1 1 1 1 1 1 1 1 1 1 t 1 1 1 1 1 z Z CM d CO Ml 4J • rH rH CN cn z z oo (Ov o rH CM cn in d O CO CO •H C iH r^ tH iH rH fH 1-1 d I-I z o Cw Z d •H d d d d d d d d d d d d d d d •H 00 d CMrM z rH iH rH rH iH rH rH rH iH rH rH rH iH rH rH 4-) 1-1 C Jo * rH Cd •H •H •H •H •H •H •H •H •H •H •H •H •H •H c H iM Cm cd e H H H H H H H H H H H H H H H d z z o z V V V V V V V V V V V V V V V z o Z 1 1 o V V V V V V V V V V V V V V V •H o Z Z 1 CM 1 1 Cd d C 4J CM • z •H c o 00 s 1 d 1 c 3 z 4J d 1-4 c C c p- z d o o z c; 4J o C o o 112 1 * 1 » 1 1 1 1 <1 ( 1 1» 4 11 1 1 1 4 1 1 ^1 (I 4 1 4 1i 1 11 1 1 1 1 1 I ^1 ' Cfl to cd cd cd cd cd cd cd cd cd cd cd Cd cd cd cd Cd cd 4J 4.) 4J 4-) 4-> 4J 4-) 4-> 4-> 4-) 4-) 4J 4J 4-) 4-» 4-) 4-) 4J cO cd cd cd cd cd cd cd cd cd cd cd cd Cd Cd cd cd cd cd tj *0 TS TJ P p P P P P P P P P p P p P P A CQ cO CQ CO CQ A OQ cQ CQ oQ CQ A cQ CQ CQ CQ CQ CQ CQ cQ cQ A CO w C/3 CO CO CO Ov CO CO CO CO CO <1- CO CO CO CO CO CO CO CO CO 00 a s s s S 00 S a a a a Ov a a a a a a a a a O’ CM 1 A A 1 1 A 1 CM A A 1 A t A 1 CM 1 A 1 A A 1 A 1 A 1 A 1 A 1 A 1 00 V CJv CJv V CJv o m m V CJv 00 o cn CO <1- CO V T) m •o m "O t3 CM P P m p VO p CO p CM p p m p UO p m p on p CM p VO p VO P VO p »—— » (U O o f— o VO o — o > o — o — o — CJ — o > o — o — o o — o — o — CJ 1— o CJ > M c c c V c Mt c 1— C -J- c 'd- c -d- C <}• c 1-4 C <}• c vd- G c -d" c c Mt C c C 1-4 a> (U 0) a> 0) z 0) 0) 0/ (U IV z cu (V cu IV CU cu cu cu (V z > > — > p > > > > p > > > > > > > > p VO 1— VO M VO H p H H p H p H p H p H H p H p H p H p H H P E-i p H p H •— i..i^ M fc— f-H «— > 1 1— VO * 1— 44 rH VO 00 Z CJV o CM CM CO -d- m CM VO r- 00 CJV o CM cn O’ O’ r-l rH P I— CM Csl CM CM CM CN CM CM CM CM CO CO CO CO CO rH CTi M-l in t-4 Cw o r^ (—1 1-4 p cw (V VO 44 CO <}• CO CO o 0) On <1> CJV 1 <1- 1 1 1 1 1 1 1 Mt <} <} <} 1 -d- 1 1 -d" , d- 1 -d- 1 Mt 1 <}• 1 <*• 1 <) O’ O I o 1 o 1 o 1 o 1 o 1 o 1 O 1 o 1 O 1 o 1 O 1 o 1 O 1 O 1 o 1 o 1 O 1 o 1 o a X a a a a a a a a a a a a a a a a a a A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A CQ cQ CQ oQ CQ cQ CQ cQ cQ CQ CQ CQ cQ cQ CQ CQ CQ cQ CQ CQ aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO 1 1 1 1 1 1 1 t 1 1 1 1 1 1 1 1 1 1 p p p p p p p p p p p p p p p p p p p p p(V pIV p(U plU pIV plU p0) pcu p0) pIV pIV pIV p(U pCV pCV pcu pcu pcu pcu pcu o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o G G G G G G c G G G c G G c G G G G G G (U CV (U cu 0) 0) cu cu lU (0 0) (U cu cu cu 0) cu cu cu cu VO VO VO VO VO VO VO VO VO VO VO VO VO VO VO VO VO VO VO VO H H E-i H H H H E-i E-i H E-i H H H H E-I H h" H H VO 00 CJV o T— CM m IV IV 0) 113 0) (0 <0 «S encode' encoded is is data -MSB -information content_portion encoded content T.6 35 length>) length>) 00 tile 00 00 -- (00 (. indefinite indefinite -- 114 Appendix F CALS: Tiled Example All Parameters This appendix demonstrates the insertion of specific data values, representing the image in Appendix B in a tiled format, for each attribute into the ASN.l definitions as shown in Appendix A. It represents a CALS example using all of the possible attributes in the ODA Raster DAP. The data values inserted are shown in column one and the transfer values are shown in column two. 115 i • f1 « 1 »1 1 * •1 t> 1 .1 1 1• 4 .1 1 1 1 *• 1 1 1* Null and A 00 A V A CO oo r-l 5-1 Parameters V V 4J n A 5^ 5-1 G V£> 4-) i-> O A 01 01 o 1-H C C A A V <8> A O A o *— CM CM A o m CJ VO -O’ o— V V A 1 < A A 1—1 1—1 CM CM OV A V i— CM CM V 1— «— 1— V Values Avaiable in VO V V VO > o o > A 1—1 1.^ 1.^ -^ constr A m 5^ 1— r— M 00 o M 5-1 A 1 CO V V .— 4J z T3 4J V 1—1 01 01 01 Image > o o > 5 V 1 1 ^ r— CM 5-1 5-1 C M — OO o C M CM CM CO — G J-) ON 'Z CM CO f— V o •o o O O O o [5] 0) 01 o o O a\ 1^ I—* *— 5-1 C A C — CM CM CO — 00 O o 1—1 o Transfer iJ o 1^ o .— O CM o ro »— o 00 00 o o «— Test 01 Possible o V o CM 00 C A A •— 00 O o •— X) o CM •— 1— o 1—1 cn 08 1 • « o 1—1 1— t— •— — o OO 00 o CO O o o o O o V V CM 1—1 CM •—t 1—— i— cO o Cw o 00 ON cd i • • • • • • 1— 1— 1— O CO o CO 1-H 00 00 a5 Raster o 1— v£> all 1— i—— CO 1—1 o CM 00 XI o o CO cO • • • CO • • • • CO • • Tiles Interchange ^ 1—1 1—1 1—< CSl 'OOcoocnoooo ct Tiled Using .... »-• A <—t VO csi VO oo 00 00 0) i-H ------CM O V CO • Ti Cl t 01 4J 4J 4-) •d 1 1—1 4-> Image G G y •rH 01 01 cO 0 *4-1 01 01 E 4h O Cl 01 5h H 0 CM 5-4 5-1 0 y 'd "d CM a a C4H y Test CM 1 1 4-> 1 1 1 01 1 1 G 1 1 1 G 01 01 d y { Parameters p - 5h - » 3 1 d Raster • ' - o 1 4J 0 cn o - — 0 - CO - - 01 — Q 0 0 y G spacing s z y 0 CM - C4H 0 5-1 1— 1-H 01 •iH 0 — 0 0 — 1 •H O c r 01 4J CM 1-H 0 G 01 - Tiled 4H CO 01 cn y CM — 0 01 i-H •iH 0 1—4 N 1—1 en -iH y 4-> 1-H 4J 5h Available Cl 0 5h 0 •H CO 0 G 5-1 01 1 y CM T) 01 4-) CO bO -) 1—4 4J 1 116 ( 1 1 i1 1 J 1 •1 1 » » t < . 1• 1 1 1 « ^n• < • 1 H * « A tH 00 CO V CO S-i A A CO 4-> 1—1 1— CO V V ro *13 G A A CO CM A O A 1—1 A rH t-H A CO o f— A CM CM VO V V rH CM 00 1— A A V VO V CO CO A V V CM CM V 1— > > -1 r— VO V V 1— M M u CM CM VO A 1-H A Ml- A A 1— Csl 1-1 4-» A A A CO O CO m V 4J CM CM 4-> t— •— •p 5 CO > A CM 00 1-^ CO V V CO o o > CO 1.^ > > G M M VO V CM V 00 V ’G V S-i A CM G G M 00 o H-l G O g: V V CO CM 4J o O 1— r—% o z T3 o\ z O V 5 r— 1— »— V4 CO V o o o o p p o ( <}• •— 1— •— r— r-^ r— T— U VO CM ro m XI VO VO t-H o VO CO XI o • • • • o CM o o o o -d- m \o 00 cd • • • • • 00 cd • 00 cd cd CO 1—1 VO • 00 o MCO •V > .— cd - 0) ' fp 1 CO - *r^ * Ip (p CO CO O tp « (U *p s p cd —— O o *r^ G CD 1^ fp fp CM o o Dd • iP G 1 CO G o (U O CM 0) - cd iP 1 CO 1 cd t o N fp cn o CL. > cd CO CM (p 0) •f o •P fp CO 1 > 1—1 1—1 OJ p CM o CO fp p G 1-H bO 1 CO 1 -o G o o t Cd fp 01 G G bO VO rH 1 P CM fp CM a> p Cd 0) CO — -P G 0) CO CO ON 0) CJ CO bO c: o X 1 - f (U O •P ip 01 - 00 p a> CO fp fp cd o •p CO 'd- o o cd o •p CO o CO 1—1 G p G cd a. N p 1 - f Cp cd •p &I cd cp CO o z CO p o p fp •r^ p G X cx P CO a o cd CO CM p CJ X •p G cd fp p G o O 1 t •P p CO cd CO p rP CO Czh (V fp 0) V CM CO O CJ 0) cd o > bO 1 P (U 1 Ori r-4 o cd 4J G p P G N •p CL. G X 0) P •v 1 1 .p fp •P G fp • G ip tP CO Cd cd cd 0) •iH p 13 •P - ip f •p CO (U G 0) o m X 00 E p P P E fp Ou G rP a O rH p CM I o^ 1 a> CJ p •H o a> 1 o CO o •P C! p C TJ P C •G X > E G CL •> «V o p P cd o 1 cd 0) CM 1 t cd cd 1—1 o E •H (U 1 p 0) •P 0) a CJ 1^ G P 'O 4J ip p G bO ’G bO CO *p P •V O u Cd •p G O cd G cd rP •H CM cp cd o Cp G CJ CL. E CL X 1 *rH o E CL. .P o 01 G c 1—1 p 3 cd p 00 bO O Cd x> a O •V 1 cd C •P 4J d 1 o •> p CO 1 cd CO cn a fp T3 G p CM X p a 0) •* G o 0) CL. £ G p > cd 3 p cu 1 o G p cd CJ o O G Tl o ’G u •r^ o T) 117 ft 1 . 1 . 1• —t 1 1 < 1 * . .> — 1 — i 1• CO m VO A A A r^ VO V V o m V A A CM VO 1— 1 <6> A — A 1-H rH 00 :-i CM CM VO V V A A V 4J V A VO VO ' —' CO m . i-H cO O CO CO A CO m . • . • I vo <) cfl oI— rH . V td • , p I-H o — to P" p P CM 1— o K Vi c V p m C 4-^ 1 1 u VO O p r-- H -- iH C4H VO p p rH p 1-H bO cd in (U u VO ca p O 3 0) 1 a E P •v *0 ^-1 •iH other-coding CO 1-H :3 p VO p 4-> - Cd rH > C3V CO 1—1 * CO bO — > Cd *H VO P P 1 :3 1 C 1 > p O CO u 1—1 CO cd •iH 1-H bO 1 p- CM p Pi •V <4-1 c o C b£) •H p CU o ca CO —1 klH C CO p P 100 •o •1-) Cu - CU o •H cu CJ fO bO O 1 CO CO O o ca O 4J CO C }-i ca CU CU bO -rH 0) 4-4 o CM 1 P £ -of O c O cfl a a i—H Cu C r-H ca •H p 1 rH 1 1 4-) 1— • Cu CO •iH u VO bJ >-l > cu 1 O 4.) Pi p W u 1-1 cd [ bO C r-4 ca C •iH <4H VO p p type iiH 1 (1) •H CU CU CJv 1-H 1 cu P P P >-,cp 5-4 a- 1-H a CO s o P VO cd cu cu CO 1 CJ) Q P tH 4J bO CU P VO CO P CO ca •o c CJV P • p ca c 1 p VO bO p p u ca 4-> p 118 1 « i '1 1 1 1 • ^ '1 » 1* 1 1 1 ^ ^1 1 • 1 ro U m1^ VOb vom O vo 1'' CM CTi u CM - VO vo Z 'O’ rH 00 . . . VO , 1— VO 1 — •V - vo in CM 5-1 C3V C3V - -O’ o 5-1 •H CTv CN *H - 3 in CM tH td -O’ o cO o o O- CM cn vO CQ CQ TJ O- 1 3 m u CQ 04 - 3 bO 3 - vo vo CO 4-4 1 cn 04 04 3 4-4 3 3 G value CO m T—( 3 > 4J 4J 4-4 3 4J 4J •H 3 r-- — o X4 CO CO 3 G 3 3 3 > in tH CQ 1 •1-4 G c G c •H c 52 3 iH 1 vo VO 05 CQ 04 5-t o H •H •H "3 -H •H a — bO CM CO vo 3 0) 5-1 4-4 •H •3 3 •3 O -3 •3 3 52 - r-. 4J vo «— 4J 3 4-4 CQ 5-4 5-1 O o u 5-4 3 O -H - O G in CO 3 4-4 CO CQ O O O o o O -a- 3 •H O 4J spacing- m 0) vo > rQ O > O 04 O o o o o O bO O 3 — CO s •H 04 CQ 5-1 -- O o o > O CJ 52 3 3 52- (U C g •u 5-1 4J O bO 1 1 1 •3 1 1 •H 42 O- 5-1 3 s O O o rH 4-5 •H •H O bO 4-4 0 O 4-4 3 1 1 X - CM 1 CO •r^ O 3 4.) Z •C 4J 5-1 G CQ O 3 bO bO 3 -O’ 4J 1 CO cO O a- co •H 5-1 O iH 0 52 G vo O- o. G pel 1 CO (U <4-4 1 5-4 CO 04 Oi 'H 3 3 3 •rH -H CM 3 119 11 * * )• 1' 1 •• ’1 51 1 1• 1 1t ( » . 1 I . 1 A 00 V A P}-i A m Cfl 00 A 'J- A A c V t— V 1—1 A CO o A V A V v£) A 1-^ o P CO P CO V 00 V A P A V r— P A V 1—1 V 1— CM CQ 1-H 00 Cfl CO 00 p p VD V c V p C P 1—1 p p p fp V A A A A 1— A A o P A A o P Cfl 1—1 rH p CM CM Cfl 1 1 — — 1 cn o OT > o 1^ o u > c V V Cfl V V C > o f— V fp c M m V rH C M o c o M 00 V 1—1 o z V <— o z o f— 1— o I—* »— o z r—i 1^ hj o z — z o z O O o o o z u ' • — 1—1 o 00 1p o t—t Tp CM z 1-^ o (P 'd' O • * • • O o o cfl o o CM cO • cO • • cfl • Z T) CM t-H O CM r-l A O O cn A CO O CO • in O i-l CM m CM V cfl . V CO • • • •p d Root o p Zca o o Layout p P 1 c p ID d 0§ o o cfl 0 0) iP Q W) Document 1 cfl P u CP C 0 •• •> cu 4-] CD E P s d •• •P o o o for ^-1 CJ = 4J Cfl o o o ip c o 1—1 CM CM •o : 0) CP s cn CD o B B O tP N Ip 1 r 0) o s - o •P 1 P O 1-^ o p O CM Z Cfl p Element - 1 o C CD cfl c: CD M-i p Ip P P CD P Data o •O CD P o CP CM Z CD P p c cfl Cfl C cfl CP P P — O TJ Cfl o z cfl •P O O C O O >1 cfl O •H CD — •p Cfl •P Z d (D jO C N O N P P C z CD 1 1 •p 1 1 •p 1 *r4 tkO P CD •P O P •P *P P P> CP P P z c •P p a p p Z CP P P Cfl P P o Sn o o p cO Cfl o O CD P 1 o CD C O CD d o a> p P CD o O CD P P CD o CD Z > cfl 1 cfl 120 1• 1 11 1 1 «t 1« 1 1 1* ).« 1* 1• 1 1« ’ A vO CM CM A V CM f-^ A 5-1 o A A V tH 4J CO fH A V tA A V A A V }-i CO A C O CO VO <8> CM 4-) A V 1— CM O A 4-) 4-) 3 d o o pto ptc 4.) 4J c c 0) 05 O O QO QO - 5-1 5-1 b O - O P o IH o 05 o o 4-) G *— 4J o s c CC rH C o fH o 05 5-1 r 05 iH s E 13200 G tH E p - o 0) 05 iH 1 5-1 O rH 1 5-1 - 4J 1 05 r P 1 0) tA (U •H •H G o o 0) 4-1 p O rC cd •H to — 4J p P p tA 4-) tA 4-) p P to { vertical Cd - to 1 C 05 >v c P p p <4-1 Q CO P 0) 4J p P 05 o — G to o O P ttS O P Pr o tj 1 ' -H rH r •H Q) — P C 05 ,P G N 05 bO 05 1 1 •H hO 05 1 1 P O p p P 4J (O, 5-1 4J P 4-> Pr U P c p p p c p; dimensions •H 5-1 05 05 cd O O O crt y >M O 05 P o tA 05 05 4J 4J 0) O P 05 4-5 P 05 P p p > •1—) 1 •r— 1 •'-0 tA o G Pr P o ) O- G u ctS P 4-» P P P P 4-) •H P o O 5-1 5-1 tA o O O O a) O O P O o a ij Ch 1 05 O 05 O c H -T-, tA p P "r— tA M :3 p 05 1— P P 05 o o P O O P 121 1 1 • ' ^t 1 (1 1 o ^ 1 • 1 1 1 » ^ A m M-l O VO VD Cvl VO V VO in o VO vO cs •p w c VO VO VO O A A A A A A A A A A A A O CM CM CM CM CM CM CM CM CM CM CM CTv a> rH o V V V V V V V V V V V V > > > > > > > > > > > > A A m OV o <) a-r^i—ivorovoooro 00 O' ov 00 00 OV «. 0) 0) • m *1—! (1) P p X P Cd r- E vD o 1—1 VO E bO 1-4 CO CO VO P4 P 1— T— W (U 1-4 CO C iP3 c 3 vO O •V •n 1—1 0) CO •H O *14 0) cO 1-4 b •H VO VO 44 CM in 1—1 cn u P p c jj X 1-4 cd , OV VO 00 •V C p (U CO ^ c •P VO (1) •V f-H cn CM o 0) CO bO o m o 3 2 (U O o p p X 4J o in VO c m o 00 _< CM VO 00 CM 1—1 CM cO CO P q_j CO : VO 1—1 4J CM o p CM CO CM CM O T— o O CO 00 54 CO VO •i4 r- (Q CO •V VO On •t4 cO S a C Q\ X ^ c 0) 1-4 CO CO in 00 •* •* 1-4 bO w P (U P 0) X O X Tj (U 1—1 0 e p O m 3 E T} CM cn in o O c 3 < tiO txO p 1— (V a cO CO 1—1 • X P o o o 44 E c o o CM C C c p CO •iH CQ c CM 44 1 O O •p •V 00 O 1-H 1^ • • CO •H CO CO <1> •H CM 1-4 o f-4 I"' iP VO C O ON •V - ON •H c O p CO W) P C 44 CO •rH X3 VO a> CO o o t-M vj* in in o in 4-) 0) Z a> 0) C i4 (V o p •H 1-4 W) -o VO •H 1 >d' Ov vO ON 00 CO p (1) 4-) i4 (p TJ o horizontal •H cO Cfl VO cd cO 1-4 P 1-4 o r*^ o 1 X> 1 c X c O (U C & P P •t4 Q a 122 , , , , 1 , 1 , . , , 1 , « —, , , 1 , , , A A A A A A A A A A A A A A A A A A A CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM V V V V V V V V V V V V V V V V V V V , , , , , , , . — — — — — ,— ,— ,— ,— , , ,— •— ,— ,— .— — — — CM CM CM CM CM CM CM 123 1 1 1 -1 1 4 — 1 1 1 1 1 1 o 00 CO cfl oa: V bO A O C CM CO (B ^ •—.(13ON^-d-00J2O 00 C7\ cMvoooocoomr^oo 00 c3 cO -d’ i-l O VO CM A CO > 00 -d- 00 CQ CM h- in CM CO 00 D CO • CO .-I CO V « • VO VO 03 m 03 c 4-3 VO VO o ZG -foreground •rH 1 4J - •rH VO VO Wt • 3m d 4J O b J 1 Oh vO VO o cd 00 I 4-) bO null c o r- VO 1-M 03 M Csl •iH o O 4J o m O - - •» C m CO VO vO — 24 i-M W O f \ CM CO o : bO - - VO VO C 3m 3m — 03 — •H bO O 4-3 C 4m 03 G 0 M •^ - VO vO VO 03 O 0 i“H 03 •• 4-> 4J 1 - - - >0 1 -background, c3 3m VO VO V£) C G u 03 O o <1> I-M 03 Z 0) c3 - - •* E •rH 1 CM d) 3m 3m 4J 1 03 03 03 VO o VO i“H 4-3 03 o 03 03 03 4-3 4M - - •* u 4-3 •fM 03 i-M G 4-3 to to CS 4m 4J 03 03 G G VO VO VO 03 1 •iM bO G C3- 03 •H •tM 03 null - - 4J G 4.3 C Z 1 1 44 Z (13 c3 — O G •tH •rH 4m 44 4M U 3m CM vO VO VO Q •rH 03 z 3m O O O o o to 19 - - •• G 4J Z o 4-3 1 1 1 o o 4J 03 O 3m •iM o 4J 3m 3m bO o o VO vO VO bO •iM O 1 1 cC 03 03 G 1 1 03 - - •* C •U a 4J 4M 1 -C3 Z •tM X 1—4 tile cS 3m 1 G O bO !-M •H vO VO VO X O 4J 03 1 G *iM 4J o CM G 4J 03 •tM G G 4J 34 03 G CM Z 03 •U 4M o >N o V G C o 4-3 o C 03 O hM 4J O G 1 o 1 O 124 , 1 , 1 , , , 1 , , , <1 , , , 1 . , 1 , , A A A A A A A A A A A A A A A A A A A A tH 1-H rH rH 1-^ r— r-H t-H rH V V V V V V V V V V V V V V V V V V V V r-^ .— .— ,— ,— ,— ,— ,— ,— r— ,— ,— ,— ,— ,— ,— CM CM CM CM CM (^^I CM CM CM CM CM CM CM CM CM CM CM CM > > > > > > > > > > > > > > > > > > > > M M M M 1— M M h- (—1 M 1— 1—1 l-l M l-l l-l l-i l-l 1— l-l z Z Z z z z z z z z z z z z z z z E. :=> z z z z z VD 1—1 VO rH VO I— VO VO 1—1 VO VO 1—1 VO fH VO 1—1 VO 1—1 VO 1—1 VO 1—1 VO o T— VO 1—1 vO 1—1 VO 1—1 VO 1—1 1—1 1—1 o o o o o o o O o o o O o o o o o o o o o o o o o o o o o o o O o o o o o o o oCM oCM OCM OCM OCM CMO oCM oCM oCsl oCM oCM oCM oCM oCM oCM OCM OCM oCM oCM oCM 125 . . , 1 , 1 , i , *, 1 1 • 1 . 1 I* I 1 > 1 1 1 1 1* ( 1 t1I 1 1 1 1 1 aio 1 4J bO c A (V C3V r-^ CJv rH a> cd cd cd cd cd cd cd cd m 4-> 4-) 4-> 4-) 4J 4-) 4.) 4J 4J !— « cd cd cd cd cd cd Cd V c A -0 •o T) "0 T3 •o •o A •o •H A VO 3-1 (W GO OQ OQ oQ CO C4 m CQ CQ CM CO A A A A A A A A A A 4J (V cy> w CO CO CO CO r- CO CO CO rH f— CO •o Z A Z A Z A Z A Z CM Z A Z 1-H z V V V V V V V V V V C c V 1 1 o 1 00 1 V 1 m V 1 o HH in VO m CO . . , , , , , — — — — — — — , , o V "C T5 f— T) i-H CM tj — •o T} 1— t3 CM CM CM CM CM CM CM CM CM CM o V 0) V O V 0) V CD Ml" (l> V ll> mJ- (V 1— -1 i-l •o T) ’O -o •o T3 -o -cd 1 1— > > > > > > > > > > VO 4-> > o — O — O #— o — O > O O > o M M M 1— 1— M 1-4 h-l H-l tH CO M <^ -d- O -d- O o O’ O H-l O O HH o Z z z z z z z Z Z c z c C c c c Z C c Z c 5 z z z z 1=1 z 5 > o 5 (U > 0) > cu > 0) > IV (V * * *“* *"** 1 -1 .^ 1— •— M V 1.^ H-l H-l h- H-l 1.^ 1— 1—t z vO z vO Z VO VO z VO VO VO VO 5 1— • • • • z • • • • VO r-l VO VO 1—4 VO VO 1—1 VO 1— vO 1—1 VO 1—1 VO 1—1 VO 1—1 «— VO ro H »— H H H •— H CO H H CM z z z z z z z z Z z z z z z Z z z A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A cQ CQ CQ OQ CQ CQ CQ CQ CQ cQ cQ cQ oQ CQ CQ CQ CQ ZCO ZCO ZCO ZCO ZCO ZCO ZCO ZCO zCO ZCO ZCO ZCO ZCO ZCO ZCO ZCO zCO 1 1 1 1 1 1 1 1 1 1 1 00 •o T) Td Z Td z Td Z •Cd •d •cd •d Td •d •d •d •d c cv (V (V (V VO VO VO VO VO VO VO VO vO VO VO VO VO VO VO vO VO o H H H H H H H H H H H H H H H H H o 1 I 1 ' 1 1 ' 1 1 i 1 ' 1 ' ' t 1 1 cr c (V 1 4-) C (V 4J c o o 126 1 t 1 1 1 1 11 1 1 t< 4 . 1 1 1• 1 1 c • c * »1 1 ' ( »' 1 1 ' to to to CO CO cO cO cO cO cO to cO CO CO CO cO cO cO «C 4J 4.) 4J 4J 4J 4J 4J 4J 4J 4J 4J 4J 4J 4J 4J 4J 4J 4J 4-) CO to CO CO to CO to cfl to CO CO cO CO to cO CO CO to td T) •o T3 T3 •o P P p P P P P P P P P P P 'Q A A CO A CO CO A cO 'O’ CO CO A CO CO CO CO A BQ Qd CQ CO A (O cO OQ CQ 00 00 CO VO CO CO r'~ CO o CO CO 1 Mt 1 'O’ 1 cf 1 1 'O’ , , 'd’ I 'd’ 1 'd’ 1 'd’ i 'd’ 1 'd 1 -d t •d 1 'd , -d 1 •d 1 •d , -d O 1 o 1 o 1 O 1 o 1 o 1 o 1 o 1 o 1 O 1 o o 1 o 1 o 1 o 1 o > O 1 O 1 o 1 o a a a a a a a a a a a a a a a a A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A ICQ CQ CQ caQ CQ OQ OQ BQ BQ cQ cQ cQ BQ CQ CQ aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO aCO 1 1 1 1 1 I 1 1 t I 1 1 1 1 1 1 p p p p p p p p p p p p p p p p py py py Py Py py Py py py py Py py Py py py py o o o o o o o o o o o o o o o o y y y y y y y y y y y y y y y y G G G G G G G G G G s G G G G G y y y y y y y y y y y y y y y y VO VO VO VO VO VO VO VO VO VO VO vO VO VO VO VO H H H H H H H H H H E-i H H H H H I I I I I I I I I I I I I I I I 00 o |H CM CO m VO r'. 00 (dl o iH CM m "d m 1^ CM CM CM CM CM CM CM CM CM cn fO cn CO CO CO y y y y y y y y y y y y y y y y rH iH iH rH iH iH iH tH iH iH iH iH rH rH iH •HH •HH •HH *HH •HH •HH •HH •HH •HH •HH •HH •HH •HH •HH •HH •HH V V V V V V V V V V V V V V V V V V V V V V V V V V V V V V V V 127 n i 1 1 I *1 U) 01 cd «d tJ 0) 01 cd cd cd Cd cd cd w ti u •u 4-> 4J V c cd cd cd cd cd cd Q •O T3 •o •O Td Td *r< 4J c cQ CO cO CO CO A co Q OT cn CO CO CO CO g tf-l s S S S S S ;4 4J A 1 A 1 A 1 A 1 CO 1 0 cn m cn V Q ”0 CM Td VO Td VO -cd VO Td T) c p (V CM 0) 1— (U rH (1) rH 0) 1— Cd *iH 1 <1- •Cd 1 tj V t5 V Td V T3 V Td 1 4J o o o o o o 4J M CJ 1— o 1— Cd »— Cd *— o Cd > C wrti C c c c c M c 4J 0) (U 0) 0) 01 Cd 4J cM > > > > C Q VO M VO M VO M VO M VO '— VO 0 M • • • • Z • • /--S H 5 H 5 H 5 H 5 H H Q A A •_! iw Mh X 4H -5 O CM m m •u fO CO cn m CO CO W) Cw CO CO 1 Mj- 1 1 1 Nf 1 <)• 1 O •iH 1 o 1 O 1 O 1 o 1 o t c o c •iH O 1-1 • cp • • • >w^ 0) Cd T3 Td t C • c • • • • • t 1 •iH 128