NBSIR 88-3728

CGM Registration for CALS

Requirements

A Technical Study Completed for the

Computer-aided Acquisition and

Logistic Support (CALS) Program

Fiscal Year 1987

Volume 3 of 4

Sharon J. Kemmerer, Editor

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Institute for Computer Sciences and Technology

Information Systems Engineering Division

Gaithersburg, MD 20899

• U56

#88-3728

1988

U-2 .
I
NBSIR 88-3728

CGM REGISTRATION FOR CALS

REQUIREMENTS

A TECHNICAL STUDY COMPLETED FOR THE

COMPUTER-AIDED ACQUISITION AND

LOGISTIC SUPPORT (CALS) PROGRAM

FISCAL YEAR 1987

VOLUME 3 OF 4

Research Information Center

ISalionai bureau of Standards

Gaithersburg, Maryland 20899

AJ/366

Ci^loo

, UiSU

/f n

Sharon J. Kemmerer, Editor

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Institute for Computer Sciences and Technology

Information Systems Engineering Division

Gaithersburg, MD 20899

March 1988

U.S. DEPARTMENT OF COMMERCE, C. William Verity, Secretary

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director
^lijn r4'fUt>: '^T» ykifeV.S iiS ^

‘ ‘<1’

‘ ;rTu Ifp ' ,.vi^C2a^ - '••"• '

. ^u-: .r'

t ii» j^r

'

^ .' ••-

. ,?* 5K

. V*,'. ' bit i

s' *-'-..,^': :A)t' '

'». . jL’ '

. -I /• * *‘'

' vvO

. . ftf\ i ;" >-‘!- j _j

^

'. .•.»•(,5#'. ^vi»*Ov»^i

iJ. «-M<lll'^

^<?f' .A-:<^rfis>,r’^-^ v,*'

'

'

,3 "vtf* m: ^<Q9i

:f.- • w- V,-

* ‘j’ -- '. ‘-*<1

*

‘ ->v*

i

‘'Cl* ^ • V .'*^t _

, -^V V'V-

‘

'* .“^"i ,--0 V*. ' .• V . • ^ i. • wJaiAA

Si f*fi” • - - . *»

.'5>1' -
EXECUTIVE SUMMARY

The overall objective of the Department of Defense Computer-aided

Acquisition & Logistic Support (CALS) Program is to integrate the

design, manufacturing, and logistic functions through the

efficient application of computer technology. CALS is a program

to apply existing and emerging communications and computer-aided

technologies in DoD and industry to:

o Integrate and improve design, manufacturing, and

logistic functions; thereby bridging existing "islands

of automation.”

o Actively influence the design process to produce weapon

systems that are more reliable and easier to support

and maintain.

o Shift from current paper-intensive weapon support

processes to a highly automated mode of operation,

based on a unified DoD interface with industry for

exchange of logistic technical information in digital

form.

The CALS program was established by the Deputy Secretary of

Defense in September 1985 to implement the recommendations of a

Joint Industry/DoD Task Force. Management is provided by a DoD

Steering Group, an OSD CALS Policy Office, and their counterparts

in each Military Department and the Defense Logistics Agency.

The CALS Policy Office has obtained the support of the National

Bureau of Standards in the selection and implementation of CALS

standards. An Industry Steering Group has also been established

to focus the work of key industrial associations and the defense

contractor community in CALS implementation.

The Bureau has been funded since Spring 1986 to recommend a suite

of industry standards for system integration and digital data

transfer, and to accelerate their implementation. NBS activities

during 1986 were primarily aimed at:

o familiarizing NBS technical staff with key DoD logistic

functions and CALS demonstration projects,

o briefing DoD personnel, contractors, and other

interested parties on Federal, national, and

international standardization efforts that are expected

to support CALS objectives,

o identifying a preliminary set of standards required for

data interchange in support of CALS, and

o developing reports on the four broad categories of

standards required to support the interchange of CALS

digitized technical information: (1) product definition

data, (2) graphics, (3) text, and (4) data management.

As a result of these efforts, NBS made a preliminary

identification of several high-priority standards implementations

i
needed for CALS data interchange and access.^ Building on

]cnowledge and experience gained during FY86, NBS focused on the

following activities in FY87: developing a CALS Framework,

Development Plan and Core Requirements Package; providing

technical support for standards development and implementation;

and conducting workshops and meetings to promote dialogue with

the Services, the Defense Logistics Agency, and industry.

A major FY87 thrust was the completion of initial documentation

of the high-priority standards required in the CALS environment.

Some of these standards (e.g., SGML, IGES) required tailoring or

enhancement. Other standards required a "push” (e.g., CGEM) for

their development in a timely fashion. These four volumes are a

collection of the final reports presented to the CALS Policy

Office. 2 The collection is divided as follows;

VOLUME 1:

Text

Evaluation of Text Interchange Methods

Plan for Conformance Testing for DoD Implementation of SGML

Guidelines for the Development of Tags for SGML

The NBS FIPS - SGML Validation Suite

The NBS FIPS - SGML Reference Parser

Using SGML - Application Guidelines

ODA/ODIF Implementation Agreement a Document Application

Profile

Data Management

CALS Report on Data Management Standards

Supporting Logistic Support Analysis (LSA) Using the

Information Resource Dictionary System (IRDS)

Media

ICST Recommendations on Optical Disks and Interface

Requirements for Planned EDMICS Procurement, Final

Report

Kemmerer, S., Editor, "Final NBS Report for CALS,

FY86,” U.S. Department of Commerce, National Bureau of

Standards, NBSIR 87-3566, May 1987.

The publishing of this collection of reports does not

imply the CALS Policy Office has endorsed the

conclusions and recommendations presented.

ii
Raster Compression

Report on Raster Graphics

Tiled Raster Interchange Format, TRIF Version 1.0, Rev. 1.2

Conformance Testing

NBS Plan for Validation (Conformance Testing) of Computer

Products in Support of the CALS Program

VOLCFME 2:

Graphics

Raster-to-Vector Conversion: A State-of-the-Art Assessment

Development of CGM Validation Routines

CALS Application Profile for CGM

CALS Requirements Reflected in the Extended CGM (CGEM)

Standards Effort

A Reference Implementation for CGM, Functional Requirements

and Conceptual Design

IGES to CGM Translator Design Specification

VOLUME 3:

Graphics

CGM Registration For CALS Requirements

VOLUME 4:

Product Data

Guidelines for Testing IGES Translators

Guidelines for IGES Application Subsets

iii
The following are additional deliverables completed by NBS during

FY87 but under separate cover. They are available through the

CALS Policy Office.

CALS Core Requirements, Phase I.O

CALS Framework*

CALS Program Integration of Logistic Support Analysis and

Reliability and Maintainability Data Deliverables

CALS Current State of Digital Technology (Phase I.O)

CALS Workshop Proceedings:

Graphics Data Interface for Engineering Design and Technical

Publication Systems (January 13/14)

Introduction to the Core Requirements Package (April 23)

MILSTD-1840A, Automated Interchange of Technical Information

MILSPEC-D-28000 , Digital Representation for Communication of

Product Data: Application Subsets

MILSPEC-M-28001, Manuals, Technical: Markup Requirements and

Generic Style Specification for Electronic Printed Output

and Exchange

iv
CONTRIBUTIONS

NBS would like to acknowledge the major technical contributors to

this volume. In alphabetical order they are:

Daniel Benigni

David Jefferson

Sharon Kemmerer

Mark Skall
vW'

p'.ijB r bJuow '

'

''

' nl .i^r^lov eirff

u

~ij' 4»-V '’'** Up fy f.

4 m

fc##’ ccni^XiHt^ t-y *o,r

irvAi)^-'Si^ M. ' jC-i

• jtf o at V iia

SBirts^ >' ‘''''1®”'^^

I.

' -^ If

,

hr li

- 4' <*'^'*ntdiafrt&ij»gEi^t^ m*it

OX't ^i5<f

. •'

- *1

-V .'#^.'TMBf ^^tne»rirw| t "*s*‘ To6i*r.ic#l

13/14) V » %r*/Ur»i'iftei^t# 9m*,^miit^ 23 )' ir-*-

for oC J* ; »•. loi% iS^4kMt« '*^

.

,

., l%rhr«.c«:.f Haxltup »' 1>4 ^ <?


FINAL REPORT

CALS SOW TASK 2.2.22.1

COM REGISTRATION FOR

CALS REQUIREMENTS
TABLE OF CONTENTS

Page

L PURPOSE 1 n. BACKGROUND 1 1.0 Overview of Computer Graphics Standards 1 1.1 Output Primitives 1 1.2 Ou^ut Primitive Attributes 2

2.0 Registration of Graphical Items 4

2.1 Registration in the CGM Standard 4

2.2 Why Registration for the CGM Alone is Insufficient 6

2.3 The Required Approach for CALS Registration 8

3.0 Applicable Standards 9

4.0 Reference Model 12

in. DISCUSSION 13

1 .0 Technical and Administrative Publishing 1

3

1.1 Introduction 13

1.2 Required Capabilities CGM Must Be Extended to Meet 13

1.2.1 Lines 14

1.2. 1.1 Setiinecap 14

1.2. 1.2 Setlinejoin 15

1.2. 1.3 Setmiterlimit 15

1.2. 1.4 Setdash 16

1.2. 1.5 Closepath 17

1.2.2 Symbols 17

1.2.3 Curves 17

1.2.4 Text 18

1.2.4. 1 Objectives and Functional Definitions 18

1. 2.4.2 Font Referencing 22

1. 2.4.3 Character Positioning 23

1. 2.4.4 Image Presentation 24

1.2.5 Images 25

1.2.6 Definition and Instantiation of Objects 25

1.2.6. 1 PostScript Procedures 26

1.2.6.2 Interpress Symbols 26

2.0 Technical Drawings and Rxxiuct Data 27

2.1 Introduction 27

2.2 IGES Entities 28

2.3 Required Capabilities 29

2.3.1 Lines 29

2.3.2 Symbols 34

2.3.3 Curves 39

2.3.4 Hatch Styles 39

2.3.5 Text 41

2.3.5. 1 Y14.2 Lettering Requirements 41

2.3.5.2 Text in IGES 43

2.3.6 Images 44

ii
TABLE OF CONTENTS (Continued)

Page

IV. CONCLUSIONS 45

1.0 Introduction 45

2.0 Lines 45

3.0 Symbols 46

4.0 Curves 46

5.0 Hatch Styles 46

6.0 Text 46

7.0 Images 47

8.0 Naming and External References 47

V. AREAS REQUIRING FURTHER INVESTIGATION 48

1.0 Curves 48

2.0 Text 49

3.0 Images 49

4.0 Specification of Data Record Contents 49

5.0 Support for Named Items and S3nnbol Libraries 50

6.0 Def&ition of Registration Requirements 50

VL RECOMMENDATIONS 51

1.0 Registration Proposals List 51

2.0 Prepared Registration Proposals 52

Vn. REFERENCES 171

VnL APPENDICES 173

Appendix A Extracts firom Typical DoD Standards 173

Appendix B PostScript and Interpress Capabilities 189

Appendix C IGES Entities and Capabilities 223

Appendix D CGM Extracts 283

FIGURES AND TABLES

Table 1 Output Primitive Attributes

Page

3

Figure 1 Linecap and Linejoin Capabilities 15

Figure 2 Setmiterlimit Capabilities 16

Figure 3 Setdash Capabilities 16

Figure 4 Qosepath Usage 17

Figure 5 ISO Font Architecture - Application Environment 19

Figure 6 A Lower-level Look at the Application Environment 20

Figxire 7 Line Styles and Widths 30

Figure 8 Line in Engineering Drawings 31

Figure 9 Arrowhead Styles 33

Figure 10 Basic Symbol Pattern 36

Figure 11 Examples of Symbols 36

Figure 12 Symbol Orientation 37

Figure 13 A Typical Engineering Drawing 38

Figure 14 Some Representative Hatch Styles 40

Figure 15 Vertical Lettering 41

Figure 16 Inclined Lettering 42

Figure 17 Microform Lettering 42

iii
mbxjbtnkid (fi

jonU OS

zlctlanA Clt

»vtiD

•51^ da^iH (te

ix3)T d^

owjrrjpui a#^

•

' - i’' sS »3J|fiIDl C^C

..I '*t '*‘- \ia V' 'V*®'?"' •’* s^'VIilpA- '•Oft,

.#,7 :=,.':4M: 'j^' lr»' '’*Vxi

tfi ItJ

fa»"i

%’;• J'-'

*iP^':c ,.• lid

siai "« "#**** ^'*

-; rcJ . ry brcp^ a-kC ?K>toftb9CiE,

j

V j|| yi/ Kifr 3C7C^ ;/jfrwiVf 'id^ no<^i2

SBRs -vir >».I ndtr^'f25fi >0 Wo

CX‘M - •’ . ^^ * . • -"^A i>

o^^OlTAOymv^MOOafe jv

: » >Ujroi|ij ^ fscrtrrjttjail Cf I

.^=.4ii JM , ^ ?^'>K3wa’m jay

^ar:>ias<j«5 *^A iiFf

Jiswhflufijj Qo4! if‘viq*<T frwrlt idCHrpjiS A Aibr-O^A

^^ikbdiyiitO,i^\rtaiJm 8 riba’j^jA

Hysrail MCD G ;dbc^4^

M'-

4 i - i® J '1C! "^^^e::;,iaAT v:Guyan

W* ^vaimhfl toqniO

^;5- flio43wU±<u qr^U

jdi«54D d«flto2

' ^-ja^bsTA IJIO^ 021

.^3 iWOi^qA ^rSI iOoJ lov*|-wrtxi A

jr,.ffl^5> ajtfiaiW to »t\jJ8 9t^

I- m ^y-iiurmiQ a?ibae«i|ii3 m saU

. ;' ‘ '1: V|]5^t' ito)v2 toS

'i#44'‘AT^fA:Kff^, " ,:toawi3C3

I 26 ^ okkV

I 26 " Sr wxrjH

£2/ 4:

d ««S<H ; tM v

r*o||B, . ^i9 3%q^B

.•*di*' ‘tih iHi

; toaW2«iOktorc2 /’4

« ItruvinG siitofi%n3 A

pp 8<1X>2 e r dl
I. PURPOSE

The purpose is to register extensions to the Computer Graphics Metafile (CGM) standard through

the American National Standards Institute (ANSI) and International Standards Organization (ISO)

processes to meet CALS requirements, to ensure that ail geometric objects which are displayed

graphically in CALS can be represented by the CGM. (Task 2. 22. 2. 2) n. BACKGROUND

The extensions necessary to allow the CGM to properly suppon CALS requirements for data

interchange in the areas of Technical Publishing, Administrative Publishing, and Technical

Drawings were derived fom applicable standards, commercial product descriptions, and CALS

program documents. The simplest extensions are described as registered linetypes, hatchstyles,

and markertypes. Such extensions add no additional "functionality" to the CGM. More complex

extensions are described in the form of the Graphical Drawing Primitives (GDPs) and Escapes

necessary for their implementation. NBSACST concludes that the general framework of the CGM

is adequate to support CALS requirements, but that a large number of extensions-some involving

significant new concepts—are required. The effort expended under this year's SOW, although very

comprehensive, addresses only a small portion of the CGM extensions which should be registered

for CALS use. This report does indicate what should be done in follow up work. This will be

discussed in Section V of the repon.

1.0 Overview of Computer Graphics Standards

For completeness and to allow comparison with CALS requirements, the output facilities of the

family of ISO/ANSI computer graphics standards—induing the CGM—are described in this

paragraph. This material is drawn from [1],

1.1 Output Primitives

Computer ^phics standards provide six output primitives: one line-primitive, one point-primitive, one text-primitive, two raster-primitives and one general purpose primitive serving as an entry point

for specific workstation capabilities and as a mechanism for extending the standards in a "standard

way."

POLYLINE - generates a set of straight lines connecting a given point sequence.

POLYMARKER - generates symbols of some type centered at given positions. The symbols are called markers; these are glyphs (symbolic characters) with specified appearances which are used to identify a set of locations.

TEXT - generates a character string at a given position.

FILL AREA - generates a polygon which may be hollow or filled with a uniform color, a pattern, or a hatch style.

CELL ARRAY - generates an array of rectangular cells with individual colors. This is a generalization of an array of pixels on a raster device. However, the cells of this primitive need not map one-to-one with the pixels defined by the display hardware.

GENERALIZED DRAWING PRIMITIVE (GDP) - addresses special geometrical output

capabilities such as the drawing of spline curves, circular arcs, and elliptic arcs. The objects are characterized by an identifier, a set of points and additional data. All transformations are applied to the points but the interpretation is left to the workstation.

1
1.2 Output Primitive Attributes

Table 1 gives, for every type of primitive, the set of attributes that control their appearance. The

attributes describe the following aspects of output primitives.

Pick identifier - A number assigned to individual output primitives within a segment and

returned by the pick device. The same pick identifier can be assigned to different output primitives.

These no not apply to the CGM.

Linetype - Linetypes are used to distinguish different styles of lines. A line may be, for example,

solid, dashed, or dashed-dotted.

Linewidth scale factor - The actual width of a line is given by a normal linewidth multiplied by

the linewidth scale factor.

Color - The color is specified by the red-, green-, and blue-intensities defining a particular color

(RGB-values).

Marker type - The marker type is a number specifying the particular glyph used for identification

of the polymarker positions.

Marker size scale factor - The actual marker size of a line is given by a nominal marker size

multiplied by the marker size scale factor.

Text font - The text font is a number selecting one representation for the text string characters out

of the possibilities present on a workstation.

Text precision - An attribute describing the fidelity with which character position, character size,

character orientation, and character font of text output match those requested by an application. In order of increasing fidelity, the precisions are string, character, and stroke.

Character height - The vertical extent of a character.

Character up vector - The "UP” -direction of a character.

Character expansion factor - The deviation of the width/height-ratio of a character from the

ratio defined by the text font designer.

Text path - The writing direction of the character sequence. The normal path is "right," i.e., the

text you are reading is written from left to right. The standards allow the text path values; left, up,

and down also.

Character spacing - Space to be inserted between adjacent characters of a text string in addition

to the space defined by the font designer.

Character alignment - A text attribute describing how the text string is positioned relative to the

reference point of the text primitive (e.g., left aligned, centered).

Interior style - The interior style used to determine in what style an area should be filled. It has one of the values: hollow, solid, pattern, or hatch.

Pattern size - The pattern size specifies the size of the basic pattern rectangle.

2
Pattern reference point - The pattern reference point specifies the origin of the basic pattern

rectangle. The lower left comer of the rectangle is placed at the reference point. Then the pattern is repeated in both directions until the whole area is filledPattern array - A pattern is defined by an array of rectangular cells, each cell having a color

assigned to it. These values are used to assign colors to the basic pattern rectangle and to ail replications of it. Hatch style - Hatching is specified by a number selecting one hatch style.

Primitive Attributes

POLYLINE PICK IDENTIFIER LINETYPE

LINEWIDTH SCALE FACTOR COLOR

POLYMARKER PICK IDENTIFIER MARKER TYPE

MARKER SIZE SCALE FACTOR COLOR

TEXT PICK IDENTIFIER TEXT FONT

CHARACTER HEIGHT TEXT PRECISION

CHARACTER UP VECTOR COLOR

CHARACTER EXPANSION FACTOR TEXT ALIGNMENT

TEXT PATH

CHARACTER SPACING

FILL AREA PICK IDENTIFIER INTERIOR STYLE

PATTERN SIZE HATCH STYLE

PATTERN REFERENCE POINT COLOR

PATTERN ARRAY

CELL ARRAY PICK IDENTIFIER COLOR

GENERALIZED PICK IDENTIHER

DRAWING

PRIMITIVE

dependent on the type of GDP

Table 1. Output Primitive Attributes

3
2.0 Registration of Graphical Items

The purpose of this paragraph is to define the framework through which graphics standards are extended by the procedure called registration, (Registration procedures do not assign values

which are defined as being workstation- or implementation-dependent.) Registration applies to the

registration of individual items within the following classes of graphical items as reserved for

registration in computer graphics standards:

a) Generalized drawing primitive (GDP) function definitions;

b) Graphical escape function definitions;

c) Linetypes;

d) Markertypes;

e) Hatchstyles;

f) Textfont appearance;

g) Prompt and echo type definitions (for graphical interaction—does not apply to the CGM);

h) Error messages.

Linetype, markertypc, and hatchstyle registration adds additional types and styles to supplement

those defined in the standards. Their definition is straightforward. Textfont appearance registers the

identifiers through which text fonts are accessed by graphics standards. GDP and Escape

registration are the mechanisms through which additional functionality is added to a graphics

standard. For example, curves can be added through GDP registration and additional line attributes

- such as endcaps—can be added through Escape registration. Since this report addresses only

CGM extensions, Prompt and Echo Type de^ition are not considered. Error messages are registered as necessary to support registered GDPs and Escapes.

2.1 Registration in the CGM Standard

The CGM standard (ANSI X3, 122-1986 or FIPS 128) describes registration in this way:

For certain elements, the CGM defines value of range of parameters as being reserved for

registration. The meanings of these values will be defined using the established procedures

of the ISO International Registration Authority for Graphical Items. These procedures do not

apply to values and value ranges defined as being reserved for implementation-dependent or

private use; these values and ranges are not standardized.

Applications therefore, shall not use parameter values in the reserved ranges for

implementation-dependent or private use. Those elements that will be affected by registration

of graphical items are:

a) LINE TYPE;

b) MARKER TYPE;

c) HATCH STYLE;

d) EDGE TYPE;

e) FONT LIST (allows the selection of named fonts via a font index);

f) GENERALIZED DRAWING PRIMITIVE;

g) ESCAPE.

4
Registration of character sets for use with the CHARACTER SET LIST element is according to the procedures established by ISO 2375, Character Set Registration.

The COM includes the following "built-in" values for items subject to registration:

1) LINE T\TE:

1. solid

2. dash

3. dot

4. dash-dot

5. dash-dot-dot

2) MARKER TYPE:

1. dot (.) 2. plus (+)

3. asterisk (*)

4. circle (o)

5. cross (x)

3) HATCH TYPE (called HATCH STYLE in the above extraa from the COM standard):

1. horizontal equally spaced parallel lines

2. vertical equally spaced pai^lel lines

3. positive slope equally spaced parallel lines

4. negative slope equally spaced parallel lines

5. horizontaWertic^ crosshatch

6. positive slope/negative slope crosshatch

4) EDGE TYPE (the built-in ones correspond directly to line types):

1. solid

2. dash

3. dot

4. dash-dot

5. dash-dot-dot

5) Text Fonts: none

6) GENERALIZED DRAWING PRIMTITVE:

none

7) ESCAPE:

none

It may be necessary to extend the CGM by adding functions that cannot be accommodated in the

restricted format of registered items. These extensions can be done by adding external elements.

The CGM standard describes GDPs, Escapes and External elements in this way:

Generalized drawing primitives

The GENERALIZED DRAWING PRIMITIVE (GDP) is a graphical primitive element that

may be used to access device (or implementation) specific graphical primitives that are not

accessed by the standardized elements.

5
Escape elements

ESCAPE elements describe device- or system-dependent data in the CGM. ESCAPES may

be included in the metafile at the discretion of the user, but direct effects and side effects of

the use of nonstandardized elements are beyond the scope of this standard. This standard

imposes no constraints on the functional intent or content of data passed by the ESCAPE

mechanisoL

External elements

External elements communicate information not directly related to the generation of a graphical image. They may appear anywhere in the CGM

The APPLICATION DATA element allows applications to store and access private data. This

element is not a graphical element and its interpretation will have no effect on any picture

produced by an interpreter.

For specification of non-standardized graphical effects, the ESCAPE and GENERALIZED

DRAWING PRIMmVE elements are provided. These elements may have an effect on the

picture produced by an interpreter.

2.2 Why Registration for the CGM Alone is Insufficient

The CGM standard (deliberately) does not standardize the actions of metafile generators or

interpreters. However, since metafiles are to be used in a fixed environment—such as the DoD

CALS program—to transfer picture data, then the action of both metafile generators and interpreters

must be precisely defined. Tliis is done by the definition of application profiles. Such a profile

for CALS is being developed by NBS/ICST.

Also, graphical items must be registered for use not only by the CGM but by all (applicable)

standards. Requirements for simple extensions such as linetypes, markertypes, and hatchstyles are similar in all graphics standards. However, the application program interface standards have more

rigorous requirements for registered Escape and GDP elements. This is illustrated by the

following extracts from the Graphical Kernel System (GKS) standard (FIPS 120, ISO

7942-1985), which should be contrasted to those given in Section 2.1 from the CGM:

Escape

Parameters: ^

In specific escape function identification In escape input data record

Out escape output data record

Effect: The specified non-standard specific escape function is invoked. The

form of the escape data record and which of them are used may vary for different

functions. Also the GKS states allowing the invocation of a specific escape function may be

restricted. The following rules govern the definition of a new specific escape function:

a) the GKS design concept (see Section 0 - introduction)

b) the GKS state lists are not altered.

c) the function does not generate geometrical output

d) any side effects are well documented.

6
Specific escape functions may apply to more than one workstation, for example, all open

workstations or all active workstations. The escape input data record can include a workstation identifier where this is required.

Note: Examples of specific escape functions anticipated at present are:

a) support of raster devices allowing the display of more than one frame buffer,

b) use of raster or hardware to manipulate data previously output by cell array. Where the specific escape function identification is bound to an integer in a programming

language specific escape function identifications greater than 0 are received for

registration or future standardization and specific escape function identifications less

than 0 are implementation dependent

Specific escape function identifications are registered in the ISO International Register of

Graphical Items, which is maintained by the Registration Authority. When a specific

escape function has been approved by the ISO Working Group on Computer Graphics,

the specific escape function identification will be assigned to the Registration Authority.

Generalized drawing primitive (GDP)

Parameters:

In number of points

In points

In GDP identifier In GDP data record

Effect: A Generalized Drawing Primitive (GDP) of the type indicated by the GDP identifier is generated on the basis of the given points and the GDP data record. The cunent values of the

entities in the GKS state list ... for the set of polyline, polymarker, text or fill area

attributes are bound to the primitive. These attributes are listed in ... When the GDP

generates output at the workstation, zero or more of the sets of attributes are used. These are the sets of attributes most appropriate for the specified GDP function and are selected for the

GDP as pan of the definition of the GDP. (They are defined in the workstation description

table).

Note: The parameters are transmitted to the workstation and interpreted in a workstation

dependent way that special capabilities of the workstation can be addressed. Even if errors occur, the GDP is display^ on all active workstations capable of doing so. For

example, some of the parameters anticipated at present are:

a) circle points given are centre, peripheral point,

b) circular arc points are centre, start point, end point to be connected anticlockwise in

world coordinates,

c) elipse points given are 2 focal points, peripheral point,

d) elliptic arc points given are 2 focal points, start point, end point to be connected

anticlockwise is world coordinates,

e) interpolating curve (for example, spline) points given are interpolated.

The recommended set of attributes to use for the above GDP examples would be the polyline

attributes.

7
It should be emphasized that the points, specified as parameters, are transformed by GKS

after the interpolation of the points (as defining say, a spline curve or circle) is performed

by the active workstation. For example, a GDP, which defines a circle, would appear as an

ellipse when the transformation has dfferential scaling for the two axes. Each specific GDP

definition defines how the transformation is applied to both the points and the shape of the

GDP. Though the points cannot be clipped, the resulting output of the GDP is clipped

against the clipping rectangle, if the "clipping indicator" entry is the GKS state list is CLIP,

and the workstation window. If a specific GDP is available on a workstation but is unable to be generated because the current transformations or clipping rectangle are such that the

preceding conditions would be violated, an error occurs. The GDP data record attribute list may contain additional data for each point (for example,

vertex order for splines) which remain untransformed. These have to be defined for a specific GDP. In defining a new GDP, the GKS design concepts (see Section 0) are not

violated. The set of generalized drawing primitives implemented on a workstation may be

empty.

Where the GDP identifier is bound to an integer in a programming language, GDP identifiers

greater than 0 are reserved for registration or future standardization and GDP identifiers less

than 0 are implementation dependent

GDP identifiers are registered in the ISO Register of Graphical Items, which is maintained by

the Registration Authority. When a GDP has been approved by the ISO Working Group on Computer Graphics, the GDP will be assigned by the Registration Authority.

2.3 The Required Approach for CALS Registration

Based on the above discussion, when writing actual registration proposals for graphical items

required for CALS, the following must be done:

1) define how the item is implemented in all applicable graphics standards;

2) develop all necessary language bindings;

3) precisely define the semantics of the item.

Registration proposals developed contain a semantic specification that is complete and precise

enough to define the required actions by metafile generators and interpreters. Portions of these

descriptions may prove too explicit to be approved by the required ANSI and ISO standards

committees. (These committees are accustomed to specifying items as loosely as possible to allow

as many implementations as possible to conform.) In this case, some material may need to be

moved from the registration proposal to the CALS application profile. In addition, some extensions

may only be achievable through the use of the CGM External Data element

8
3.0 Applicable Standards

The standards listed in this section were identified as being applicable to technical drawings and

automated (technical and administrative) publishing. Drawing and drafting standards were included

in the list since they are the best source of information on the "graphical presentation" requirements

for engineering drawings. Product data standards were included since they are often (mistakenly)

used for picture transfer purposes and, consequently, contain features relating to the "presentation"

requirements for such data. The FIPS, ANSI and ISO standards in the areas of graphics standards

and product data definition are not repeated here, since they are adequately documented in last year's final report.

Technical publishing

MIL-M-38784B - Manuals, Technical: General Style and Format Requirements

Description of drawing forms

ANSI Y14.1 - Drawing Sheet Size and Format (1980)

ANSI Y14.2M - Line Conventions and Lettering (1979)

Lists: purpose, classification, and preparation

ANSI Y14.1-1980 - Drawing, Sheet Size and Format

ANSI Y14.34M-1982 - Parts Lists, Date Lists and Index Lists

ANSI Y32. 16 - Reference Designations for Electrical and Electronic Parts and Equipment

DoD-D- lOOOB Drawings, Engineering and Associated Lists

Printed board drafting practice

MIL-STD-100

MIL-STD-275

MIL-STD-429

MIL-STD-1494

Engineering Drawing Practices

Printed Wiring for Electronic Equipment

Printed-Wiring and Printed-Circuit Terms and Definitions

Multilayer Printed Wiring Boards for Electronic Equipment

ANSI Y14.5 - Dimensioning and Tolerancing

ANSI Y32. 16 - Reference Designations for Electrical and Electronic Parts and Equipment

IPC-T-50

IPC-D-310

IPC-D-350

IPC-D-390

IPC-CM-770

Terms and Definitions

Suggested Guidelines for Artwork Generation and Measurement Techniques

for ^nted Circuits

Printed Board Description in Digital Form

Guidelines for Design Layout and Artwork Generation on Computer

Automated Equipment for Printed Wiring

Component Mounting Guidelines

MIL-D-8510

MIL-I-46058

MIL-P-55110

Drawings, Undimensioned, Reproducible, Photographies and Contact:

Preparation of

Insulating Compound, Electrical for Coating Printed Circuit Assemblies

Printed Wire Boards

9
Line conventions and lettering; signs and symbols

ANSI Y14.2M-1979 - Line Conventions and Lettering

ANSIY10.3 - Quantities Used in Mechanics of Solids: Letter Symbols for

ANSIY10.20 - Mathematic Signs and Symbols for Used in Physical Sciences and

Technology (include supplement ANSI Y10.20a 1975)

Drawing preparation for microfilming

ANSIY14.1 - Drawing Sheet Size and Format

ANSI Y14.2M - Line Conventions and Lettering

NMA - MS 100-1971 Glossary of Micrographics Terms

MIL-M-9868D Microfilming of Engineering Documents

Other drawing practices

ANSI Y14.7.1

ANSI Y14.7.2

ANSIY14.17

ANSIY14.13M

Gear Drawing Standards—Part 1 for Spur, Helical, Double, and Rack

Gear and Spline Drawing Standards—Part 2, Bevel and Hypoid Gears

Fluid Power Diagrams

Engineering Drawing and Related Documentation Practices—Mechanical

Springs

Dimensioning and tolerancing (general dimensions)

ANSI Y14.3

ANSI Y14.5M

ANSI Y14.6

Multi and Sectional View Drawings

Dimensioning and Tolerancing

Screw Thread Representation, Engineering Drawing and Related

Documentation Practice

Reference designations for electrical parts and equipment; electrical diagrams

ANSI Y32.16

ANSI Y32.2

ANSI Y14.15

ANSI Y14.15b

1975 Reference Designations for Electrical and Electronics Parts and

Equipment

1975 Graphic Symbols for Electronic Diagrams

Electrical and Electronics Diagrams (Includes supplements ANSI Y14.15a

and Y14.15b 1973)

Electrical and Electronics Diagrams (supplement to ANSI Y14.15 1966)

Note: These standards have been accepted for use by the Department of Defense.

MIL-STD-15-2 - Electrical Wiring Equipment Symbols for Ships' Plans Pan 2

Surface texture

ANSI-B46. 1-1978 - Surface Texture

ANSI-Y14.36-1978 - Surface Texture Symbols

10
Abbreviations • for use on drawings and technical documentation

ANSI Y1 . 1 - Abbreviations

MIL-STD 12 - Abbreviations for Use on Drawings, Specifications, Standards, and

Technical Documents

Graphic symbols for metal joining and nondestructive testing symbols (welding)

AWS A2.4-76 - Symbols for Welding and Nondestructive Testing.

MIL-STD-25B - Ship Structural Symbols for Use on Ship Drawings

Specification practices

MIL-STD-490

MIL-S-83490

DOD-STD-100

MIL-STD-961

MIL-STD-1679

DSM4120.3M

Specification Practices

Specifications, Types and Forms

Engineering Drawing Practices

Outline of Forms and Instructions for the Presentation of Specification

Weapon Systems Development (Navy)

Standardization Policies Procedures and Instructions

ISI metric practice

ASTM E380 - Standard for Metric Practices

DOD-STD-1476 - Metric System, Application in New Design

Production identification

MIL-STD-130

MIL-P-15024

MIL-19834

MIL-P-83497

Identification Marking of US Military Property

Plates, Tags, and Bands for Identification of ^uipment

Plates, Identification or Instruction, Metal Foil, Adhesive Backed, General

Specifications for

Procedures for Preparation of Programmed Tapes and Cards

Communication of product data

ANSI Y 14.26.3 - Dictionary of Terms for Computer-aided Preparation of Product Definition

Date (including Engineering Drawings)

ANSI Y14.26 - Engineering Drawing and Related Documentation Practices—Digital

Representation for Communication of Product Definition Data

DoD/CALS specific standards

Draft MIL-STD- 1840A - Automated Interchange of Technical Information

DOD-D-(IGES) - Digital Representation for Communication of Product Data: Application

Subsets

11
4.0 Reference Model

For purposes of this task, a very simple reference model has been adopted to define how the CGM

is used in technical drawing production and publishing applications.

For the purposes of this work, it is assumed that the CGM will be used in the following manner in

CALS:

1) CGM pictures will be used to transfer engineering drawings.

2) CGM pictures will be used to transfer pages of technical publications which contain

both text and graphics; the extensions being defined herein will allow the CGM alone to be

used for transferring the content of document pages—text, geometric graphics, and image

(raster) graphics. The CGM may also be used to transfer pictures which are then embedded in

documents by some process outside the scope of this study.

No assumptions were made in the following areas:

1) The manner in which graphical metafiles are transferred.

2) The embedding of CGM content in documents defined in other standards ( for example,

ODA and SGML).

3) The manner in which descriptions of externally defined items are made available to a CGM

interpreter.

4) Transfer of "processible” product definition data or "processible-form” office documents.

(It is assumed IGES and/or ODA/ODIF are used in these cases).

12
III. DISCUSSION

1.0 Technical and Administrative Publishing

1.1 Introduction

It is widely recognized that computer graphics standards, CGM in particular, will need to be

extended to properly support publishing in the CALS environment Such extensions will be initially

developed in the form of GDPs and Escapes and the "folded into" the standards during their next

revision cycles.

The following liaison statement (between the two relevant standards bodies) from ASC X3H3

(Computer Graphics) to ASC X3V1 (Office Systems) summarizes some of these changes:

Liaison Statement to X3V1 TG8 Concerning TPM (Text Presentation Metafile)

User Requirements (X3H3/87-31)

1 . Rapid soft copy display of formatted composite documents.

2. Use of internationally standardized color models in interchange.

3 . Use of standard methods for image compression.

4. General fill boundary specification.

5 Wide lines with joint and end features, and patterns with anchoring.

6. Curves, including conics and Bezier curves.

7. General clip boundary.

X3H3 would like to work with the TPM developers on graphics aspects to achieve two goals:

1. Any functionality in TPM which is close to functionality in GKS or CGM should be

identical.

2. Any graphic functionality required by TPM but not present in CGM should be developed

jointly so that it can be used compatibly by existing and future graphics and office systems

standards.

Subsequent sections describe first the methodology by which extensions in the publishing area were determined, and then the general features that must be added to the CGM. These general

features are given by way of example of current proprietary products.

1.2

Required Capabilities CGM Must Be Extended to Meet

In the absence of standards in this area (the Text Presentation Metafile under development in X3V1

will not be available—even in draft form—until late 1987), the features of the most widely used

commercial products have been used to define the required capabilities. In particular, the PostScript

Page Description Language [5,6] of Adobe Systems has been selected to provide a baseline set of

capabilities. In some cases, features from the Interpress Page Description Language [4] of Xerox

Corporation have been used instead of or in place of those in PostScript.

13
Defining required capabilities in the publishing area is more difficult than for engineering drawing,

since format and presentation are determined more by artistic considerations than slavish adherence

to format standards. MIL-M-38784B contains requirements for high-level formatting and no

"presentation" requirements. Unless noted, the capabilities discussed below have been made into

registration proposals, and can be found in the Recommendations section.

1.2.1 Lines

"Lines" in PostScript are drawn through a two-step process. First, a path is constructed,

corresponding to the line to be drawn. This is done by a sequence of moveto and lineto

operators. (Relative operators, or curve operators can be interspersed. Appendix B provides a list of all PostScript operators, and detailed descriptions of the ones used for graphics.) Next, the

stroke operator paints the path with the current color and line width.

The PostScript language gives complete control over how the stroke operator converts a path into a painted line or curve. TTie setlinewidth operators determine the width of the stroked line. There

are several operators that allow other characteristics of a stroked path to be precisely determined.

Among these are:

1 ) setlinecap determines the appearance of line segment ends;

2) setlinejoin determines the method by which different line segments are joined;

3) setdash determines the pattern for dashed lines.

These operators are described below in detail:

1.2.1.1 Setlinecap

The setlinecap operator takes a number from the stack and uses it as a code determining how

PostScript will end stroke line segments. For example, the program line

1 setlinecap

would cause PostScript to paint all line segments with round ends.

There are three values for the line cap code:

0. Butt caps - The line segment has square ends perpendicular to the path. This is the

PostScript default line cap.

1 . Round caps - The line segment ends with semicircular caps with diameters equal to the

widths of the line.

2. Projecting square caps - These are similar to butt caps, but extend one-half of a line width

beyond the line segment's endpoint (These three styles are illustrated in Figure 1).

14
^tn€jo>o = 0,Mitarjcms

1. '"ccap = 0. Bj” caps

L'ne:Oin = l; Rouncj jc'»v5

L -ecap = 2; Protecting caps

Lineioin = 2;Bevsl«4

Figure 1. Linecap and Linejoin Capabilities

1.2. 1.2 Setlinejoin

When two connected line segments are stroked, PostScript needs to make a decision about what

type of join to use between them. The setlinejoin operator tell PostScript how to join connecting

line segments. This operator is similar to setlinecap, in that it takes a code from the top of the

stack. This code can have values from zero to two, corresponding to the following types of line

0. Mitered join - The edges of the stroke are extended until they meet. This is the default

join. This join is affected by the current miter limit (see below).

1 . Rounded join - The segments are connected by a circular join with a diameter equal to the

line width.

2. Bevel join - The segments are finished with butt end caps and the notch at the larger

angle between the segments is filled with a triangle.

These three styles are illustrated in Figure 1.

1.2. 1.3 Setmiterlimit

Mitered joins can present a problem. If two line segments meet at an extremely small angle, the

mitered join can produce a spike that extends a considerable distance beyond the intersection of the

path segments. To prevent this, the join switches from mitered to beveled when the angle between

line segments becomes too acute. Figure 2 illustrates how the setmiterlimit operators is used to control this effect.

joins:

15
The Tiiter limit is the majtimu"'

ratio ot i/w

10 setmitertimit

3 setmiteriim.it

Figure 2. Setmiterlimit Capabilities

1.2.1.4 Setdash

The current path is normally stroked with a solid line. Other methods of stroking a path are possible, however. The PostScript graphics state includes a dash array and a dash outset, rhat

together describe what pattern of alternating black and white dashes should be used to stroke paths.

This pattern is set by the setdash operator, which takes an array and a number from the stack and

makes them the current dash array and offset. The array contains a set of numbers, such as

[3 5 15]

which represent the lengths of alternating black and white segments should make up a stroked line. The array above would cause all paths to be stroked with a repeating sequence consisting of three

units -of black, five units of no ink, one unit black, five units no ink. This pattern will repeat along

the entire stroked path. This is illustrated in Figure 3.

[3515] 0 setdash

Figure 3. Setdash Capabilities

The second argument passed to setdash is the offset within the dash pattern where the stroke

operator is to start when it prints a line. That is, if we were to set the dash pattern with the line

[6 3] 3 setdash

stroked lines would begin three units into the pattern, or half way through the first long dash.
1.2. 1.5 Closepath

A final necessary capability is provided by the closepath operator. This operator adds a line

segment to the current path connecting the current point to the last point addressed by a moveto

operator. Figure A shows an example of a box containing a notch in one comer since it hasn't been

"closed." After the closepath operator is applied (with mitered joins) the result is "better box" in

Figure 4.

Figure 4. Closepath Usage

1.2.2 Symbols

PostScript provides no explicit modular symbol capabilities. Its program language-like structure however, allows graphical patterns to be defined once and positioned at various points to provide

the necessary capability. This topic is explored further in Paragraph 3.8. 1.2.3 Curves

PostScript provides the following operations to draw curve line segments:

arc - appends a counterclockwise arc of a circle to the current path, possibly preceded by a straight

line segment.

arcn - behaves like arc, but builds its arc segment in a clockwise direction.

arcto - appends an arc of a circle to the current path, preceded by a straight line segment.

curveto - adds a Bezier cubic section to the current path . moveto - starts a new subpath of the current path, sets the current point in the graphics state to the user coordinate without ad^ng any line segments to the current path.

closepath - closes the current subpath by appending a straight line segment connecting the current point to the subpaths's starting point.

rlineto - appends a straight line segment to the current path in the same manner as lineto;

however, the number pair is interpreted as a displacement relative to the current point rather than as an absolute coordinate.

17
rmoveto - starts a new subpath of the current path in the same manner as moveto, however, the

number pair is interpreted as a displacement relative to the current point rather than as an absolute

coordinate.

rcurveto - adds a Bezier cubic section to the current path in the same manner as curveto;

however, the three number pairs are interpreted as displacements relative to the current point rather

than as absolute coordinates.

stroke - paints a line following the current path and using the current color.

strokepath - replaces the current path with one enclosing the shape that would result if the stroke

operator were applied to the current path.

setflat - sets the flamess in the current graphics state to num, which must be a positive number.

Flamess is used to control the accuracy with which curves are rendered on an output device

clip - intersects the inside of the current clipping path with the inside of the current path to produce

a new (smaller) current clipping path.

Additional details are contained in Appendix B which provides a complete description of each

operator mentioned above. [ Registration proposals have been prepared for the curve

capability. Some others have equivalent facilities in the CGM. Setflat, closed

figure and stroke path require further study before generalization and

incorporation in the CGM.]

1.2.4 Text

Rather than draw the required text capabilities from PostScript—which represents only one of

many technologies for defining and rendering text, ISO DP 9541 Font and Character Information

Interchange is used. There is agreement in principle amongst the various standards committees that

the capabilities represented in this draft standard should be adopted by computer graphics

standards.

ISO DP 9541 defines font referencing, positioning, and presentation. Minimal and complete

capabilities are defined in each of these areas as follows:

I.2.4.I. Objectives and Functional Definitions

The objective of the Font and Character Information Interchange Standard is to define a common

font resource architecture which can be used in a variety of development and application

environments, for the purpose of supporting text (characters, symbols, ideograms) generation,

interchange, and presentation. The font resources which are developed to this architecture may be

used by: text and graphic editor, document formatters, utilities, device service programs, resource management programs, and presentation device drivers. Figure E provides a high level look at the

environment in which ISO DP 9541 operates. Figure F decomposes Figure E to provide a lower

level look at the publishing environment.

18
Text Data

>

<

<

A

Text

Data

Document

Editing

Products <

Document

Formatting

Products

AAA

Font Resource Information

1 s ZD and Description

2 = Character Positioning

3 = Character Image

f'ii»urc I. Application Kn\ironmi*nt

Figure 5. ISO Font Architecture - Application Environment

19
Final-form

Document x Data Sets

or Library

Device

Service

Program

or hodule

Device Printer

DS

or Display

A

Device

X : Final-form or Revisable documents may be routed

to other programs* devices* systems* and sites.

XX : Positioning information and shape information may

be down-loaded to a device via a device service

facility or may be resident in the device on a diskette* hard file* cartridge* etc.

l icurc 2. Applicafinn F.nMr«mmcnt (lou lc\d )

Figure 6. A Lower-level Look at the Font Application Environment
Consistency of font resource information is a requirement for softcopy display of documents to be

typeset, and interchange of documents between systems.

The degree of consistency can be significantly improved through the use of a common font resource architecture.

A font resource is defined to be the total collection of information required to characterize and

identify a font to compose blocks of text and to define the images of the characters, for use by an

electronic data processing system. A font resource will contain information that:

1) identifies and describes itself to permit selection by users and application programs.

2) defines the character attributes required by a document formatting process to position the

characters on a presentation surface.

3) defines each character's shape for generation of the character images on the presentation

surface.

Font production is defined to be the process of designing the character images, converting those

images into a digital technology format (bit image, vector drawing orders, outline algorithm, etc.),

defining the various height, width, and escapement values for each individual character, assigning

appropriate descriptive and identifying information (to the characters and the font resource in

general), and creating a font resource that contains all of the required information in a format that can be used by a text processing system.

Text processing system is defined to be the total collection of hardware devices and software

or firmware programs required to generate, modify, display, and/or print text. Those components

(devices and programs) may be contained in a single hardware device that processes only text or may be included within a larger document processing system and/or communication network. Text

processing may be the primary function of the component (text editor) or it may be only an

auxiliary fonction of the component (graphics editor, device service program, resource management

program).

Font storage and access is defined to be the process of storing the font file information on the

appropriate media for use within a text processing system, and the process of accessing that

information by the various components of a text processing system. When a font resource is first generated, all of the required information may be contained in a single font resource file, but that

may not be the format that is most useful within a text processing system

Font referencing is defined to be the process of identifying or characterizing a font. The

referencing task affects editing, formatting and presentation because it is necessary for the user

to specify the desired fonts in the document, for the formatter to identify the fonts and find the

required character positioning information from the appropriate font resource, and for the

presentation process to identify the fonts and find the required character positioning and shape

information from the appropriate font resource. Referencing may include identification of a specific

font resource, or simply provide sufficient descriptive information about the desired font that an

alternative font resource can be found if the specified one is not available to the system which will

format or present the document.

Character positioning is defined to be the process of determining where a given character is to appear on the presentation surface. This function is performed by the document formatting process,

which is a generic name for any process that determines the text, graphic, or image content and

format of a document, including pages and line breaks and how text should flow around graphics

21
or image objects that also appear in the document The document formatting process makes use of

font resource information along with user, system, and document content information. Thus, font resources provide only a portion of the information required for character positioning. Characters

may be positioned absolutely or relatively. That is, the formatting process may specify the precise

location where each individual ch^acter is to be positioned or the formatting process may specify

the content and beginning of a string of characters. In either case, the process must know the image

and escapement extents for each individual character, and other character attributes dealing with

coordinate system, reference point, rotation, kerning, ligatures, etc. Image presentation is defined to be the process of forming the character image on the

presentation surface. This process is actually performed by a hardware device (display or printer),

but may be supponed by a series of software and/or hardware processes which translate the

character image information from its font resource format to the format or control codes required

by the presentation device. Font resources, defined according to this standard, may suppon a variety of shape definition techniques, some public and some private. Some font designs are privately owned and the key to translation of the character shape information is only available

through license agreements. Other font designs are in the public domain and anyone may have

access to the character shape information. In addition, other practical considerations may suggest

the use of other image technologies.

1.2.4.2 Font Referencing

Minimal Referencing

The minimal subset of font referencing supports simple identification of the font resource design

and character content, but does not suppon description of the font resource to a level of detail

required for suppon of document rendering (fidelity level) specification. The subset only includes

font name.

Complete Referencing

The complete subset level of the font referencing supports description of the font resource to a level

that permits selection or approximation of a font resource based on the description provided. The

selected font must be described to a level of detail that accurately identifies the attributes of the font resource that was chosen for document formatting. If it becomes necessary for the presentation

service to substimte another font resource, it must find one that most closely corresponds to both

the user and formatter specified fonts.

The subset includes the following attributes (in addition to those defined for the minimal subset):

Control attributes

body size units

Control attributes

character collection

Format attributes

font size

minimum size

maximum size

Layout attributes

maximum height

X height

cap height

22
ascender height

descender depth

minimum escapement

average escapement

maximum escapement

weighted average escapement

lower case escapement

upper case escapement

digit escapement type

writing mode

Appearance attributes

posture

structure mood

function

character category

font category

typeface name

design classification

escapement class

hairline weight

relative wei^t

absolute weight

relative width

absolute width

relative height

absolute height ^

1.2.4.3 Character Positioning

Minimal Positioning

The minimal subset of character positioning supports character increment fonts, but does not

support proportionally spaced fonts where each character has a defined escapement value.

This subset includes the following attributes:

Control attributes

font name

escapement class

bodysize units

Positioning attributes

average escapement

font size

Complete Positioning

Given the document formatting requirements and text content, the escapement required for each

character must be determined. The formatting process may designate that a character may be

positioned anywhere on the presentation surface. To prevent unwanted character overlap, excessive

gap between characters, or characters running off the edge of the presentation space, the values of

each character’s recommended escapement must be known.

23
This subset includes the following attributes (in addition to those defined for the minimal subset):

Control attributes

minimum space amplification

maximum space amplification

pairwise escapement adjustment

These attributes are repeated for each character and for each writing mode supponed by the font resource.

Positioning attributes

character name

writing mode

position point

escapement point

extents (4 values)

sectored space adjustment

amplification

correction

white space adjustment

op's

Formatting programs may use the positioning information to determine each character’s position on

a presentation surface, with each character being presented at its designated point. Or, the

formulating program may designate the starting point (and the text character string, with each

character providing information needed for the next character's presentation position).

1.2.4.4 Image Presentation

The information contained in these subsets may be stored and used separately from the information

contained in the function sets defined for referencing and positioning. A font resource may not be

identified as supporting one of these subsets unless it contains all of the attributes defined for that

subset. That is, if a resource contains ail font attributes except one from the minimal subset, then

the resource cannot be identified as supporting either the minimal or the complete subset

Minimal Presentation

The minimal subset level of character presentation supports only the bitmap format of character

image definition. Alternate formats will not be recognized.

This subset includes the following attributes:

Control attributes

font name

bodysize units

Presentation attributes (per character and rotation)

character name

charaaer shape information

The attributes for this format will be defined.

This is the basic format required for definition of character shapes for the registration of characters

for Part 3 of the ISO DP 9541 standard.

24
Complete Presentation

Given the positioning point for a character, the shape of the character must be presented on the

presentation surface using the device technology applicable to that device. All character shape

information is defined relative to an ori^n, which has a defined x-y offset and rotation from the

escapement box origin (current positioning point). Non-ISO character image technologies do not

need to be supported by this subset level.

Control attributes

image technology

Presentation attributes (per character and rotation)

character-shape information fon

straight line outline

circular outline

conic outline

Bezier outline

composite

The shape information may be defined separately for each device technology, but there should be one set of device independent positioning information for each resource ID. Thus, the shape

information may be repeated for several different technologies in any one font resource, or the

shape and positioning information may be contained in separate files with cross reference pointers.

1.2.5 Images

PostScript includes a very minimal set of capabilities for handling images (raster bitmaps). The

operators provided are

image—^renders a sampled image onto the current page. The sampled image is a rectangle array of

width X height sample values, each of which consists of bits sample bits of data (1, 2, 4, or 8).

imagemask—similar to the image operator, however, it tracks the source image as a mask of 1 bit sample that is used to control where to apply paint (with the current color) and where not to. It is most useful for printing characters as bitmaps. Such bitmaps represent masks through which a color is to be transform^.

The image capabilities are too limited to meet CALS requirements (or those of the publishing

industry in general). This topic requires funher study. [The CGM can be extended to

incorporate a very general set of facilities compatible with the raster portions of

Group 4 facsimile.]

1.2.6 Definition and Instantiation of Objects

One capability that is missing in the CGM is the ability to define an arbitrary picture component

(e.g. a symbol or non-primitive object) which can be instanced (repeated) multiple times with a

single picture or over shared amongst different pictures in a document

As will be further discussed, this capability is needed for both publishing and engineering drawing

applications.

The capabilities of both PostScript (based on a programming language approach) and Interpress

(based upon defining extended operators) are described below. Appendix B contains detailed

descriptions of the corresponding PostScript and Interpress features.

25
1.2.6. 1 PostScript Procedures

A PostScript procedure is a set of operations grouped together with a common name. This set of

operations is stored with its key in a dictionary. When the key appears in a program, the associated

set of operations is carried out.

Procedures are defined in exactly the same way as variables. The program must place the procedure

name (preceded by a slash) on the stack, followed by the set of operations that make up the

procedure. Then, the def operator is used to store the operations and name in the current

dictionary.

1.2.6.2 Interpress Symbols

The concepts of symbol and instance are provided in Interpress by composed operators and

transformations. A graphical symbol can be defined as a composed operator. When an instance, or copy, of the symbol is to be printed, the current transformations will be applied to all coordinates as the symbol csdls imager operators. The properties of the current transformation will thus, determine

the position, size, and rotation of the instance on the printed page.

The principal use of symbols and instances in Interpress is for printing characters. Each character is defined by a composed operator, called a character operator. These operators are invoked usually

by SHOW, with a current transformation that achieves the proper size, orientation and position of

the character.

Instancing can also be used for other purposes. Graphical objects that are repeated often on a page

or throughout a document may be tracked as instances. A symbol is defined as a composed

operator and called with an appropriate current transformation in order to generate each instance.

26
2.0 Technical Drawings and Product Data

2.1 Introduction

It is recognized that some extensions to computer graphics standards are necessary to properly

support the creation of drawings and views of product model data. The following extract from the

Final NBS Reportfor CALS - FY86 summarize a contractor's findings:

The addition of several facilities to the graphics standards would greatly improve the ability of

these standards to efficiently represent the drawings and views implicit in IGES and PDES

files. These additions are described in the following paragraphs.

Support for full conics including hyperbolas and parabolas

Support for splines, including at least one of the parametric spline and rational B -spline

representations.

Support for surface definitions, including surfaces of revolution and cylinders.

Support for a ROUNDED RECTANGLE output primitive.

Support for many new line types, including some or all of the 11 forms of "arrows"

defined in IGES through registration and subsequent standardization.

Support for the CENTERLINE symbol as new standardized marker type.

Addition of facilities to more directly control and specify such features of text strings as subscripts, superscripts, and fractions. At present, these features can be generated only

by using the more primitive APPEND TEXT and by changing associated text attributes

like CHARACTER HEIGHT, CHARACTER SPACING, and TEXT ALIGNMENT.

In IGES/PDES the slant of the text is independently specified from the type face (e.g.,

Helvetica Italics Bold). The Computer Graphics Interface (CGI) standard allows, via the

Character Orientation element, text characters to be skewed ("slanted"). This feature is not

directly available in the Graphical Kernel Sytem (GKS) standard and the Programmers

Hierarchical Interface Graphics System (PHIGS) standard; it can occur only as a result of

the segment or structure transformations.

In PDES, continuous text alignment is used to align multiple text strings. This feature is also available in CGI/CGM. It should be added to GKS, GKS-3D (GKS in three

dimensions) and PHIGS.

The six predefined IGES SECTTION entity patterns not corresponding to standardized

CGI/CGM patterns should be registered.

Support for user-defined line types.

S uppon for multiple color tables.

NBS/ICST generally suppons these conclusions, although recommendations made in this report

are more comprehensive and somewhat different than those above for extensions in several areas. Funher, this work is limited to extensions to the CGM as dictated by the actual requirements from

standards for product data description and drawings themselves, rather than being limited to investigation of the IGES standard (which does not describe engineering drawings, per se, but

rather the transfer of the complete information necessary to describe the representation of a product.)

27
The methodology used to define the capabilities required to define images of engineering drawings

was the following:

1. Review requirements from the standards for the production of engineering drawings listed in

Section 3.0 of the Background section above; then extract the required representational capabilities

needed in the CGM.

2. Review the IGES standard to extract entities for which the CGM must be able to describe

images; then extract the required representational capabilities needed in the CGM.

3. Consider the CALS system level requirements in areas such as use of symbol libraries. Since no

such requirements exist in explicit form and there is no well-defined CALS reference model, the

capabilities of commercially available products were used to derive requirements.

2.2 IGES Entities

IGES Version 3.0 contains the following types of entities. Each of these entities and suggestions on how it might be rendered by systems implementing graphics standards are described in

Appendix C. TTiis material was extracted from the Final NBS Reportfor CALS - FY86, The CGM

must be capable of describing images (graphical representations) of these entities:

CIRCULAR ARC

COMPOSITE CURVE

CONIC ARC - registration proposal prepared

COPIOUS DATA

PLANE

LINE

PARAMETRIC SPLINE - registration proposal prepared

PARAMETRIC SPLINE SURFACE

POINT

RULED SURFACE

SURFACE OF REVOLUTION

TABULATED CYLINDER

TRANSFORMATION MATRIX

FLASH ENTITY

RATIONAL B-SPLINE - registration proposal prepared

RATIONAL B-SPLINE SURFACE

OFFSET CURVE

CONNECT POINT

NODE

FINITE ELEMENT

NODAL DISPLACEMENT AND ROTATION

OPpcp'T STFRFArF

CURVE ON PARAMETRIC SURFACE

TRIMMED (PARAMETRIC) SURFACE

ANGULAR DIMENSION

CENTERLINE

DIAMETER

FLAG NOTE

GENERAL LABEL

GENERAL NOTE

LEADER

LINEAR DIMENSION

POINT DIMENSION

RADIUS DIMENSION

SECTION

28
GENERAL SYMBOL

SECTIONED AREA

WITNESS LINE

ASSOCIATIVITY DEFINITION

ASSOCIATIVITY INSTANCE

DRAWING

LINE POINT DEFINITION

MACRO CAPABILITY

PROPERTY

SUBnGURE DEFINITION

TEXT FONT DEFINITION

VIEW ENTITY

EXTERNAL REFERENCE ENTITY

NODAL LOAD/CONSTRAINT ENTITY

COLOR DEFINITION ENTITY

TEXT DISPLAY ENTITY

2.3 Required Capabilites

2.3.1 Lines

The following material is drawn from ANSI Y14.2M-1979 (Line Conventions and Lettering) and

explains how "lines" are used in product definition drawings:

Line widths - Two widths of lines are recommended for use on manually prepared drawings.

(See Figure 7.) One width of line is acceptable on drawings prepared by automated methods. The

ratio of line thickness should be approximately two-to-one. The thin-line width should be

approximately 0.35 mm or 0.016 inch and the thick-line width approximately 0.7 mm or 0.032

inch. The acmal width of each line should be governed by the sizes and styles of drawing, and the

smallest size to which it is to be reduced. All tines of the same type should be uniform throughout

the drawing. Spacing between parallel tines should be such that there is no fill-in when reproduced

by available photographic methods. Note: spacing of no less than 1.5 mm (0.06 inch) normally

meets reproduction requirements.

Line quality - All tines should be clean cut, opaque, uniform, and properly spaced for legible

reproduction by all commonly used methods, including microfilming in accordance with industry

and government requirements. When manually produced, there should be a distinct contrast

between the two widths of lines. Contrast must be obtained only by variance in the relative widths

of the lines. In no case should contrast be achieved by a difference in density, opaqueness or color.

Visible lines - The visible tines, Figure 7 and 8, should be used for representing visible edges or contours of objects. Visible tines should be drawn so that the views they outline clearly stand out on the drawing with a definite contrast between these tines and secondary tines.

Hidden lines - Hidden tines. Figures 7 and 8, consist of short evenly spaced thin dashes and are used to show the hidden features of the object. The lengths of the dashes may vary slightly in

relation to the size of the drawing. Hidden tines should always begin and end with a dash in contact

with the visible or hidden tine from which they start or end, except when such a dash would form a continuation of a visible line. Dashes should join at comers, and arcs should start with dashes at tangent points. Hidden Lines should be omitted when their use is not required for the clarity of the

drawing. Although features located transparent materials may be visible, they should be treated as concealed features and shown with hidden lines.

Section lines - Section tines. Figures 7 and 8, are used to indicate the cut surfaces of an object in a section view.

29
sOTk:

VISIBLE LINE.

( width J030 TO J029)

hidden line "width .015 TO .022)

SECTION line thin

(width .015 TO j02 2)

CENTER UNE

DIMENSION

LINE

EXTENSION i UNE

AND LEADERS

6

7

THIN

(WIDTH ^5 TO ^22)

r- Leader

£xfens/on L/ne ^ O/mens/on L/ne "^

3.50 Thin

(width .015 TO ^22)

CUTTING -PLANE

LINES OR

VIEWING - PLANC

LINES

6

^ 9

I _ _(width _ .050 TO

7wioT»r!o5orT^o3ir

BREAK LINES

I I

THICK

(width .030 TO .03f)

THIN

(width 015 TO 022)

PHANTOM LINE 12

THIN

(width 015 TO .022)

STITCH LINE 13 (i^OTh .015 "to

* 022)

Thc'.e approximate line >aidtht are intended to differentiate between THICK and THIN lines and are not values for control of a«.wcpt4nce ur rejection of the draum|5

Figure 7. Line Styles and Widths

30
Figure 8. Lines in Engineering Drawings

31
Center lines - Center lines. Figures 7 and 8 consist of alternating long and shon dashes. They

are used to represent axes of symmetrical parts and features, bolt circles, and paths of motion. The

long dashes of the center lines may vary in lengths, depending upon the size of the drawing. Center

lines should start and end with long dashes. They should not intersect at the spaces between dashes

or by crossing the long or short dashes. Center lines should extend uniformly and distinctly a shon

distance beyond the object or feature of the drawing unless a longer extension is required for

dimensioning or for some other purpose. They should not terminate at other lines of the drawing

nor should they extend through the space between views. Very short center lines may be unbroken

if no confusion results with other lines.

Symmetry lines - This is a center lines used as an axis of symmetry for a partial view. The line

of symmetry is identified by two thick short parallel lines drawn at right angles to it. They are used in representing partially drawn views and partial sections of symmetrical pans. Symmetrical

view visible and hidden lines may extend past the symmetry line if clarity would be improved.

Dimension lines - Dimension lines. Figure 7 and 8 are used to indicate the extent and direction

of dimensions and are terminated by neatly-made uniform arrowheads. The length of the arrowhead

should be equal to the height of the dimension numerals if possible. If inadequate space is available, the arrowhead may be shown outside the dimension limit

Extension lines - Extension (wimess) lines. Figures 7 and 8, are used to indicate the point or

line on the drawing to which the dimension applies. A short gap is left where the extension line

would join the object, so as not to confuse extension lines with the lines of the object

Extension lines are also used to indicate the extension of a surface to a theoretical intersection.

When a point is located by extension lines, the extension lines should pass through the point

Leaders - Leaders, Figures 7 and 8, are used to direct notes, dimensions, symbols, item

numbers, or pan numbers to features on the drawing. A leader should generally be a single straight

inclined line (not vertical or horizontal), except for a short horizontal portion extending to the center

of the height of the first or last letter or digit of the note. This horizontal portion is optional and if used it should not underline the note. The leaders should terminate as follows:

a) Without symbol, if they end on a dimension line .

b) With a dot 1.5 mm or 0.06 inch minimum diameter, if they end within outlines of an object

.

c) With an arrowhead, if they end on the outside of an object

d) With or without a dot or arrowhead on drawings prepared by computer automated techniques.

Leaders should not be curved in any way and should not cross each other unless unavoidable. Two

or more leaders to adjacent areas on the drawing should be drawn parallel.

Cutting-plane lines - Cutting-plane and viewing-plane lines. Figures 7 and 8, are used to indicate the location of cutting planes for sectional views and the viewing position for removed

partial views. Two forms of cutting-plane and viewing-plane lines are approved for general use. Break Lines - Two forms of break lines are approved for general use as follows:

a) A freehand thick line. (See Figure 7, line 10.)

b) Long ruled thin dashes joined by zigzags. (See Figure 7, line 11.)

32
Phantom lines - Phantom lines (Figure 7, line 12) consist of long, thin dashes separated by pairs

of short, thin dashes. The long dashes may va^ in length, depending on the size of the drawing.

Phantom lines are used to indicate alternate {wsitions of moving parts (Figure 8); adjacent positions

of related pans; and repeated detail. These lines are also used for features such as bosses and lugs

(later moved); for delineating machining stock and blanking developments; for piece pans in jigs

and fixtures; and for bend lines on drawings or formed metal parts. Phantom lines should stan and

end with long dashes which may vary in length, depending on the size of the drawing.

Stitch lines - Stitch lines (Figure 7, lines 13 and 14) consist of shon, thin dashes and spaces of

equal lengths. The dots are approximately 0.016 (0.35 mm) in diameter and 0.12 inch (3 mm)

apart.. Stitch lines are used for indicating a sewing or stitching process.

Chain lines - The chain line (Figure 7, line 15) consist of thick, alternating long and shon

dashes. This line is used to indicate that a surface or surface zone is to receive additional

manufacturing treatment within limits specified on the drawing. (See Figure 8.)

Arrowheads - Arrowheads may be prepared manually or mechanically. The length and width

should have a ratio of approximately 3:1. The width of the arrowhead should be proportionate to the thickness of the lines used. Consistency of the style of an arrowhead should be contained

throughout the drawing. See Figure 9 for acceptable arrowhead styles.

Figure 9. Arrowhead Styles

In addition to the generic line types defined in ANSI Y14.2M, ANSI and DoD standards in specific areas require the use of additional types of lines. Insufficient time is available at present to fully

investigate these and categorize them. To illustrate the general nature of the need for such lines

types. Appendix A contains extracts from two Military Standards define other linestyles and specify

their meanings.

In summary, many additional linestyles are required to support engineering drawings. There are additional requirements on how patterns stan and end within line segments beyond those that

computer graphics standards alone can satisfy. Some of these restrictions may need to be stated in

the CALS application profile since they go beyond what can be specified through the registration

process alone. For example, there are special rendition requirements for hidden lines that cannot be

satisfied by a polyline primitive with the appropriate linestyle alone. This happens because the

conformance requirements for computer graphics standards do not specify how linestyle patterns

must be continued from segment to segment within a polyline, nor do they specify how such a line

must end. NBS/ICST will write registration proposals for such items to include the additional

conformance requirements, however, they may be rejected by the standards committees.

33
[ Note: A linetype registration proposal has been prepared for each of the above

linestypes, with the following exceptions:

- visible lines can be done with linetype solid;

- symmetry lines cannot be done with a single graphical line of any type; a symbol

facility could be used, or a set of individual line elements;

- single and double arrow linetype can be used for teaders and dimension lines;

- cutting plane lines must be done as a set of individual lines since they can't be

represented as a single linetype.

Some restrictions, such as allowable widths of lines and styles of text in

engineering drawings, will need to be stated in the application profile for CALS.]

2.3.2 Symbols

The general intent of this section is to illustrate that the requirements for symbols in engineering

drawings cannot be met by the polymarker primitives of the graphics standards.

International Standafd ISO 3461 defines the general characteristics of symbols used in engineering

drawings. This International Standard applies to graphics symbols which may be:

a) placed on equipment or parts of equipment of any kind in order to instruct the persons

handling the equipment as to its use and operation:

b) placed on sites and ways where people may assemble or move, giving them instructions,

such as prohibitions, warnings, rules or limits, regarding their behavior

c) used in pictorial reproductions, such as plans, drawings, layouts, guidelines and similar

documents.

Definitions

For the purposes of ISO 3461, the following definition applies:

Graphic symbol: A visually perceptible figure produced by means of writing, drawing, printing or other manufacturing techniques. It is used to transmit a message and represents in an

understandable manner, independently of any language, an object, concept or state.

Graphics symbols stand for objects, concepts or states. (What a symbol stands for is usually

known as the "referent ") This includes abstract references such as conditions, relationships, facts or actions.

Functions

As a rule, graphic symbols are used to:

a) identify (for example to describe a piece of equipment or an abstract concept);

b) qualify (for example to describe a variation or a secondary function);

c) instruct (for example to describe an operation or method of use);

d) command(that something must or must not be done);

e) warn (for example of danger);

0 indicate (for example direction, quantity).

34
Graphic Form

For each graphic symbol that is required an original design is prepared. An original design is a symbol design drawn and presented in the manner described below, i.e,. drawn out on the basic

pattern with due regard to the principles defined below. The basic pattern described below

constitutes a frame in which the original design may be inscribed. The lines indicated in the basic

pattern (circles, hexagons, octagons, squares, etc.) are intended as an aid to the designer in

drawing up the original designs. The form of the graphics symbols should be suitable for

economical reproduction by means of commonly applied techniques, such as etching, engraving,

printing, and photographic means.

Basic Pattern

The basic panem (Figure 10) comprises:

1) a basic square of side 50 mm; this measure is equal to the nominal measure, a , of the original

2) a basic circle of 36 mm diameter having approximately the same area as the basic square;

3) a second circle of 50 mm diameter, being the inscribed circle of the basic square (1);

4) a second square of side 40 mm, which touches the basic circle (2) with its comer,

5) a rectangle of approximately the same area as the basic square (1), with the long side (62.5

mm) horizontal and symmetrical with the basic square;

6) a second rectangle having approximately the same area as the basic square (1), with its long

side (62.5 mm) vertical and symmetrical with the basic square;

70 a third square formed by the lines passing through the points of intersection of the basic square

(1) and the basic circle (2); the sides of this square are oriented at 45 degree to the basic square

and the comers of this square define the limits of the horizontal and vertical dimensions of the

basic pattern;

8) an irregular octagon formed by lines inclined at 30 degrees to the sides of the square (7);

The basic pattern is laid upon a 75 mm x 75 mm square subdivided by a 12.5 mm square grid

which also coincides with the basic square (1).

The original design of a graphics symbol should be fitted into the basic pattern according to the

following principles:

1) for a symbol consisting of a single geometrical form, such as a circle or a rectangle, the

corresponding geometrical forms of the basic pattern should be used, in which case the Lines of

the basic pattern should be the center lines of the .1 inch thick lines of the symbol being

designed;

2) to achieve the impression of uniform perceived size among symbols, attention should be given

in the equalization of surface areas; for example, a circle without external pans should be

drawn upon the basic circle (2) (see Figure 11, pan C) whereas a circle with external pans

should be drawn upon the smallest circle (3) (see Figure 1 1, pan D).

Figure 1

1 gives several examples of symbols created according to this standard.

35
Figure 10. Basic Symbol Pattern

Figure 11. Examples of Symbols

36
Orientation of the Symbols

The majority of graphic symbols preserve their meaning in any position. However, when the

meaning of a graphic symbol does depend on its orientation of position, this shall be explicitly

stated. Figure 12 illustrates a graphics symbol not dependent on its position (a television receiver),

and a graphic symbol dependent on its position (a "bar").

The statement concerning the position dependency could read as follows:

"The meaning of the graphic symbol depends on its position. Care shall be taken that it is not

reproduced on rotating controls."

Figure 12. Symbol Orientation

Use of Symbols in Engineering Drawings

Figure 13 illustrates the typical use of symbols in engineering drawings. A large number of simple

symbols are used repetitively in different locations to construct the drawing. Such drawings should

not be transferred by building each symbol from primitives available in the COM, nor is it feasible

to make each required symbol a Generalized Drawing Primitive or marker symbol. It is absolutely

essential that any technique used to transfer such drawings allow:

1) a symbol to be defined once in a picture and then instanced repetitively,

2) externally defined symbols from standard libraries to be included by reference.

This must be done for these reasons:

1) to reduce the required communication bandwidth;

2) to reduce the storage required for the picture;

3) to promote standardized appearance of drawings.

37
Figure 13. A Typical Engineering Drawing Showing the Use of Symbols

38
2.3.3 Curves

Insufficient time and funding are available in the present SOW to investigate this area thoroughly.

For now, it is assumed that the IGES entities represent a sufficient set. 2.3.4 Hatch Styles

A wide variety of hatch styles are used in engineering drawings for purposes such as representing

the nature of materials. Figure 14 illustrates some typical ones. Insufficient time and funding are available in the present contract to investigate this area thoroughly, but based on preliminary

observations, the following capabilities appear to be needed:

1) All necessary patterns available as re^stered hatch styles ( for reasons similar to those stated for

marker symbols above, drawings containing these hatch patterns cannot be transferred between

systems by decomposing the patterns using the individual primitives available in the CGM.)

2) Arbitrary fill areas and clipping regions are needed to represent drawings containing such hatch

patterns. These cannot be approximated by breaking them up into simpler areas since pattern

continuity cannot be maintained.

[ Note: Registration proposals were prepared for all types of section lining (hatch

styles) except the following, which can be done with a built-in hatch style:

- electric windings, etc. hatch index 6, horizontal/vertical crosshatch.

Registration proposals were prepared for the following hatch styles to support the

more exact rendition requirements of the engineering drawing standard from a similar type in the built-in CGM linestyles. In each case, the drawing standard

requires ”45 degree lines” while the built in hatch styles guarantee only "positive”

an^or "negative” slope.

- cast iron, etc. similar to hatch index 3, positive slope equally spaced

parallel lines

- white metal, etc. similar to hatch index 6, positive slope/negative slope

crosshatch]

39
CAST IRON OR

malleable iron

AND GENERAL

USE FOR ALL

MATSRIALS

Bronzt. brass, copper, and

compositions

White metal, zinc,

lead, babbitt, and

alloys

Magnesium,

aluminum, and

aluminum alloys

Rubber, plastic, electrical insulation

13

Marble, slate, glass, porcelain, etc.

14

Sound insulation Earth

8

Cork, felt, fabric,

leather, fibre

Thermal

insulation

Titanium and

refractory material

Sand

Electric windings,

electromagnets,

resistance, etc.

17

Water and

other liquid^

o C> ° c O a ^ ^

0 - — ^ O- ^ O ^ o

18

r \ \ \ \

Concrete Across gram » ^ With gram ( '"OOa

Figure 14. Hatch Styles from Y14.2M

40
2.3.5 Text

The text capabilities that are actually required in engineering drawings are quite simple, although

most drawing systems provide more advanced feamres. This paragraph will first present the

requirements taken from Y14.2M-1979, and then will describe the enhancements that are needed

to, for example, render IGES defined data without loss of quality.

2.3.5.1 Y14.2 Lettering Requirements

Single-stroke Gothic Lettering

Lettering on drawings must be legible and suitable for easy and rapid execution. These

requirements are met in the recommended single-stroke gothic characters shown in Figures 15 and

16 or adaptations thereof, which improve reproduction legibility. One such adaptation by the

National Microfilm Association is the gothic style Microfont alphabet intended for general usage.

(See Figure 17.) Opaque and well-spaced lettering is required on the drawing for microfiTm

reproduction.

Inclined or Vertical Lettering

Either inclined or vertical lettering is permissible. Only one style of lettering should be used

throughout a drawing. The preferred slope for the inclined characters is 2 in 5 or approximately 68

degrees with horizontal. (See Figure 16.)

ABCDEFGHUKLMNOP

ORSTUVWXYZ&

Figure 15. Vertical Lettering

41
/] BCDEFOHUKLMNOP

0R5TUVWXYZ& ' 1234567890

Figure 16. Inclined Lettering

ABCDEFGHI JKLMNO

PQRSTUVWXYZ

I 23HS67890

Figure 17. Microform Lettering

Use of Upper-case Letters

Upper-case letters should be used for all lettering on drawings. When additions or revisions are made, the original style of lettering should be maintained.

Lettering for titles, subtitles, drawing numbers, and other uses may be made free-hand, by

typewriter, or with the aid of mechanical lettering devices such as templates and lettering machines.

Regardless of the method used, all characters are to conform, in general, with the recommended

gothic style and must be legible in full or reduced size copy by any accepted method of

reproduction.

A type face comparable to light-line Pica Gothic, block numerals is preferred for typing on

drawings.

42
Size and Spacing of Lettering

The recommended minimum freehand and mechanical letter height for various applications are defined in the standards as follows:

Letters in words should be spaced so that the background areas between the letters are approximately equal, and words are to be clearly separated by a space equal to the height of the

lettering. For legible reproduction, a space between two letters of at least 0.06 inch (1.5 mm) is to be used whenever possible. The space between two numerals having a decimal point between them

is to be a minimum of two thirds the height of the lettering. The vertical space between lines of

lettering should be no more than the height of the lettering, and no less than half the height of the

lettering used.

Notes should be placed horizontally on drawings and separated vertically by spaces at least equal to double the height of the character size used, to maintain the identity of each note. The division line of a common fraction should be parallel to the direction in which the dimension

reads and should be separated from the numerals by a maximum of 0.06 inch (1.5 mm) spacing.

When fractions occur in notes, tables, and lists, the diagonal division line is permissible. Numerals

in fractions should be the same size as other numerals.

Spacing between max/min dimensions should be one-half of the character height

Lettering should not be underlined except when special emphasis is required. The underlining

should not be less than 0.06 inch (1.5 mm) below the lettering.

The lettering height spacing, and proportions in Figure 15, 16, and 17 normally provide acceptable

reproduction or camera reduction and blow-back. However, manually, mechanically,

opti-mechanically, or electro-mechanically applied lettering (typewriter, etc.) with height, spacing,

and proportions less than those recommended are acceptable when the minimum reproducibility and

legibility requirements of the accepted industry or military reproduction specifications are met.

Therefore, the basic requirements for lettering on a drawing is that fully legible copies may be

produced.

2.3.5.2 Text in IGES

The IGES standard defines an entity called general note which consists of strings of text that are incorporated in other entities for producing drawing labels and annotation. IGES defines the

following fonts for use with this entity:

0. Symbol font (use longer recommended)

1. Standards block

2. LeRoy

3. Future

4. Fastfont

5. Calcomp

6. Comp 80

7. Microfilm standard

8. ISO standard

9. DEN standard

10. Military standard

1 1 . Gothic

12. New gothic

13. Lightllne gothic

14. Simplex Roman

15. Italic

43
16. APL

17. Century schoolbook

18. Helvetica

1001. Symbol font 1 1002. Symbol font 2

In addition, the IGES text model includes several capabilities that are not present in computer

graphics standards such as the CGM. Appendix C contains extracts from the IGES standard that

explain these capabilities.

IGES also includes a text font definition entity that enables a text font to be described as a sequence of strokes. Appendix C contains extracts from IGES 3.0 that explain this entity. This

capability could be built on top of the CGM by stroking out the individual characters as required. A

more general solution to compatibility is described in Conclusions Section, where a common font

definition mechanism is proposed, based on ISO 9541, for product data standards, graphics

standards and publishing standards.

2.3.6 Images

Based upon review of project descriptions, CALS will capture and store a great deal of existing

engineering drawing data in raster form. Neither the CGM nor IGES adequately address this area.

It is likely that a solution developed for the use of image (raster) data in the publications area will

also effectively address the requirements of engineering drawings.

44
IV. CONCLUSIONS

1.0 Introduction

This section presents the list of extensions that are needed to the COM. It is anticipated that most of

these extensions can be implemented through the registration process. In several areas—as described in Section V below—additional study is necessary to determine the precise nature of the

required extensions.

NBS/ICST used the following criteria in defining required extensions:

1) Picture description must be as compact as is practical, consistent with ease of generation and

interpretation. (This implies, in particular, that a "symbol" or "macro" capability is needed, as is access to external libraries of symbols.)

2) Only "presentation-related" relationships between objects and attributes of objects need be

preserved in the transfer. (This places the transfer at an intermediate level between that provided by

IGES and by the (unextended) COM. When (1) and (2) are considered jointly, they imply that

transfer by "approximation with lower-level graphical entities"—such as approximation a curve with a sequence of line segments or a centerline with a set of polylines and/or marker types—is unacceptable. A local system is free however to make such approximations in the process of

imaging a picture, consistent with accuracy restrictions.)

3) Extensions must be consistent with the philosophical basis of standards in the areas of Open

Systems Interconnection (naming and addressing in particular) and Office Systems (font

architecture in particular.)

2.0 Lines

A user defined linestyle, similar to that described in Section 1.2.1 of the Discussion section is required.

Linetypes that directly represent the presentation requirements of engineering drawings must be

defin^. Where the limited capabilities of the built-in polyline primitive—which allows a linetype to consist only of a sequence of line segments and gaps, without precise control over its rendition—are exceeded, GDPs may be needed. Some conformance data may need to be placed in

the application profile.

Some of the types needed are:

1) center line,

2) phantom line,

3) break line,

4) lines with arrows on one or both ends.

Extensions to line attributes to include line end styles and joining options.

[Note: A registration proposal for each of those from Y14.2M has been written.

Investigation of other standards is needed to identify others.]

45
3.0

Symbols

As described above, the polymarker primitive is not particularly useful for either publishing or engineering drawing. The registration of additional marker types has little utility. Instead, a general

object definition and instantiation capability as described is needed. [ No registration

proposals have been completed in this area.] 4.0

Curves

The following curves are required as GDPs. As necessary, Escapes are required to suppon their

attributes.

1) Bezier curves,

2) B-splines,

3) Conics and conic arcs,

4) Other splines as determined by the study described in .

[Note: A registration proposal for each of these has been written.]

A closed figure primitive is required, together with:

1) Arbitrary clipping region,

2) Arbitrary fill boundary.

[ No registration proposals have been completed in this area.]

5.0

Hatch styles

Registered hatch styles to support engineering drawing uses as defined in Section 2.3.4 of the

Discusion section are required.

[Note: A registration proposal for each of those from Y14.2M has been written.

Investigation of other standards is needed to identify others.]

Registered hatch styles to support technical and administrative publication uses are required.

Insufficient data is available to specify these now.

6.0

Text

The text model must be completely replaced through the use of GDPs and Escapes to adopt the

model and architecture of ISO DP 9541.

Some specific fonts identified in Section 2.3.5 of the Discussion section for use in engineering

drawings must be registered.

[ No registration proposals have been completed in this area.]

46
7.0 Images

A raster "input" primitive to accept input from scanners and files stored on disc (optical or not) is required.

The role of compression in the metafile must be clarified. Although it is best to rely on other

standards for necessary compression, it may be necessary to add GDPs to cover more sophisticated

compression techniques in the CGM in the short term. Tlie CClTi Group 3 and Group 4 facsimile

standards do not provide either color or grey scale capabilities.

Additional raster attributes are required to support image processing.

[ No registration proposals have been completed in this area.]

8.0 Naming and External References

The naming and definition of attributes and objects must be extended from the simplistic

two-dimensional (positive and negative integer indices separating the space into registered and

implementation-dependent types) name space to one consistent with the "resource" view of objects seen in most modem commercial systems and exemplified in the ISO DP 9541 font work. ( A

limited anempt was made in the CGM by including a list of font names that are then mapped to indices. This was a first step in the right direction.) This can be done fairly easily by defining

GDPs and Escapes to replace the existing output primitives and attributes. It is absolutely

essential that this be done to insure the long-term coherence of information

processing standards. Neither the CGM nor other computer graphics standards

will find acceptance in modern applications without these extensions.

47
V. AREAS REQUIRING FURTHER INVESTIGATION

1.0 Curves

More technical work is necessary to explore:

1. Define the actual requirements in the two selected application areas for curves ( as opposed to guessing them based on current practice.

)

2. Investigate implementation difficulty to determine the cost of implementation.

3. Determine mathematical properties of conversions between curves (e.g. loss of accuracy, loss of

desired curvature, etc.)

4) Define a minimal set of curves that:

a) have implementation difficulty appropriate for various classes (price/performance) of

systems;

b) can be readily used to approximate other curves. To illustrate some of the complexities involved, the following material—provided by a member of

the committee that developed the IGES standard—shows some of the differences and similarities

between two curves: B-spIines and Bezier curves.

Differences between B-splines and Bezier curves

1) Bezier curve + Composite curve = B-spline

That is, the classes of functions are in fact the same.

2) Commonalities between Bezier curves and B-splines

exact conics (rational quadratics), though the algorithms for conic to Bezier (or B-spline)

conversions are not in the public domain, to the best of my knowledge.

nonrarional polynomial curves of any degree.

nice mathematical properties: convex hull, plane intersection, etc.

3) Bezier

CO continuity can be explicit (common endpoint).

Faster evaluation (by divided differences), though not as fast as power basis. Points and

deviations.

Greater storage requirements (deg+1 points per segment, while B-spline can use Const

number of segments if continuity is maximal).

More stable (lower condition number than power basis or B-spline).

Easy mathematics: evaluation, degree evaluation, degree evaluation, subdivision.

48
Trivial conversion to B-spline.

Immediate evaluation of points and derivations at parametric start and end.

4) B-spline

parametric continuity given explicitly in the knot sequence. For exactness, prefer knots

with explicit multiplicity to repeated knots.

Mathematics is quite complex, but powerful: evaluation, adding and removing knots.

For repeated evaluation or intersection algorithms, will probably want to convert to piecewise Bezier first (this amounts to making all of the interior knots of multiplicity

degree and the two exterior knots of multiplicity degree +1.)

2.0 Text

Additional time and funding will be required to develop and define the new text GDP and

associated escapes (to implement attributes) that can fully implement the model of ISO DP 9541.

Extensions to the "CGM environment” compatible with the ISO font description and transfer work

must be developed.

3.0 Images

Additional funding will be required to develop and define raster input extensions and raster data

types needed to fuUy support technical and administrative publications. Specifically, the following

items are beyond the level of the current task:

1. Definition of standard interfaces to input scanning devices through the CGI/CGM and GKS.

2. Expansion of the attributes of raster data to accommodate the requirements of image processing

algorithms. For example, data is needed on the characteristics of input scanner (resolution,

frequency response characteristics, etc.) to properly process the data.

3. Families of standard compression algorithms must be developed beyond those currently

supponed in MIL-STD-1840 (Automated Interchange of Technical Information.) The one

algorithm in that standard (CCITT group 4 facsimile) as well as the one compression technique

supported in the CGM (a one-dimensional run-length encoding vaguely similar to Group 3

facsimile) are well known to be inadequate for "photographic” content. These techniques are useful

for rasterized text and geometric graphics, however these contents would most likely be

"compressed" by sending them in a CGM or ODIF format. The CGM can be easily extended with

additional raster primirive/sencodings, thereby completely removing the requirement for the

inclusion of Group 4 facsimile in MIL-STD-1840.

4.0 Specification of Data Record Contents

Escapes, GDPs, and Application data all contain information in data records. The standards do not

dictate how data in such records must be formulated or encoded. It is desirable that a standard

method be developed for all of these data records and promulgated throughout the standards

community with the intention that all registration proposals use this same standard method. At

present, we are specifying a "clear text" encoding only for all data records. This is clearly

inadequate to support binary coded transfer of complex drawings due to compactness

considerations.

49
5.0 Support for Named Items and "Symbol Libraries”

Extensions must be developed to replace the simplistic "indexed" definition of attributes in the

graphics standards with named definitions based on a resource model consistent with that of the

ISO Font standard. Techniques must be developed to allow picture components (symbols, macros)

to be defined and instantiate in pictures.

6.0 Definition of Registration Requirements and Development of Registration

Proposals

Additional work will be required to complete the definition of registration requirements and the

development of registration proposals in these areas:

1) Linetypes,

2) Hatchstyles,

3) Text fonts.

This is due to these factors:

1) The large number of registration proposals to be developed.

2) The long time-frame involved in sponsoring registration proposals through the approval process

and preparing necessary revisions and responding to comments from standards committees.

3) The need for a review of proposed items by the CALS community.

50
VI. RECOMMENDATIONS

1.0 Registration Proposals List

Recommendations for this task are the registration proposals themselves. The following list contains the categories and the names of the registration proposals developed under this CALS

SOW task. They have been submitted to ANSI for formal processing through ISO. Section 2.0

below contains the actual registration proposals that have been developed and submitted for this

fiscal year, and are in the order as listed below.

1) Linetypes

break line - style 1 break line - style 2

center line

chain line

double arrow

hidden line

phantom line

single aiTow

single dot

stitch line user specified dash pattern

2) Hatchstyles

across grain wood

bronze, brass, copper, and compositions

cast iron or mailable iron and general use for all materials

concrete

cork, felt, fabric, leather, and fiber

earth

magnesium, aluminum, and aluminum alloys

marble, slate, glass, procelain, etc. rock

rubber, plastic, and electrical insulation

sand

sound installation

steel thermal insulation

titanium and refractory material

water and other liquids

white metal, zinc, lead, babbitt, and alloys

with grain wood

3) Generalized drawing primitives

Bezier curve

conic arc parametric spline curve

rational B-spiine curve

4) Escape functions

set conic arc transformation matrix

set dash

set line cap

set line join

set miter limit

51
2.0 Prepared Registration Proposals

The following registration proposals are exactly as submitted to ANSI for formal registration.

They have all been submitted and are currently in the formal process.

52
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetype

Name: breaJc line - style 1

Description: break line linetype —style 1— consists of either one of two allowable

representations as specified in ANSI Y14.2M-1979 (Line Conventions

and Lettering.)^ This is simply a line having a "freehand" appearance.

This linetype is intended for use in engineering drawings

Additional Comments: The requirements stated in ANSI Y14.2M-197 9 shall be followed

when rendering this linetype.

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered for use with computer graphics standards to enable

compact storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (COM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

53
This page left intentionally blank.

54
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

dale of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetypb

Name: break line - style 2

Description: break line linestyle consists of either one of two allowable

representations as specified in ANSI Y14.2M-1979 (Line Conventions

and Lettering.) This is a line consisting of long dashes joined by

zigzags. Such lines have the following visual appearance:

^

This linetype is intended for use in engineering drawings.

Additional Comments: The requirements stated in ANSI Y14.2M-1979 shall be followed when

rendering this linetype.

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered for use with computer graphics standards to enable

compact storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

55
This page left intentionally blank.

56
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetype

Name: center line

Description: ^ center line linetype consists of alternating long and short dashes as specified in ANSI Y14.2M-1979 (Line Conventions and Lettering.) Such a line has the following visual appearance:

This linetype is intended for use in engineering drawings . The long

dashes may vary in length depending on the size of the drawing. Lines

drawn in this linetype shall start and end with long dashes. A very

short line may be unbroken.

Additional Comments: The requirements stated in ANSI Y14.2M-197 9 shall be followed

when rendering this linetype . In some cases, it is necessary to

exercise precise control over the manner in which two center

lines intersect in a drawing. In these cases, it is appropriate

to simulate this linetype by sequences of correctly placed

individual line segments . Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered • for use with computer graphics standards to enable

compact storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

57
This page left intentionally blank.

58
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetype

Name: chain line

Description: chain line linetype consists of alternating long and short dashes

as specified in ANSI Y14.2M-1979 (Line Conventions and Lettering.)

Such a line has the following visual appearance;

This linetype is intended for use in engineering drawings. Its rendition

is generally different from that of the dashed-dotted linestyle already

present in the graphics standards.

Additional Comments: The requirements stated in ANSI Y14.2M-1979 shall be followed

when rendering this linetype. In some cases, it is necessary to

exercise precise control over the manner in which two lines intersect in a drawing. In these cases it may be appropriate to

simulate this linetype by using sequences of correctly placed

individual line segments.

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered -for use with computer graphics standards to enable

compact storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

59
This page left intentionally blank.

60
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetype

Name: double arrow

Description: ^ double arrow linetype consists of a solid line terminated by two

arrowheads as specified in ANSI Y14.2M.-1979 (Line Conventions and

Lettering) requirements for dimension lines. The arrows are rendered so that the arrow tip occurs at the first and last points in the defining

set. Such a line has the following visual appearance:

This linetype is intended for use in engineering drawings

Additional Comments: requirements stated in ANSI Y14.2M-1979 shall be followed

when rendering this linetype

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered for use with computer graphics standards to enable

compact storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

61
This page left intentionally blank.

62
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetype

Name: hidden line

Description: ^ hidden line linetype consists of short evenly spaced dashes as specifiec

in ANSI Y14.2M-1979 (Line Conventions and Lettering.) Such a line has the

following visual appearance:

This linetype is intended for use in engineering drawings . The dashes may

vary in length depending on the size of the drawing. Lines drawn in this

linetype shall start and end with a dash. Dashes shall join at corners,

and arcs drawn with this style shall start and end with dashes . These

rendition requirements are different from the dashed linetype that is

already defined in the graphics standards.

Additional Comments: The requirements stated in ANSI Y14.2M-1979 shall be followed when

rendering this linetype. In some cases, it is necessary to exer- cise precise control over the manner in which two lines intersect

in a drawing. In these cases it may be appropriate to simulate

this linetype by using secpiences of correctly placed individual

line segments

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered for use with computer graphics standards to enable

compact storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5 . 4 . 1

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

63
This page left intentionally blank.

64
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetype

Name: phantom line

Description: phantom line linetype consists of long dashes separated by pairs of

short dashes as specified in ANSI Y14.2M-1979 (Line Conventions and

Lettering.) Such a line has the following visual appearance:

This linetype is intended for use in engineering drawings. The long

dashes may vary in length depending on the size of the drawing. Lines

drawn in this linetype shall start and end with long dashes which may

vary in length aepending on the size of the drawing.

Additional Comments: The requirements stated in ANSI Y14.2M-1979 shall be followed

when rendering this linetype. In some cases, it is necessary to

exercise precise control over the manner in which two lines i.ntersect in a drawing. In these cases it may be appropriate to simulate

this linetype by using sequences of correctly placed individual

line segments.

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered for use with computer graphics standards to enable

compact storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

65
This page left intentionally blank.

66
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetype

Name: single arrow

Description: ^ single arrow linetype consists of a solid line terminated by an arrowhead as specified in ANSI Y14.2M-1979 (Line Conventions and

Lettering) requirements for dimension and leader lines. The arrow is

rendered so that the arrow tip occurs at the last point in the defining

set. Such a line has the following visual appearance:

This linetype is intended for use in engineering drawings .'

Additional Comments: requirements stated in ANSI Y14.2M-1979 shall be followed

when rendering this linetype

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered for use with computer graphics standards to enable

compact storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

67
This page left intentionally blank.

68
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: lznetypz

Name: single dot

Description: ^ single dot linetype consists of a solid line terminated by a dot

as specified in ANSI Y14.2M-1979 (Line Conventions and Lettering)

reqpairements for leader lines . The dot is rendered so that the dot occurs at the last point in the defining set. Such a line has the

following visual appearance: •

This linetype is intended for use in engineering drawings

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed when rendering this

linetype

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

69
This page left intentionally blank.

70
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

dale of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: linetype

Name: stitch line

Description: ^ stitch line linetype consists of dashes and spaces of equal length

as specified in ANSI Y14.2M-1979 (Line Conventions and Lettering.)

Such a line has the following visual appearance:

This linetype is intended for use in engineering drawings. Its definition

contains rendition requirements beyond those for the dashed linetype

already present in the graphics standards

Additional Comments: The requirements stated in ANSI Y14.2M-1979 shall be followed when

rendering this linetype. In some cases, it is necessary to exer- cise precise control over the manner in which two lines intersect

in a drawing. In these cases it may be appropriate to simulate

this linetype by using sequences of correctly placed individual

line segments

Justification for Inclusion in the Register:

This linetype is commonly used in engineering drawings. It is one of a set of

linetypes to be registered for use with computer graphics standards to enable

compact storage and transfer of engineering drawings

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in .5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

71
This page left intentionally blank.

72

/
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: lznetype

Name: user-specified dash pattern

Description:

The user-specified dash pattern linetype consists of alternating dashes and spaces

as specified in the current user-specified linetype. This linetype is intended

for use in high-quality graphical applications where the user of the standard

maintains precise control over the manner in which the linetype is rendered by

the use of individually specified attributes. Although its use is not precluded in

applications that choose to use bundled attributes, the intent of the user to

exercise a high degree of control over the rendition of graphical output will be

compromised, especially in metafile applications.

Additional Comments:

This registration proposal is accompanied by a proposal to register an escape function -Set Dash— for the CGM that defines the current user-specified linetype. It is

intended that these proposals be processed together.

Justification for Inclusion in the Register:

User specified linetypes are needed to support the requirements of office document

exchange and publishing. They are commonly found in widely available proprietary

graphics systems

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered linetype to supplement those

defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered linetype to supplement those

defined in 5.7.2.

73
This page left intentionally blank.

74
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: across grain wood

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of across grain wood in engineering

drawings. The intended visual representation of a filled-area element hatched in

this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

' Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings. It is one of a set of

hatchstyles registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized. ^

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5 4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24
This page left intentionally blank.

76
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstylz

Name: bronze, brass, copper, and compositions

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of bronze, brass, copper, and compositions

in engineering drawings. The intended visual representation of a filled-area

element hatched in this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchtypes registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.
This page left intentionally blank.

78
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: cast iron or malleable iron and general use for all materials

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of cast iron or malleable iron and general

use for all materials in engineering drawings. The intended visual representation

of a filled-area element hatched in this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype. These requirements are different from those for CGM linetype 3, which

requires only positive slope lines rather than 45 degree lines.

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24
This page left intentionally blank.

80
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: concrete

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of concrete sections in engineering drawings

The intended visual representation of a filled-area element hatched in this style

is illustrated below:

, .O' c

C> • 6 0 D

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype.

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings' is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined 'in 5.4.1.

2) ISO 8632 (COM) - Specifies a registered hatch style as defined in 5.7.24.

l

1

81
This page left intentionally blank.

82
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: corJc, felt, fabric, leather, and fibre

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of cork, felt, fabric, leather, and fibre in

engineering drawings. The intended visual representation of a filled-area element

hatched in this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed when rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings. It is one of a set of

hatchstyles registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.

83
This page left intentionally blank.

84
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstylb

Name: earth

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of earth sections in engineering drawings

The intended visual representation of a filled-area element hatched in this style

is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.

85
This page left intentionally blank.

86
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lO April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: magnesium, aluminum, and aluminum alloys

Description:

A hatchstyle conforming- to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of magnesium, aluminum, and aluminum alloys

in engineering drawings. The intended visual representation of a filled-area

element hatched in this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1,

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.

87
This page left intentionally blank.

88
I PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presemauon of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: marble/ slate, glass, porcelain, etc.

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of marble, slate, glass, porcelain, etc. in

engineering drawings. The intended visual representation of a filled-area element

hatched in this style is illustrated below;

Additional Comments:

//// // /. ///////.

y / y / , A

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is comm.only used in engineering drawings. It is one of a set of

hatchstyles registered for use with computer graphics standards to enable oom.pact

storage and transfer of engineering drawings. The need for a compact represe.ntaticn of the attributes of filled areas in engineering drawings is widely

recognized

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies

2) ISO 8632 (CGM) - Specifies

a registered hatch

a registered hatch

style as style as

defined in 5.4.1.

defined in 5.7.24.

89
This page left intentionally blank.

90
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

'Class of Graphical Item: hatchstyle

Name: roc)c

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of rock sections in engineering drawings

The intended visual representation of a filled-area element hatched in this style

is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.

91
This page left intentionally blank.

92
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstylz

Name: rubber, plastic, and electrical insulation

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of rubber, plastic, and electrical insulation

in engineering drawings. The intended visual representation of a filled-area

element hatched in this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings. It is one of a set o: hatchstyles registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (COM) - Specifies a registered hatch style as defined in 5.7.24.

93
This page left intentionally blank.

94
I PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: batchsttlz

Name: sand

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of sand sections in engineering drawings.

The intended visual representation of a filled-area element hatched in this style

is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14 . 2M-1979shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24,

95
This page left intentionally blank.

96
I

PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

1

I

I

I

I

Class of Graphical Item: batchsttle

Name: sound insulation

Description:

A.hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of sound insulation in engineering

drawings. The intended visual representation of a filled-area element hatched in

this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed inrendering this

linetype

,

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (COM) - Specifies a registered hatch style as defined in 5.7.24
This page left intentionally blank.

98
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: steel

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of steel sections in engineering drawings

The intended visual representation of a filled-area element hatched in this style

is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings. It is one of a set of

hatchstyles registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.

I

I

99
This page left intentionally blank.

100
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: thermal insulation

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of thermal insulation in engineering

drawings. The intended visual representation of a filled-area element hatched in

this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype.

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings. It is one of a set of

hatchstyles registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24
This page left intentionally blank.

102
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: titanium and refractory material

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of titanium and refractory material

in engineering drawings. The intended visual representation of a filled-area

element hatched in this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.
This page left intentionally blank.

104
I

Dlass of Graphical Item: hatchstyle

dame: water and other liquids

escription:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of water and other liquids in engineering

drawings. The intended visual representation of a filled-area element hatched in

this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 take precedence over those in this

! proposal in case of a conflict.

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings. It is one of a set of

hatchstyles registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

I recognized.

PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.
This page left intentionally blank.

106
proposal for registration of graphical item

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyle

Name: white metal, zinc, lead, babbitt, and alloys

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of white metal, zinc, lead, babbitt, and

alloys in engineering drawings. The intended visual representation of a filledarea element hatched in this style is illustrated below:

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 Shall be followed in rendering this

linetype. These requirements are different from those for CGM linetype 6, which

requires only positive and negative slope lines rather than

45 degree lines.

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered for use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a compact representation of the attributes of filled areas in engineering drawings is widely

recognized

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (CGM) - Specifies a registered hatch style as defined in 5.7.24.

I

I

I

107
This page left intentionally blank.

108
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal lo April 1987

sponsoring authority ANSI

Class of Graphical Item: hatchstyls

Name: with grain wood

Description:

A hatchstyle conforming to the requirements of ANSI Y14.2M-1979 (Line Conventions

and Lettering) for the representation of with grain wood in engineering

drawings. The intended visual representation of a filled-area element hatched in

this style is illustrated below;

Additional Comments:

The requirements stated in ANSI Y14.2M-1979 shall be followed in rendering this

linetype

Justification for Inclusion in the Register:

This hatchstyle is commonly used in engineering drawings . It is one of a set of

hatchstyles registered use with computer graphics standards to enable compact

storage and transfer of engineering drawings. The need for a ccm.pact representation of the attributes of filled areas in engineering drawings is widely

recognized.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered hatch style as defined in 5.4.1.

2) ISO 8632 (COM) - Specifies a registered hatch style as defined in 5.7.24.
This page left intentionally blank.

no
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: GDP

GDP Identifier: Bezier curve

Description:

A Bezier cubic section is generated using the four points specified. The curve

starts at the first point and ends at the fourth point; the second and third point

are used as control points . See the attached sheets for more details

Additional Comments:

The Bezier curve capabilities proposed here are adapted from those in the

PostScript language developed by Adobe Systems Incorporated.

Justification for Inclusion in the Register:

Bezier curves are needed to support the requirements of office document exchange

and publishing. They are commonly found in proprietary widely available graphics

systems

[Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered GDP as defined in 5.3.

2) ISO 8632 (CGM) - Specifies a registered GDP as defined in 5.6.10

3) ISO 8651^ (GKS Language Bindings) - Specifies a registered GDP.

(see attached sheets)

^At present at the stage of draft

The status of this relationship is

provisional until this standard has been approved by ISO council.

Ill
1) CGM Functional Specification (reference ISO 8632 COM;

Part 1: Functional Description)

Bezier curve adds a Bezier cubic curve between the first point,

referred to here as Y^) and the fourth point r,) , using

iXj, y,) and {X^fYp) as the Bezier cubic points.

The four points define the shape of the curve geometrically. The

curve starts at Yq) , it is tangent to the line from (X^, Y^) to

{X^, Y^) at that point, and it leaves the point in that direction.

The curve ends at (X^, Y^) , it is tangent to the line from ( x^, yp

to (Xjj, Yg) at that point, and it approaches the point from that

direction. The lengths of the lines (X^, Y^) to (X^, yp and

(X^, y^) to (X^, Y.j) represent in some sense the "velocity" of the

path at the endpoints. The curve is always entirely enclosed by the

convex quadrilateral defined by the four points.

The mathematical foundation of a Bezier cubic curve is derived from

a pair of parametric cubic equations;

x(t) = -h c^t +

y(t) = -h -h c^t + y.

The cubic section produced by Bezier curve is the path traced by

x(t) and y (t) as t ranges from 0 to 1 . The Bezier control points

corresponding to this curve are:

^2 = ^0 0

II •h c/3

X, = X, •h II -

1- (c -h b ) /3

y y

X3 = X, •h ‘=>. 0

II •h c,, + b./+ a

y y

112
A functional description of the Bezier curve generalized drawing

primitive parameters is:

Parameters

function identifier (I) as assigned by the Registration

Authority

point list (nP

)

data record (D)

Items for Data Record:

Integer IL 0

Integer RL 0

Integer SL 0

Data Record Description:

The data record is empty.

2) CGM Encodings (reference ISO 8632 CGM; Parts 2,3,4)

All encodings wilj. be handled in the same way - as a clear text

encoding (machine independent) of a FORTRAN-style packed data

record. This is treated as a string .type in each encoding and is

encoded according to the rules for string in that encoding.

113
This page left intentionally blank.

114
PROPOSAL FOR registration OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANS

Class of Graphical Item: GDP

GDP Identifier: conic arc

Description:

A bounded connected portion of a parent conic curve is generated in a definition

space and then transformed to world coordinates by the current conic arc transform-'

ation matrix. The intended realization of this output primitive is equivalent zo that intended for the Conic Arc Entity of IGES Version 3.0. See the attached

sheets for more .details

Additional Comments: None

Justification for Inclusion in the Register:

Conic arcs are needed to support the requirements of office document exchange,

publishing, and engineering drawing exchange. They are commonly found in

proprietary graphics systems. The conic arc capabilities proposed here are adopted

from the ANSI Y14.26 (IGES Version 3.0) specification.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered GDP as defined in 5.3.

2) ISO 8632 (CGM) - Specifies a registered GDP as defined in 5.6.10.

3) ISO 8651'' (GKS Language Bindings) - Specifies a registered GDP.

(see attached sheets)

*At present at the stage of draft. The status of this relatio.nship is

provisional until this standard has been approved by ISO council.

115
1) CGM Functional Specification (reference ISO 8632 CGM;

Part 1: Functional Description)

The conic arc is a realization of the Conic Arc Entity of the

IGES 3.0 standard. The attached extracts from the IGES Version 3.0

standard provide the functional specification.

A functional description of the conic arc parameters is:

Parameters

:

function identifier (I) as assigned by the Registration

Authority

point list(nP) - contains the two start and terminate points

data record (D) : - see the IGES attachments for definitions

A.

B

C

D

E

F

Note: The ZT value is not included since it must be zero.

Items for Data Record:

The following values are in the same order as in the IGES standard.

Integer IL 0

Integer RL 6

Real RA(1) A

Real RA(2) B

Real RA(3) C

Real RA(4) D

Real RA(5) E

Real RA(6) F

Integer SL 0

Data Record Description:

The parameters are as defined in the attached extract from the

IGES standard.

2) CGM Encodings (reference ISO 8632 CGM; Parts 2,3,4)

All encodings will be handled in the same way - as a clear text

encoding (machine independent) of a FORTRAN-style packed data

record. This is treated as a string type in each encoding and is

encoded according to the rules for string in that encoding.

116
104 . CONIC ARC

3.4 Conic Arc Entity

A conic arc is a bounded connected portion oi a parent conic curve which

consists of more than one point. The parent conic curve is either an ellipse, a

parabola, or a hyperbola. The definition space coordinate system is always

chosen so that the conic arc lies in a plane either coincident with or parallel to the XT, YT plane. Within such a plane, a conic is defined by the six

coefficients in the following equation.

A*XT^ B»XT*YT C*YT^ XT E»YT F « 0

3.4.1 Each coefficient is a real number. The definitions of ellipse, parabola, and

hyperbola in .terms of these six coefficients are given below.

3.4.2 A conic arc determines unique arc endpoints. A conic arc is defined within

definition space by the six coefficients above and the two endpoints. By

considering the conic arc endpoints to be enumerated and listed in an ordered

manner, start point fallowed by terminate point, a direction with respect to

definition *pace can be associated with the arc. In order for the desired

elliptical arc to be distinquished from its complementary elliptical arc, the

direction of the desired elliptical arc must be counterclockwise. In the case

of a parabola or hyperbola, the parameters given in the parameter data

section uniquely define a portion of the parabola or a portion of a branch of

the hyperbola; therefore, the concept of a counterclockwise direction is not

applied. (Refer to Section 3.1.2 for information concerning use of the term

" counterclockwise^ 0

3.4.3 The direction of the conic arc with respect to model space is determined by

the original direction of the arc within definition space, in conjunction with

the action of the transformation matrix on the arc.

116

117
10U . CONIC ARC

3. 4.3

The definitions of the terms ellipse, perabola, and hyperbola are given in terms

of the quantities Ql, Q2, and Q3. These quantities are

01 • detenniaam of

A M/2 D/2

M/2 C E/2

D/2 E/2 F

Q2 « dctcnniaaai of

A M/2

M/2 C

03 - ^ C

A parent conic curve is An ellipse if Q2X» and Ql * Q3<0.

A hyperbola if Q2<0 and Ql ^ 0. A parabola if Q2 « 0 and Ql i 0. An example of each type of conic arc is shown in Figure ^3.

3.4.6 Those entities which can be represented as various degenerate forms of a coruc

equation (Point and Line) must not be put into the Entity Type 104; more

appropriate Entity Types exist for these forms.

Because of the numerical sensitivity of the implicit form of the conic

description, a receiving system not using that form as its internal representation

for conics need not be expected to correctly process conics in this form unless

they are put into a standard position in definition space. A conic arc entity is said to be in a standard position in definition space provided each of its axes is parallel to either the XT axis or YT axis and provided it is centered about the ZT

axis. For a parabola, use the vertex as the origin. The conic is moved from this

position in definition space to the desired position in space with a transformation

matrix (Entity type 124).

The form number is regarded as purely informational by such a postprocessor.

Fvrther details may be found in Appendix E.

117

118
104 - CONIC ARC

118

119
10U - CONIC ARC

3.A.7 In the event that a parameterization is required but not given, the delauit

parameterization is:

Parabola

case A and £ / 0.0

if XI < X2

C(t) » (t, .(A/E)*f2, 2T)

where, for i « 1 and 2, ti « XI.

if X2 <X1

C(t) . (-t, -(A/E)^f2, 2T)

where, for i « 1 and 2, ti > -XI.

case C and D 0.0

if Yl < Y2

C(t) * (-»C/D)*f((2, t, ZT)

where, for i « 1 and 2, ti « Yi.

if Y2 < Yl

C(t) . (-(C/D)^f2, -t, ZT)

where, for i s 1 and 2, ti « -Yi.

for tl ^ t C t2

for tl 4 t 4 t2

for tl 4 t 4 t2

for 1 1 4 t 4 ^

Ellipse

C(t) * (a*cos t, b^sin t, ZT)

for tl 4 t 4 t2

where

a = sqrt(-F/A)

b * sqrt(-F/C)

and, for i 3 1 and 2, ti is such that

Q) (a*cos ti, b^sin ti, ZT) 3 (Xi, Yi, ZT)

an 0 4 tl 4 2«PI

Gu) 04 t2 - tl 4 2*P1

Hyperbola

case F*A < 0.0 and F*C > 0.0

a 3 sqrt<-F/A)

b 3 sqrt(F/C)

and, for i s 1,2

ti is such that

G) (a^sec ti, b^tan ti, ZT) 3 (Xi,Yi,ZT)

Gi) - Py2<tl,t2<PI/2

119

120
104 - COMIC ARC

. 3.4.S

if tl < X2

C(t) s (a*sec t, b^tan ZT) for 1 ^ t ^ t2

if t2<tl

C(t) * U*sec(-t), b^tan(-t), ZT) for -tl ^ t ^ -t2

case F*A > 0.0 and F*C < 0.0

let a * sqrt(F/A)

b « $qrt(-F/C)

and, for 1 s 1,2

ti is such that

a) (a^tan ti. b*sec ti. ZT) * (Xi.Yi.ZT)

Qi) - PI/2 <tl.t2 <PI/2

if tl<t2

C(t) s (a*ta:i t, b*sec t, ZT) for tl ^ t ^ t2

if t2 < ti

C(t) » (a*tan(-t). b*$ec(-t). ZT) for -ti ^ t ^-t2

Field 13 of the directory entry accommodates a Form Number. For this entity,

the options are as follows:

FORM Meaning

0 Form of parent conic curve must be determined from the general

equation.

1 Parent conic curve is an ellipse (See example 1. Figure S-3).

2 Parent conic cwve is a hyperbola (See example 2. Figure 3-3).

3 Parent conic ctrve is a parabola (See example 3. Figure S-3).

120

121
104 CONIC ARC

3.4.9 Directory Data

ENTITY TYPE NUMBER : 104

3.4.10 Parameter Data

II Name Ti2£. Oescriotion

1 A Real Conic Coefficient

2 B Real Conic Coefficient

3 C Real Conic Coefficient

4 D Real Conic Coefficient

3 E Real Conic Coefficient

6 F Real Conic Coefficient

7 ZT Real ZT Coordinate of

plane of definition

S XI Real Start Point Abscissa

9 Y1 Real Start Point Ordinate

10 X2 Real Terminate Point

Abscissa

11 Y2 Real Terminate Point

Ordinate

Additional Pointers as required (see 2«2.4.4.2).

121

122
APPENDIX E - CONIC APCS

APPENDIX E

CONIC ARCS

Conic arcs as specified by the ICES standard are extremely sensitive to the data in two distinct ways:

(a) Accvracy

It is numerically sensitive; small changes in the coefficients can cause

large changes in the locations of the points satisfying the conic equation.

(b) Stability

The determination of the conic type depends upon whether certain

invariants are positive, zero or negative. Working in floating point

arithmetic, a machine value of 0.0 is vmlikely to be encomtered.

Furthermore, small changes in coefficient values can easily result in

positive values when negative ones are intended and conversely.

It is assumed that data is put into a conic arc entity with the intent of preserving

the geometric properties of the data (major and minor semi-axes, asymptotes,

directrices, etc.) in addition to describing the points on the curve.

If the geometric properties are desired, the 104 entity should be used as described

below.

This method primarily adck’esses the stability problem, though the accuracy of the

conic should improve because the range of coefficient values will decrease. While

the geometric properties are not explicitly defined in this representation, they can

be obtained from it in a direct and arithmetically stable manner.

If both the sending and intended receiving system are known to use the A-F form of

the 104 entity (Conic Arc) in their own databases the preprocessor may put the data

into in the unchanged form. This minimizes the loss of information caused by

truncation and roundoff errors as no changes are made to the data. The stability

problem is presumably not of concern in this case.

ui^

123
APPENDIX E - CONIC ARCS

(1) Here is one suggested set of values:

Ellipse

A :=AXISY2

C :sAXISX2

E:s 0

B:s 0

0:s 0

F -A*C

where AXISY and AXISX are the lengths of the major and minor semiaxes (not necessarily in order).

(2) Hyperbola

A :a - AXISY2 (or AXISY2) B 0

C :a AXISX 2 (or - AXISX2, if A 0) D :» 0

E :s 0 F :» -A*C.

where AXISY and AXISX are the lengths of the major and minor semiaxes (not necessarily in order).

(3) Parabola

A 0 (or 1 ) B :a 0

C :« 1 (or 0, if A . 1) D :» ^DIST

(or 0, if A a 1) E :a 0 (or %^DIST, if A « 1) F :a 0

where OIST is the distance of the vertex from the focus.

Preprocessor Conic Handling

The conic arc must be put into standard form* parallel to the X and/or Y axis(axes)

and centered about the origin. An 124 transformation matrix must be used to move

the conic arc into its desired position in space. In this form the coefficients in the

format that should be 0.0 will be exactly so. In particular, for the ellipse and

hyperbola B, 0« and E must be 0.0, and for the parabola B and F and either A and E

or C and 0 must be 0.0. Determination of the conic type from the equations becomes straight forward for

the postprocessor.

For further mathematical details, see (THOM60).

480

124
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM 19S* date of presenauon of proposal 1C April *7

sponsoring authority ANSI

Class of Graphical Item: GDP

GDP Identifier: parametric spline curve

Description:

A planar (two dim.ensional) ’ parametric spline curve is generated. The intended

realization of this output primitive is equivalent to that intended for the

Parametric Spline Curve Entity of ANSI Y14.26 (IGES Version 3.0), with the

restriction that the "Z polynomial" of the IGES standard be zero. See the

attached sheets for more details.

.Additional Comments: None

Justification for Inclusion in the Register:

Parametric spline curves are needed to support the requirements of engineering

drawing exc.hange . They are commonly found in proprietary graphics systems.

Relationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered GOP as

Z) ISO S632 'ZZIO - Specifies a registered GO? as

3) ISO 8651* (GKS Language Bindings) - Specifies a (see attac.hed sheets) .

defined in 5.3.

defined in 5 . 6 . 1C

registered GOP

*At present at the stage of draft . The status of this relat io.nship is

provisio.nal until this standard has been approved by ISC council.

125
1) CGM Functional Spacification (reference ISO 8632 CGM;

Part 1 Functional Description)

The paramatric splina curva is a realization of the Para.T.etrzc

Spline Curve Entity of the IGES 3.0 standard, restricted to the

two-dinens ional environment of the CGM. The attached extracts frcr - the IGES Version 3.0 standard provide the functional specif icaticn

.

A functional description of the parametric spline curve parameters

is : Parameters

:

function identifier (I) as assigned by the Registration

Authority

point list(nP) - contains the "T” values

data • record (D)

:

- see the IGES attachments for definitions

CTYPE

H

N

AX

AY

TPX

TPY

Items for Data Record:

If VDC TYPE integer was selected (Warning; parametric splines

should not be expected to work well in this case)

:

The following values are in the same order as in the IGES standard

with the Z values ommitted.

Integer IL 3 + 9N

Integer IA(1) CTYPE

Integer IA(2) H

Integer IA(3) N

Integer IA(5) T(l)

Integer lA (5+N) T (N+1)

Integer IA(5+N+1) AX(1)

Integer RL 0

Integer SL 0

126
112 - PARAMETRIC SPLINE CURVE

3.S Parametric Spline Curre Entity

(Consult Appendix 0 for additional mathematical details)

The parametric spline cirve is a sequence of parametric polynomial segments.

The CTYPE value in Parameter 1 indicates the type of curve as it was

represented in the sending (pre-processing) system before conversion to this

entity.

3.5.1 The N polynomial segments are delimited by the breakpoints T(l), T(2),

..mT(N<^ 1). The coordinates of the points in the i-th segment of the cirve are

given by the following cubic polynomials (the coefficients 0» or C and D will be

zero if the polynomials are of degrees 2 or 1, respectively):

cr(/) V

nu)m4 ru)^Bru) it-*- cru) v

Z{u)»A2U)'¥BZU) •t’^CZU) •t^DZU) V

wtaeie

In order to avoid degeneracy, for each i at least one of the nine real coefficients,

BX(i), CX(i), OX(i), BY(i), CY(i), OYG), BZ(i), CZ(i), and OZ(i) must be nofvzero.

3.5.2 If the spline is planar, it must be parametrized in terms of the X and Y

polynomials only. The Z polynomial will then be zero except for each i, the AZ(i)

term which indicates the Z-depth in definition space.

3.5.3 The parameter H is used as an indicator of the smoothness of the curve. If HsO,

the curve is continuous at all breakpoints. If Hal, the curve is continuous and

has slope continuity (see section 6.3 of FAUX79) at all breakpoints. If Ha2, the curve is continuous and has both slope and curvature continuity at all breakpoints

(see section 6.3 of Faux79).

132

127
If VDC TY-PE rea-1 was selected:

Integer IL 3

Integer IA(1) CTYPE

Integer IA(2) H

Integer IA(3) N

Integer RL lON+1

Real RA(1) T(l)

Real RA(N+1) T(N+1)

Real RA(N+2) AX(1)

Real RA(N+3) BX(1)

Integer SL 0

Data Record Description:

The parameters are as defined in the attached extract from the

IGES standard.

2) CGM Encodings (reference ISO 8632 CGM; Parts 2,3,4)

All encodings will be handled in the same way - as a clear text

encoding (machine independent) of a FORTRAN-style packed data

record. This is treated as a string type in each encoding and is

encoded according to the rules for string in that encoding.

128
112 - PARAMETRIC SPLINE

3.S.4 To enable determination of the terminate point and derivatives without

computing the polynomialSt the Nth polynomials and their derivatives are evaluated at u s T(N<»1). These data are divided by appropriate factorials and

stored following the polynomial coefficients. For example, the name TPY3 will be used to designate 1/3! times the third derivative of the Y polynomial for the

Nth segment evaluated at u«T(N^l), the parameter value corresponding to the

terminate point. Note that these data are redundant as they are derived from

the data defining the Nth polynomial segment.

3.S.3 An example of a parametric spline is shown in Figire V7. Additional examples

are shown in Figure 3-S.

3.S.6 Directory Data

ENTITY TYPE NUMBER : 112

3.S.7 Parameter Data

Index

1

Name

CTYPE

NDIM

N

Integer

Integer

Integer

Integer

Description

Spline Type

(IsLinear

23Quadratic

3sCubic

AaWilson-Fowler

3sModfied

WilsocwFowler

6s8 Spline)

Degree of continuity with

respect to arc

length

2splanar

3snon-planar

Number of segments

T(l) Real Break points of

piecewise

polynomial

5-N T(N-^l)

133

129
CURVE

'(

X(U).

V(U),

Z(U)

).

FOR

T(l)

$U

^

T(N»1)

N

-3

SEGMENTS

112 - PARAMETRIC SPLINE CURVE

w w S

I V *T

m • m ^

«N <N <M

CM

II

A ^ ^

^ — CN ^ * R

* « * |h> ^ ^ ^ — <N

^

^ ^ ? S < < < a. >

« * * M"> —WWW<N

N — <N

II II H R OO

QS

Q. a. a. a. u.

^ ^ ^ ^

21

S S S

H* H* H»

I I I • • • s s s

X >• i<*g ^

^

CM CN e*M ^

h* N»

I I I WWW • • c ^

CM CM CM

<w sa sn s^a

335o2 «

***

^ a uj

^ ^

CM CM CM

1 333

— n R R

UJ

I X§ii^

1^

c/9 su.

134

130

FIGURE

3-7

EXAMPLE

OF

THE

PARAMETRIC

SPLINE

CURVE

ENTITY
112 - PARAMtiaiC SPLIN

n

lU *

-J s

Q. ^ < 3 X

• u

135

131

FIG.

3-8

EXAMPLES

OF

PARAMETRIC

SPLINE

CURVE

DfTITY
112 - PARAMETRIC SPLINE CURVE

Index Name Type Descriotion

6>»N AX(1) Real X coordinate

polynomial

7>N BX(1)

S<^N CX(1)

DX(1)

10-fN AYU) Y coordinate

U^N BY(1) polynomial

124.N CY(1)

13-^N DY(1)

A2(l) Z coordinate

13^N BZ(l) polynomial

CZ(1)

17^N OZ(l)

. Subsequent X, Y, Z

. polynomials concluding

with the twelve

coefficients of the Nth

polynomial segment.

e

(The parameters that follow comprise the evaluations of the polynomials of the Nth

segment and their derivatives at the parameter value usT(N<^l) corresponding to the

terminate point. Subsequently these evaluations are divided by appropriate factorials.)

136

132
112 - PARAMETRIC SPLINE CURVE

6^13*N TPXO Real X value

TPXl X first derivative

TPX2 X second derivative/2!

TPX3 X third derivative/3!

TPYO Y value

TPYl

TPY2

TPY3

TPZO Z value

TP21

TPZ2

TPZ3

Additional Pointers as required (see 2,2AA,2)

Software to convert between parametric spline curves or surfaces and the corresponding

rational B-spline curves or surfaces is available from the ICES office at the National

Bureau of Standards. Materials provided include a magnetic tape of Pascal source code, a

listing of the code, and accompanying documentation.

137

133
This page left intentionally blank.

134
I

,

j PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal 10 April 1987

sponsoring authority ANSI

Class of Graphical Item: GDP

GDP Identifier: rational B-spline curve

Description:

A planar (two dimensional) rational B-spline curve is drawn. The intended

I realization of this output primitive is equivalent to that intended for the

I Rational B-Spline Curve Entity of ANSI Y14.26 (IGES Version 3.0)/ with the

restriction that the "Z polynomial" of the IGES standard be zero. See the

attached sheets for more details.

Additional Comments: None

[Justification for Inclusion in the Register:

I Rational B-spline curves are needed to support the requirements of engineering

drawing exc.hange. They are commonly found in proprietary graphics systems.

elationship to Particular Standards:

1) ISO 7942 (GKS) - Specifies a registered GDP as defined in 5.3.

2) ISO 8632 (CGM) - Specifies a registered GDP as defined in 5.6.10.

3) ISO 8651^ (GKS Language Bindings) - Specifies a registered GDP.

(see attached sheets) .

*At present at the stage of draft. The status of this relationship is

provisional until this standard has been approved by ISO council.

I

135
1) CGM Functional Specification (reference ISO 8632 CGM;

Part 1: Functional Description) •

The rational B-spline curve is a realization of the rational

B“spline curve Entity of the IGES 3.0 standard. The attached

extracts from the IGES Version 3.0 standard provide the functional

specification

.

A functional description of the rational B-spline parameters is:

Parameters

:

function identifier (I) as assigned by the Registration

Authority

point list(nP) - contains the control points

data record (D)

:

- see the IGES attachments for definitionsK

M

PROP 2

PROP 3

PROP 4

T

W

NORM

Note: The PROPl value is not included since it must be 1.

Items for Data Record:

The following values are in the same order as in the IGES standard.

Integer IL

Integer IA(1)

Integer IA(2)

Integer IA(3)

Integer IA(4)

Integer IA(5)

Integer RL

Real RA(1)

Real RA(1+A)

Real RA(2+A+K)

Real RA(3+A+K)

Integer SL

5

K

M

PROP 2

PROP 3

PROP 4

see IGES extract

T(-M)

W(0)

XNORM

YNORM

0

Data Record Description:

The parameters are as defined in the attached extract from the

IGES standard.

136
2) CGM Encodings (r.eference ISO 8 632 CGM; Parts 2,3,4)

All encodings will be handled in the same way - as a clear

encoding (machine independent) of a FORTRAN-style packed

record. This is treated as a string type in each encoding and is

encoded according to the rules for string in that encoding.

137

n.

ft
126 - RATIONAL B SPLINE C'JHVE

3.16 Rational Spline Cvrve Entity

The rational B-spline curve may represent analytic curves o£ general interest.

This information is important to both the sending and receiving systems. The

directory entry form number parameter is provided to commimicate this information. It should be emphasized that use of this curve form should be

restricted to communications between systems operating directly on rational ^

spline curves and not used as a replacement for the analytic forms for

commifiication. For a brief description of a rational B>spUne curves, see Section

% of Appendix D.

If the rational B*spline cirve represents a preferred ctrve type, the form nianber

corresponds to the most preferred type. The preference order is from 1 through

5 followed by 0. For example. If the cvrve is a circle or circular arc, the form

number is set to 2. If the c;rve is an ellipse with vjiequal major and minor axis

lengths, the form nianber is set to 3. If the cirve Is not one of the preferred

types, the form number is set to 0.

If the curve ties entirely within a tmique plane, the planar flag (PROPl) is set to

1, otherwise it is set to 0. If it is set to I, the plane normal (parameters

U^A^4K through I6^A^4K) contain a cnit vector normal to the plane containing

the curve. These fields exist but are Ignored if the curve Is nofvplanar.

169

138
126 - RATIONAL B SPLINE CURVE

If the be^nning and ending points on the curve are identical* PROP2 is set to 1.

li they are not equal* PROP2 is set to 0.

If the curve is rational (does not have all weights equal)* PROP3 is set to 0. If all weights are equal to each other* the curve is polynomial and PROP3 is set to

1. The curve is polynomial since in this case all weights cancel and the

denominator sums to one (see Appendix Oa).

If the ctjrve is periodic with respect to its parametric variable, set PROP4 to 1, otherwise set PROPa to 0.

3.16.1 Directory Data

ENTITY TYPE NUMBER: 126

Form Meaning

0 Form of cxrve must

parameters.

1 Line

2 Crcuiar arc

3 Elliptical arc

a Parabolic arc

5 Hyperbolic arc

>16.2 Parameter Data

be determined from the rational &-spline

Index Name Description

1 K Integer Upper index of sum. See

Appendix D

2 M Integer Degree of basis

functions

3 PROPl Integer :0 - norvplanar

si - planar

a PROP2 Integer

/ sO - open curve

si - closed curve

5 PROP3 Integer sO - rational

si . polynomial

6

Let NsK-M<

PROPa

1 and let AaN^2M

Integer sO - nonperiodic

si - periodic

170

139
126 - RATIONAL B SPLINE .A'

7 T(-M) Real Knot Sequence

•

•

•

T(N-rM)

UA

e

W(0)

•

Real Weights

•

•

S-»A>K

•

• W(K)

9^A^K XO Real Control Points

l0i.Ai>K YO

lUA^K

e

ZO

•

• • XK

104>A>4K YK

1UA<»>9K zx

12^A^4K V(0) Real Starting parameter value

13^A^9K V(l) Real Ending parameter value

XNORM Real Unit Normal Qf curve is planar)

134.A-T4K YNORM

164.A<t4K ZNORM

Additional Pointers as required (see 2.1.4.4.2).

Software to convert between parametric spline curves or surfaces and the corresponding

rational B-spiine curves or surfaces Is available from the ICES office at the National

Bureau of Standards. Materials provided include a magnetic tape of Pascal source code, a

listing of the code, and accompanying documentation.

171

140
APP£MDIX D - SPLINE RE? PESENTATICNS

D4 RATIONAL B-SPLINE CURVES

The comments in this section pertain primarily to section 3.16.

A rationai B-spiine ojrve is expressed parametrically in the form

K

2 *0)PC)bj(t)

K

1.0

where the notation is interpreted as follows.

The W(i) are the weights (non-zero real numbers).

The P(i) are the control points (points in r\

472

141
APPENDIX D - SPLINE REPSESENTA r: INS

The b. are the B-spline basts functions. These are defined as soon as their

degree^ M, and underlying knot sequence^ T, are specified.

This is done as follows:

Let N a K - M < I, Then, the knot sequence consists of the non-decreasing

.set of real numbersj T(—W), •••, T(0), T(N), •••, T(N^M)

The OiTve itself is parametrized for V(0)<t4V(l) where

T(0)4V(0)^V(1)4T(N).

The ^spline basis functions b. are each norvnegative piecewise polynomials

of degree M. The function bj is supported by the interval ir(/-A/), r(/^l)l.

Between any two adjacent knot values T(j), T(j4>l) the function can be

expressed as a single polynomial of degree M.

For any parameter value t between T(0) and T(N) the basis functions satisfy

the identity

K

2 V*’ • *• 1>0

If the weights are all positive, the arve C(t) is contained within the convex

hull of its control points.

There are a number of ways to precisely define the B-spUne basis functions.

A recursive approach proceeds as follows.

Let denote the &-$pline basis function of degree m

supported by the interval

With this notation, the degree 0 functions are simply characteristic functions

of a half-open interval.

Nit

I e.5) •

1 if a<r<»

0

otherwise

473

142
APPENDIX 0 - SPLINE REP RESENTATIONS

The degree k functions are defined in terms of those of degree k-1.

lip, i»-i) ^

(s^~t)NU |si x»)

Xt-J - Xo »\

Since some of the denominators will be 0 in the case of multiple knots, the

convention 0/0 « 0 is adopted in the above definition.

Rational Bezier curves (and surfaces) can be expressed exactly as rational &-

spline curves (and surfaces). (BLOMS2).

Software to convert between parametric spline curves or surfaces and the

corresponding rational B-spline curves or surfaces is available from the IGE5

office at the (National Bureau of Standards. Materials provided include a magnetic tape of Pascal source code, a listing of the code, and accompanying

documentation.

474

143
This page left intentionally blank.

144
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal jq

sponsoring authority

Class of Graphical Item: ESCAPE

{Specific Escape Function Identifier: Set Conic Arc Transformation Matrix

Description:

This escape function sets a value of the transformation matrix needed to

describe how a conic arc described by the conic arc GDP is moved from "definition space" to world coordinates (called "model space" in the IGES standard.)

It is modelled on the Transformation Matrix Entity of the ANSI Y14.26 (IGES

version 3.0) specification. See attached sheets for additional details.

Additional Comments:

None

JustiFication for Inclusion in the Register:

Conic arcs are needed to support the requirements of engineering drawing exchange.

They are commonly found in proprietary graphics systems. Due to various numerical

problems, such curves are best specified in a "definition space" and then transformed to their final location by applying a transformation matrix. This escape

function is needed to supply values for the required "modelling" or transformation

matrix.

Relationship to Particular Standards:

1) ISO 8632 (CGM) - Specifies a registered escape as defined in 5.8.1.

2) See attached sheets.

I

1

r
1) CGM Functional Spacification (reference ISO 8632 CGM;

Part 1: Functional Description)

Set Conic Arc Transformation Matrix is a realization of the

Transformation Matrix Entity of the IGES 3.0 standard, restricted

to the two-dimensional environment of the CGM. This matrix is a component of the graphics state and determines how subsequent conic

arc output primitives are transformed from definition space to

virtual device coordinates. The attached extracts from the IGES

Version 3.0 standard provide the functional specification.

A functional description of the Set Conic Arc Transformation

Matrix escape parameters is:

Parameters

:

function identifier (I) as assigned by the Registration

Authority

data record (D) : - see the IGES attachments for definitions

Rll

Ri2

R21

R22

Items for Data Record:

If VDC TYPE integer was selected (Warning: conic arcs should

not be expected to work well in this case)

:

Integer IL 6

Integer IA(1) ^11

Integer IA(2) Ri2

Integer IA(3) R21

Integer IA(4) R22

Integer IA(5) Tl

Integer IA(6) T2

Integer RL 0

Integer SL 0

If VDC TYPE real was selected:

Integer IL

Integer RL

Real RA(1)

Real RA(2)

Real RA(3)

Real RA(4)

Real RA(5)

Real RA(6)

Integer SL

0

6

^11

Ri2

^21

^22

Tl

T2

0

146
Data Record Description:

The parameters are as defined in the attached extract from the

ANSI Y14.26 (IGES version 3.0) standard.

2) CGM Encodings (reference ISO 8632 CGM; Parts 2,3,4)

All encodings will be handled in the same way - as a clear text

encoding (machine independent) of a FORTPAN-style packed- data

record. This is treated as a string type in each encoding and is

encoded according to the rules for string in that encoding.

147
12U - TRANSFORMATION MATRIX

3.14

3.14.1

Transformation Matrix Entity

The Transformation Matrix entity transforms three-row column vectors by means of a matrix multiplication and then a vector addition. The notation for

this transformation is

’RIIR12R13" "XINPUT* Tf 'xoutput"

R21 R22 R23 YINPUT T2 3 YOUTPUT

.R31 R32 R33. ZINPUT Ji. .ZOUTPUT,

Here, col [xiNPUT, YINPUT, ZlNPUTj G.e., the column vector) is the vector being

transformed, and col ^XOUTPUT, YOUTPUT, ZOUTPUlj is the column vector resulting

from this transformation. R s

^RjjJ is a 3 row by 3 column matrix of real numbers,

and Tscol ^Tl,T2,T3j is a three-row column vector of real numbers. Thus, 12 real

numbers are required for a Transformation Matrix entity. This entity can be

considered to be an **operator" entity in that it starts with the input vector,

operates on it as described above, and produces the output vector.

Frequently, the input vector lists the coordinates of some point in one coordinate

system, and the output vector lists the coordinates of that same point in a second coordinate system. The matrix R and the translation vector T then

express a general relationship between the two coordinate systems. By

considerating special input vectors such as col ^1,0,oj, col ^0,1,oj, and col[o,0,lj

and computing the corresponding output results, a geometric appreciation of the

spatial relationship betwem the two coordinate system can be gained.

For example, for

0 0 1 r ^

0

R s 0 1 0 T . 0

-10 0 b 4 .0.

158

148
124 - transformation matrix

the spatial relationship of the input and output cordinate systems is the

following:

2OUTPUT

All coordinate systems are assumed to be orthogonal, cartesian, and right-handed

vailess spedficaliy noted otherwise.

3.14.2 Following are three specific areas where the Transformation Matrix entity is used to transform coordinates between coordinate systems. Each example area

illustrates a specific choice of input and output coordinate system. Other

choices of coordinate systems may be appropriate in other application areas.

The usual situation for this type of use of the Transformation Matrix entity is when the input vector refers to the definition space coordinate system for. a

certain entity, and the output vector refers to the model space coordinate

system. (See Sect. 3.1.1) In this case, the matrix R is referred to as the defining

matrix, and the Transformation Matrix entity defining R and T is pointed to in field seven (transformation matrix field) of the directory entry of the entity.

(See Sect. 2«2.4.3.7) In this use of the Transformation Matrix entity, the matrix

R is subject to the restrictions given in Form 0 and Form 1 below.

159

149
124 - TRANSFORMATION MATRIX

A second situation is the case when the input vector refers to the model space

coordinate system and the output vector refers to a viewing coordinate system.

In this case, the matrix R is referred to as a view matrix, and is subject to the

restrictions given in Form 0 below. Note that when a planar entity is viewed at true length G.e., the viewing plane is parallel to the plane containing the entity)

then the rotation matrix pointed to by OE Field 7 of the planar entity will be the

inverse (smatrix transpose) of the matrix pointed to by OE Field 7 of the View

entity. (See Sect. 4.3.11)

A third situation involves finite element modeling applications. Here, it may be

the case that an input coordinate system is related to an output coordinate

system by a particular R and T, and, in turn, the output coordinate system is then taken as an input coordinate system for a second R and T combination, and

so on. These coordinate systems are frequently called local coordinate systems.

Model space is frequently called the reference system. For example, the

location of a finite element node may be given in one local coordinate system,

whi^ may serve as the input coordinate system for a second local coordinate

system, which in turn serves as the input coordinate system for the model space

coordinate system which is the reference system. Allowable forms of the matrix

R for these applications are detailed in Forms 10, 11, and 12 below.

3.14.3 Whenever coordinate systems are related successively to each other as described

above, a basic result is that the combined effect of the individual coordinate

system changes can be expressed in terms of a single matrix R and a single

translation vector T. For example, if the coordinate system change involving the

matrix R2 and the translation vector T2 is to be applied following the coordinate

system change involving the matrix R1 and the translation vector Tl, then the

matrix R and the translation vector T expressing the combined changes are R=(R2) (Rl) and T * (R2) (Tl) T2.

Here, (R2) (Rl) denotes matrix multiplication of 3x3 matrices, where

multiplication order is important. The matrix R and the translation vector T are computed similarly whenever more than two coordinate system changes are to be

applied successively.

160

150
124 - transformation matrix

Successive coordinate system changes are specified by allowing a Transformation

Matrix entity to reference another Transformation Matrix entity through Field 7 of the Directory Entry. In the example above, the Transformation Matrix entity

containing R1 and T1 would contain in its Directory Entry Field 7 a pointer to the Transformation Matrix entity containing R2 and T2. The general rule is that

Transformation Matrix entities applied earlier in a succession will reference

Transformation Matrix entities applied later. Note that the matrix product

(R2) (Rl) in the example above does not appear explicitly in the data, but. If needed, must be computed according to the usual rules of matrix multiplication.

A second example of coordinate systems being related successively (or

**concatenatetf*, or "stacked), in addition to the finite element example

mentioned above, involves one manner of locating into model space a conic arc

that is in standard position in definition space. In this case, Rl and T1 move the

conic are from its standard position to an arbitrary location in any plane in definition space satisfying ZTaconstant. (Therefore, RI 33SIU),

Rl3l«Rl32«Rli3s Rl23«0.0. Tl can be an arbitrary translation vector.) R2 and

T2 then position the relocated conic arc into model space. (R2 can be an

arbitrary defining matrix and T2 can be an arbitrary translation vector.) Note

that for Rl and Tl, both the input vector and the output vector refer to the same coordinate system, namely, the definition space for the conic arc.

3.U.a A 3x3 matrix R Is called orthogonal provided its transpose, R^, about the main

diagonal yields a matrix inverse for R. The columns of an orthogonal matrix

considered as vectors form an orthogonal collection of unit vectors. As (R^^sR,

the transpose of an orthogonal matrix is again an orthogonal matrix. The

determinant of an orthogonal matrix is equal to either plus one or minus one. In the event R is an orthogonal matrix with determinant equal to positive one, R

can be expressed as a rotation about an axis passing through the origin. In this

event, R is referred to as a rotation matrix. In the event R is an orthogonal

matrix with determinant equal to negative one, R can be expressed as a rotation

about an axis passing through the origin followed by a reflection about a plane

passing through the origin perpendicular to the axis of rotation.

161

151
124 - TRANSFORMATION MATRIX

3.14.3 Allowable Form Numbers. The defining matrix of an entity must use either

Form zero or Form one. A defining matrix associated with a view entity must

use Form zero.

Form 0: (default) R is an orthogonal matrix with determinant equal to positive one. T is arbitrary. The columns of R taken in order form a right-handed triple

in the output coordinate system.

Form 1: R is an orthogonal matrix with determinant equal to negative one. T is arbitrary. The columns of R taken in order form a left-handed triple in the

output coordinate system.

3.14.6 Forms 10, 11, 12. These form numbers indicate special matrices used in conjifiction with th" node entity (type number 134).

Form 10s This form number conveys special information when used in conjunction with the Node entity (type number 134) in Finite Element

Applications.

Refer to Fig. 3- 17(a) for notation. The matrix R and the vector T are used to transform coordinate data from the ul,u2,u3 coordinate

system to the x,y,z local system.

The ul,u2,u3 coordinate system has its origin at an arbitrary fixed

point col XOFF5ET, YOFFSET, ZOFFSET in the x,y,z coordinate

system and is assumed to be displaced parallel to that reference

coordinate system. Thus,

’l 0 o' ' XOFFSET

R 3 0 1 0 , T 3 YOFFSET

.0 0 1, . ZOFFSET

,

162

152
12U - TRANSr CRMATIGN MATRIX

Z

Figure 3-17 Displacement Components

163

153
124 - TRANSFORMATION MATRIX

Form 11:

so that

’l 0 o"

0 ^ ul ' XOFFSET" ’xlocal'

0 1 0 u2 YOFFSET s YLOCAL

.0 0 1, .ZOFFSET, .ZLOCAL.

Note that the orientation of the two coordinate systems can be

described by saying that the ul,u2,u3 coordinate system is the

system obtained by imposing orthogonal curvilinear coordinates

onto the x,y,z space and then constructing unit tangent vectors to the three curvilinear coordinate curves at the given fixed point to serve as basis vectors. In this special case of parallel

displacement, the curvilinear coordinates imposed are identical to the existing x,y,z coordinates.

This form number conveys special information when used in conjuiction with the Node entity (type number 134) in Finite

Element applications.

Refer Figure 3- 17(b) for notation. The matrix R and the vector

T are used to transform coordinate data from the ul, u2, u3

coordinate system to the x,y,z local system.

The ul, u2, u3 coordinate system has its origin at an arbitrary fixed

point

XOFFSET . ro cos Qo ro 0

YOFFSET . ro sin Oo 0 0© 360®

ZOFFSET * Zq -oo<z^ < oO

for rgsO, take OsO^

in die x,y,z coordinate system. The ul,u2,u3 system is the system

obtained by imposing orthogonal curvilinear coordinates onto the

x,y,z space which are the cylindrical coordinates (r,0,z) with

X 3 r cos 0

y 3 r sin 0

Z 3 z.

164

154
124 - transformation matrix

and then constructing unit tangent vectors to the three curvilinear

coordinate curves at the given fixed point to serve as basis vectors.

Thus, the relationship between the ul, u2, u3 and the x,y,z local

coordinate system is given by

cosOq -sinOo 0 *ul'

’ XOFFSET* 'XLOCAL*

sinOo cosOq 0 u2 YOFFSET a YLOCAL

o o I. .u3 .ZOFFSET, .ZLOCAL,

Form 12: This form number conveys special information when used in conjunction with the Node entity (type niimber 134) in Finite

Element applications.

Refer to Fig. 3- 17(c) for notation. The matrix R and the vector T

are used to transform coordinate data from the ul, u2, u3

coordinate system to the x,y,z local system.

The ul, u2, u3 coordinate system has its origin at an arbitrary fixed

point

XOFFSET « r<,sin Oq sin #o

YOFF5ET * r^sin 0^ cos #o

20FFSET « rocos Qo

for ro = 0, take 0^ a a 0®

for Oq a QO or ISO^, take 0q

a 0^

in the x,y,z coordinate system. The ul, u2, u3 system is the system

obtained by imposing orthogonal curvilinear coordinates onto the

x,y ,2 space which are the spherical coordinates (r, 0, 0) with

X a r sin 0 cos 0

Y a r sin 0 sin 0

Z s r cos 0

ro^O

040o4180O

O<0o<36OO

165

155
124 - TaANSFORMAIION MATRIX

and then constructing unit tangent vectors to the three curvUinear

coordinate curves at the given fixed point to serve as basis vectors.

Thus, the relationship between the ul, u2, u3 and the x,y,z local

coordinate systems is given by

sinOo cos#o cosOq COS#o -sin0Q ul m m XOFFSET XLOCAL

sinOQ sin#o COSOq sin0o COS0O u2 YOFFSET a YLOCAL

cosOq -sinOo 0 u3

m m 20FFSET

m « 2LOCAL

• m

See, Kaplan, (KAPL32) or Hildebrand, (HIL076) for a disoasion of orthogonal

ctirvUinear coordinate systems.

3.14.7 Directory Data

ENTITY TYPE NUMBER: 124

3.14.S Parameter Data

Index Name Type Description

1 Rll Real Top Row

2 R12 Real

3 R13 Real

4 Tl Real

3 R21 Real Second Row

6 R22 Real

7 R23 Real

S T2 Real

9 R31 Real Third Row

10 R32 Real

11 R33 Real

12 T3 Real

Additional Pointers as required (see 2.2.4.4.2).

166

156
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal jq ^93-7

sponsoring authority ^NS

'lass of Graphical Item: ESCAPE

pecific Escape Function Identifier: Set Dash

description:

This escape function sets a value for the user-specified dash pattern (registered)

linetype. This pattern is used during subsequent interpretation of graphical

primitives that use linetype attributes. See attached sheets for additional

details

additional Comments:

The line type capability proposed here is adapted from those in the PostScript

language developed by Adobe Systems Incorporated.

ustification for Inclusion in the Register:

The Set Dash function is needed to support the user-specified dash pattern

linetype. This linetype is needed to support the requirements of office document

exchange and publishing. Similiar capabilities are commonly found in widely

available proprietary graphics systems.

Relationship to Particular Standards:

1) ISO 8632 (CGM) - Specifies a registered escape as defined in 5.8.1.

2) See attached sheets.

157
1) CGM Functional Spacification (reference ISO 8632 CGM;

Part 1: Functional Description)

Set Dash sets a dash pattern state value in the graphics state,

controlling the dash pattern used during subsequent interpretation

of graphics primitives that are drawn with the registered linetype

value of "user-specified dash pattern" (linetype TBD) . If the array

of dash pattern lengths is empty (i.e, the number cf lengths is

zero) , the linetype is equivalent to solid. If array of dash

pattern lengths is not empty, the affected primitives are drawn

with dashed lines whose pattern is given by the elements of the

array, which must be non-negative numbers and not all zero.

The elements of the array of dash pattern lengths are interpreted

in sequence as distances in VDC units along the path of the

primitive. These distances alternately specify the length of a gap

between dashes. The contents of the array are used cyclically. When

the end of the array is reached, the pattern starts over at the

beginning

.

Dashed lines wrap around curves and corners just as solid lines do.

The ends of each dash are treated with current line cap, corners

within a dash are treated with current line join. No measures are

required to coordinate the dash pattern with features of an output

primitive

.

The offset value, in VDC units, may be thought of as the "phase" or

the dash pattern relative to the start of the path. It is

interpreted as a distance into the dash pattern at which the

pattern should be started. Before beginning output of the dash

pattern, the elements of the array of dash pattern lengths are

cycled through, and the distances of alternating dashes and gaps

added up, but without generating any output. When the offset

distance into dash pattern has been reached, the primitive is drawn

(from its be'ginning) using the dash pattern from the point that has

been reached.

When continuity is set to restart

,

each portion of a primitive

(e.g. each line segment within a polyline) is treated

independently; i.e. the dash pattern is restarted (and offset

applied) at the beginning of each portion. When continuity is set

to continuous, the dash pattern is not restarted in going from one

portion of a primitive to the next.

A functional description of the Set Dash escape parameters is:

Parameters

:

function identifier (I) as assigned by the Registration

Authority

data record (D)

:

offset (VDC)

continuity (one of: restart, continuous) (E)

number of lengths (I)

(nVDC)

dash pattern lengths array

158
Items for Data Record:

If VDC TYPE integer was selected:

Integer IL 3 + number of lengths

Integer IA(1) offset - Integer IA(2) continuity

Integer IA(3) number of lengths

Integer IA(4) first length

Integer IA(5) second length

Integer IA(2+number of lengths) last length

Integer RL 0

Integer SL 0

VDC TYPE real was selected:

Integer IL 2

Integer IA(1) number of lengths

Integer IA(2) continuity

Integer RL 1 + number of lengths

Real RA(1) offset

Real RA(2) first length

Real RA(3) second length

Real RA(l+number of lengths) last length

Integer SL 0

Data Record Description:

The parameters define the offset, continuity, number of dash

pattern lengths, and the dash pattern lengths.

2) CGM Encodings (reference ISO 8632 CGM; Parts 2,3,4)

All encodings will be handled in the same way - as a clear zexz

encoding (machine independent) of a FORTRAN-style packed data

record. This is treated as a string type in each encoding and is

encoded according to the rules for string in that encoding.

159
This page left intentionally blank.

160
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal April 1987

sponsoring authority

Class of Graphical Item: ESCAPE

Specific Escape Function Identifier: Set Line Cap

Description:

This escape function sets a value for the current line cap. This value is to

determine the shape put at the ends of portions of lines and curves during

subsequent interpretation of graphical primitives that use linetype attributes

See attached sheet for additional details

Additional Comments:

The line cap capabilities proposed here are adapted from those in the PostScript

language developed by Adobe Systems Incorporated.

Justification for Inclusion in the Register:

User specified line caps are needed to support the requirements of office doc’oment

exchange and publishing. They are commonly found in widely available proprietary

graphics systems

Relationship to Particular Standards:

1) ISO 8632 (CGM) - Specifies a registered escape as defined in 5.8.1.

2) See attached sheet.

161
1) CGM Functional Specification (reference ISO 8632 CGM;

Part 1: Functional Description)

Set Line Cap sets the current line cap value in the graphics

state to the value specified by the line cap indicator. Thisestablishes the shape to be put at the ends of open subpcrtions of

graphics output primitives whose components are lines or curves

.

The following line cap values are supported:

1: butt cap; the portion is squared off at the endpoint of the

path; there is no projection beyond the end of the path.

2: round cap; a semicircular arc with diameter equal to the

line width is drawn around the endpoint and filled in with

the current line colour.

3: projecting square cap; the portion continues beyond the

endpoint of the path for the distance equal to half the line

width and is squared off.

Values above 3 are reserved for future registration and

standardization, and negative values are available for

implementation-dependent use.

A functional description of the Set Line Cap escape parameters is:

Parameters

:

function identifier (I) as assigned by the Registration

Authority

data record (D) : line cap indicator (IX)

Items for Data Record;

Integer IL

Integer IA(1)

Integer RL

Integer SL

Data Record Description:

The parameter defines the line cap index.

2 ) CGM Encodings (reference ISO 8632 CGM; Parts 2,3,4)

All encodings will be handled in the same way - as a clear text

encoding (machine independent) of a FORTRAN-st yle packed data

record. This is treated as a string type in each encoding and is

encoded according to the rules for string in that encoding.

1

line cap indicator

0

0

162
PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal ^0 April 1987

sponsoring authority ^^3 j

Class of Graphical Item: ESCAPE

[

i Specific Escape Function Identifier: Set Line Join

Description:

This escape function sets a value for the current line join. This value is to

determine the shape put at corners between portions of lines and curves during

subsequent interpretation of graphical primitives that use linetype attributes

See attached sheet for additional details.

Additional Comments:

The line join capabilities proposed here are adapted from those in the PostScript

language developed by Adobe Systems Incorporated.

Justification for Inclusion in the Register:

User specified line joins are needed to support the requirements of office

document exchange and publishing. They are commonly found in widely available

proprietary graphics systems

Relationship to Particular Standards:

1) ISO 8632 (CGM) - Specifies a registered escape as defined in 5.8.1.

2) See attached sheet.

163
1) CGM Functional Specification (reference ISO 8632 CGM;

Part 1: Functional Description)

Set Line Join sets the current line join state in the graphics

state to line join indicator

.

This establishes the shape to be put

at the corners between portions (line or curve segments) of line'

and curve graphical output primitives. The following line join

values are supported:

1 miter join; the outer edge of the two portions are extended

until they meet at an angle, as in a picture frame. (If the

portions meet at too sharp an angle, a bevel join is used

instead; this is controlled by the miter limit state

established by Set Miter Limit escape function) .

2: round join; a circular arc with diameter equal to the line

width is drawn around the point where the portions meet 'and

is filled in with the current line colour, producing a rounded corner.

3: bevel join; the meeting portions are finished with butt end

cap (see the Set Line Cap escape function); then the

resulting notch beyond the ends of the portions is filled

with a triangle in the current line colour.

Values above 3 are reserved for future registration and

standardization, and negative values are available for

implementation-dependent use.

Join styles are significant only at points where consecutive

portion of a path connect at an angle; portions that meet or

intersect fortuitously receive no special treatment.

A functional description of the Set Line Join escape parameters is

:

Parameters

:

function identifier (I) as assigned by the Registration

Authority

data record (D)

:

line join indicator (IX)

164
Items for Data Record:

Integer IL 1

Integer IA(1) line join indicator

Integer RL

Integer SL

0

0

Data Record Description:

The parameter defines the line join index.

2) CGM Encodings (reference ISO 8632 CGM; Parts 2,3,4)

All encodings will be handled in the same way - as a clear text

encoding (machine independent) of a FORTRAN-style packed data

record. This is treated as a string type in each encoding and is

encoded according to the rules for string in that encoding.

Data Record Description:

165
This page left intentionally blank.

166
I

PROPOSAL FOR REGISTRATION OF GRAPHICAL ITEM

date of presentation of proposal *937

sponsoring authority ANSI

Class of Graphical Item: ESCAPE

I Specific Escape Function Identifier: Set Miter Limit

' Description:

This escape function sets a value for the current miter limit. This value helps

determine the shape put at corners between portions of lines and curves during

subsequent interpretation of graphical primitives that use linetype attributes

Its purpose is to place a limit on how long a "spike" can emanate from the join

of two portions of a line or curve primitive by "truncating" long miter joins

into bevel joins. See attached sheets for additional details.

Additional Comments:

The line join capabilities proposed here are adapted from those in the PostScript

language developed by Adobe Systems Incorporated.

Justification for Inclusion in the Register:

User specified miter limits are needed to support the requirements of office

document exchange and publishing. They are commonly found in proprietary graphics

systems

Relationship to Particular Standards:

1) ISO 8652 (C3M) - Specifies a registered escape as defined in 5.8.1.

2) See attached sheet.

167
1) CGM Functional Spacification (reference ISO 8632 CGM;

Part 1:. Functional Description)

Set Miter Limit sets the current miter limit value in the

graphics state to miter length specifierr which must be a nurriber

greater than or equal to 1. The miter limit controls the treatment

of corners between portions of line and curve output primitives

when miter joins have been specified (see Set Line Join^ . When

portions connect at a sharp angle, a miter join results in a spike

that extends well beyond the connection point. The purpose of the

miter limit is to cut off such spikes when when they become

objectionably long.

At any given corner, the miter length is the distance from the

point at which the inner edges of the curve or line portions

intersect to the point in which the outside edges of the portions

intersect (i.e., the diagonal length of the miter). This distance

increases as the angle between the portions decreases. If the ratio

of the miter length to the line width exceeds the miter limit

parameter, the corner is treated with a bevel join instead of a miter join.

The ratio of miter length to line width is directly related to the

angle <|) between the segments by the formula:

miter length / line width = 1 / sin (<p/2)

Examples of miter limit values are: 1.415 cuts off miters (converts

them to bevels) at angles less than 90 degrees, 2.0 cuts off miters

at angles less than 60 degrees, and 10.0 cuts miters off at angles

less than 11 degrees. The default value of the miter limit is 10.

Setting the miter limit to 1 cuts off miters at all angles so that

bevels are always produced even when miters are specified.

A functional description of the Set Miter Limit escape parameters

is : Parameters

:

function identifier (I) as assigned by the Registration

Authority

data record (D)

:

miter length (VDC)

168
Items for Data- Record:

If VDC TYPE integer was selected:

Integer IL

Integer IA{1)

Integer RL

Integer SL

1

miter length

0

0

If VDC TYPE real was selected:

Integer IL

Integer RL

Real RA(1)

Integer SL

0

1

miter

0

limit

Data Record Description:

The parameter defines the miter length.

2) CGM Encodings (reference ISO 8632 CGM; Parts 2,3,4)

All encodings will be handled in the same way - as a clear text

encoding (machine independent) of a FORTRAN-style packed data

record. This is treated as a string type in each encoding and is

encoded according to the rules for string in that encoding.

169
This page left intentionally blank.

170
Vn. REFERENCES

1. G. Enderle, K. Kansy, G. Pfaff, Computer Graphics Programming, Spring Veriag, Berlin,

1984.

2. ANSI X3.122- 1986, Computer Graphics - Metafile for the Storage and Transfer of Picture

Description Information.

3. ANSI X3. 124- 1985, Computer Graphics - Graphical Kernel System (GKS) Functional

Description

4. Robert F. Sproul and Brian K. Reid, Introduction to Interpress, Xerox System Integration

Guide 038404, Xexox Corporation, El Segundo, CA, April 1984.

5. Adobe Systems Inc., Postscript Language Reference Manual

Addison Wesley, Reading,

MA, 1985.

6. Adobe Systems Inc., Postscript Language Tutorial and Cookbook , Addison Wesley,

Reading, MA, 1985.

7. Brad Smith and Joan Wellington, Initial Graphics Exchange Specification (IGES), Version

3.0, National Bureau of Standards, April 1986.

8. Modern Drafting Practices and Standards Manual, Genium Publishing, Schenecttudy, NY,

1986.

9

171
This page left intentionally blank.

172
Vm. APPENDICES

Appendix A. Extracts from Typical DoD Standards
',;-- 5 T ;-253

;uy i?sSYV 5 C - INTE = A ~ '

L!-’^£S, PLA-£ SrO£S

S" Fri^ = 35, N£a5 s r

=

= rEC<S C5 C~-£: "'-A- v, iN section

•-A-E ECC.es, c-',cC2S, C 20E2

5- r r t r - s £-0., S CE C2

OEC<S AS,; 3U'.<-EACS, -A5 s rt C2

rE'.cw

CTN*E 2 L.N £

0=EN \.0 C2 S^EC’®':C Ar«A C5 2CU^C«2'

0

r ^ .__ -_(

j

/ 1

j

/V J

( »0f

)

^44

»ff

\

f

t //• ^

\ «

..

S NO'-E -A^ST£s^^O LA3

OCU 3-E rASTESEO LA2 \v

=-=

}

1 ^^ f^S“En £0 CCw 3'.E 3 'w

^ A 7

C5 SEAv.i

SH 13:;'

rIG:?£ 1. Cr-ve-:: t or.al delineation.

174

til m

Ml'
MIL-STD-25B

10 May 1984

SYMBOL ^P5=TAT!0N

^ i .

e_x

^

j3 irL. >i< “Lioli X

LIMITS OF BE4MS - CONTINUOUS OR

INTERCOSTAL (CONTRACT DRAWINGS)

OR

LIMITS OF INTERCOSTAL BEAMS

(ship CONSTRUCTION DRAWINGS)

5XAxi3^I-T I $«xax{o^I-T limits of COf^^TINUOUS BEAMS

(ship CONSTRUCTION DRAWINGS)

CO.MTINUOUS SHAPE TWPO'JGW PLATE

CONTRACT DRA>;iNGS;

COLUVR DETAILS SPECIFIED IN

APPROPRIATE SPECIFICATION

CCLJLA^

SHIP CONSTRUCTION DRAWINGS:

C0LU\R DETAILS SHOWN ON

DETAIL VIEW AS REQUIRED

SH 13028-1

FIGURE 1. Conventional delineation. - Continued

13

175
MIL-STD-25fa

10 May 198;

WEB PgAMES-OI LVL Tip MN PK )Q x 4 X 1 2 I- T. M N DK TO 2^*0 0< \2 )( <c 2 ^ 2^ I-T^

6EuCw2r>.oD< I2 xG^X35^I-T, except as NOTED

VERT 5TIF 5x4. /NTCL

;— . 7-

i:> ,'

, 4°-.^ ^ Mil iTrri^

4-^ r T T

» -TT“J-r-jw-

-hi M.b;

tit!^m!-Si#ii^

016 5aSE line

STA

SH 13029

FIGURE 2. Contract drawing or contract guidance drawing - shell expansion

i;

176
M i. i A 10 May 1984

SH 13030

FIGITIE 3. Concracc drawing or contract guidance drawing - deck plan .

15

177
MILITAJRY STAI-HDARD

MIL-STD-IT

23 January

SUFZHSZi:

MIL-STT-l

11 Septen

MECHANICAL SYMBOLS

(OTHER THAN AERONAUTICAL, AEROSPACECRAFT

AND SPACECRAFT USE)

PART-1

1963

178

(D>

O
MIL-STD-173-1

23 January 1963

EE?AR7>!ZNT CF CZFZRSE

WASHINGTON 25, D. C.

Mechanical Synhola (Other

Than Aeronautical, Aerospacecraft

and Spacecraft Use)

MIL-STD-17B-1

1. This standard has teen approved ty the

Department of Defense and Is mandatory for use by the

Departments of the Army, the Navy, and the Air Force,

effective 23 January 1963.

2. Recommended corrections, additions, or deletions

should be addressed to the Standardization Division, Defense

Supply Agency, Alexandria, Virginia.

11

179
FOREWORD

Jv1TL-STD-17b- 1

23 January 1963

By permission of the American Standards Association and the

American Society of Mechanical Engineers, the symbols contained

herein have been adopted without change from the following American

Standards:

ASA Z32. 2. 3-1949 - Graphical Symbols for Pipe Fittings, Valves

(Reaffirmed 1953) and Piping.

ASA Y32. 4-1955 - Graphical Symbols for Plumbing.

ASA Z32. 2. 4-1949 - Graphical Symbols for Heating, Ventilating,

(Reafilrmed 1954) and Air Conditioning.

ASA Z32.2# 6-1950 - Graphical Symbols for Heat-Power

(Reaffirmed 1 956) Apparatus

.

ASA Y32. 10-1958 - Graphical Symbols for Fluid Power

Diagrams.

U1

180
r.:iL-STD-17B-l

23 January 1963

CONTENTS

Page

1.1 Scope — 1

1.2 Limitations — — — 1

1.3 Application 1

1.4 Use 1

2. Graphical symbols for pipe fittings, valves and piping ------— 2

3. Graphical symbols for plumbing — 10

4. Graphical symbols for heating, ventilating and air conditioning----- - 13

5. Graphical symbols for heat power apparatus 22

6. Graphical symbols for fluid power diagrams 2o

Iv

181
Section 1, Scope.

MIL-STD-17B-1

23 January 1962

This standard cstablls.hcs an apprcvad listing • t ^ ^ A • , • 4 ^ i 4 i 4 symbols that shall be used in the preparation of drawings when graphic

or symbolic representation is desired, for all items except aircraft,

aercspacecraft, or spacecraft. The sym.bols listed are those m.ost

com.monly employed on engineering drav;ings. They are for exterior

and interior services.

1. 2 Limitations . - Where graphical symibols are required for an

item, or equipmient not covered in this standard, the form, and c.haracter

of the sym.bcl will be left to the discretion of the activity concerned,

provided that the symbol used does not duplicate any of those contained

herein, and is clearly understandable, subject to one interpretation only,

or explained by a suitable note on the drawing when necessary.

1.2 Application4 - Pipe fittings, valves and piping symbols (see

section 2) shall be used for all systems, except wnhere so desired, the

sym.bols shown for fluid power systems (see section 6) may be used for

fluid power systemiS. All other sym.bols shall be used as applicable.

1. 4 Use . - Each drawing or one s.heet of each set of drawings on

which sym.ools are used shall show a legend which shall identify the

sym.bols. However, those sym.bols wnich are unm.istarcably identified

on the drawing by the text or note at or near the sym.bols, m.ay be

om. itted in the legend. In lieu of identifying each sym.bol, it is perm.issible

to state tnat sym.bols used are in accordance with this Standard or the

appropriate Am.erican Standards. Since sym.bslic representation does not

usually involve exact or scale layout or the actual run or leads of piping, the

sam.e symool m.ay be used for all projections of the system, (plan,

elevations and sections) except where specific sym.ools for the various views

are included in this standard.

1

182
M:L-STD- 17B-1

23 January 1963

Section 2 - Graphica * ^4WW*«« -s, valves,

extracted fron: Publication ASA Z32. 2. 3:

a

183
^ .

' '-"a - 1 January O'-,

C. w

pipe r.::',r.gs va.ves and piping (cont*d.

)

! i Bell i ! Flan'jed : Screwed : and spigot : Welded • Soldered

Z^l Long radius

2. 5. 8 Peduclng

2. 5. 9 Side outlet

(outlet dowTv)

2. 5. 10 Side outlet

(outlet up)

2. 6. 11 Street

2. 6 Joint

2. 0. 1 Connecting

pipe

2. 6. 2 Expansion

2. 7 Lateral

2. d Orilice flange

2. 9 Reducing fiance

^

184
:y:iL-STD-173-l23 January 1963

Pipe finings, va.ves

: Flanged : Scrsv/ed

2.10 Pluas

2. 10. 1 Bull plug

2. 10. 2 Pipe plug

2. 11 Reducer

2. 11. 1 Concentric

2. 11. 2 Eccentric

2. 12 Sleeve

2. 13 Tee

2. 13. 1 (Straight

size)^

2. 13. 2 (Outlet up)

2. 13.3 (Cutlet

down)

2. 13. 4 (Double swee0

2. 13. 5 Reducing

2. 12, 6(Single

s’Aeep)

—sii:

md splTwt Telded Soldered

0

c

^ -X—X- -©— -e0

9-Le X' ‘ ~x Q- ^ O

9<lKr X-0-X -KE>©-

x-Qx »£h>

f 9r^ Xi t.x •es-Le185
MIL-STD- 17E-1

22 Jar.uary 15t3

5

186
:.ri-STD- 173-1 - 23 Jan-ary ldz2

Sec'.lon 6 - Grapalcal syzibols fcr fluid power diagrams, extraciod from

ASA ?ubllca:lcr* Y22.1C:

6.1 Tills section shows the bcslo symbols, describes the principles on which

the symbols are based, and lll-strates some representative comprslte symbols.

Composite symbols can be devised tor any iluld power compcnent by c.mb.:.Lng

basic symbols. A symbol Is considered to be the lines, letters and abbreviations

which Identify purpose and method of operation of component represented, and

symbols only are standardized In this section. Component data are added to symbols when 'used In circuit diagrams and consist of names of ports and control

elements, notes regarding pressure and flow rate settings and other explanatory

data.

0.2 Symbol rules. The following rules are applicable to graphical symbols

for fluid power diagrams:

(a) Symbols show connections, flow paths and function of component

represented. They do not Indicate conditions occurlng durl.ng

transition from one flow path arrangement to another. , Further,

they do not Indicate construction, or values such as pressure,

flow rate, and other component settings.

(b) Symbols do not Indicate location of ports, direction of shlftlm of

spools, or position of control elements on actual componentl

(c) Symbols may be rotated or reversed without altering their

meaning except in the cases of:

(1)

^Llnes to reservoir, 6. 3.7.1 and 6. 3. 7.

(2) Vented manifold, 6. 8. 3

(d) Line width does not alter meanl.ng of symbols.

(e) Symbols may be dra'wn any suitable size. Size may be varied

for emphasis or clarity.

(f) Letter comblra.tlons used as parts of graphical symbols are not

necessarily abbreviations, provided t.ieir rr.eanin^ is clearly

•understandable and subject to one interpretation only or

explained by a suitable note or tabulated legend on the

drawing when necessary.

(g) ’Vhere flow lines cross, a loop shall be used except within a symbol

envelope. Loop may be used In this case If c.arity Is Improv^.

(h) In multiple envelope symbols, flow condition shown nearest a control symbol takes place when that control Is caused or permitted

to actuate.

(1) Each symbol Is dra'wn to show normal or neutral condition of

component 'unless multiple circuit diagrams are furnished showing

various- phases of circuit operation.

(j) Arrows shall be used wltnln symbol envelopes to show direction of

flow path In component as used In the application represented.

Double-end arrow snail be used to Indicate reversing flow.

(k) External ports are where flow lines connect to basic symbol, except

where component enclosure Is used.

Externa* ports are at Intersections of flow ILnes and ccmpozent

enclosure symbol wr.en enclosure Is used.

187
MIl-STD-lTB-l

23 January 1963

5. 3 Fle« LiDca Aad Fle« Lim Fuactioos 6.2L8 Oueetiea of 6L3.1 Liato, Verkiai

12.2 Liaoo, Pilot

Length of dash thall be at least 20 line widths ®* PIu4ged Cooaectieo

With spare approturateiy } line wi^ha ^

dl2 Linea. Li^id Oroio or Atr Exhouai

Length of dash and apace shall be ipprositrateiy equal, each leaa than ) line widths.

d2i4 Lines, Oessioi

C.3.C.1 Tfsliof StMiom —

6Ld ^2 Pt^ Pomm TaJt^olf Stmiom

0

63.1C Restrietioo, Fiae4

d2.5 Lines, Jeioiog

d3 .11 Q^ck OiocooMCt

d2.1Ll Withomi Chacks

d2.ll 2 Chadks

Connectot dot shall be approsimatciy 3 widths —..-j

of aaaoe.ated lines. r»aconnected

d2.6 Lines, Flexible

63.'^ Lines to Reaereou dd 1.1 Baiau Plaid Laval

d3LlI.d2 Tith One Check

d3bll.d3 Checks

1

dd7.2 Ahova Pl^d Uval 6. 4 Puapa, Cea^resnors And Rotary Motors d4.1 Bnoic Syvbol c i t ' Ent^iopa

27

188
Appendix B. PostScript and Interpress Capabilities

189
PostScript Procedures and Interpress Symbols

190
POSTSCRIPT Procedures

A PostScript procedure is a set of operations grouped together

with a common name. This set of operations is stored with its key in a dictionary. When the key appears in a program, the as- sociated set of operations is carried out. PostScript procedures are defined in exactly the same way as variables. The program must place the procedure name (preceded

by a slash) on the stack, followed by the set of operations that make up the procedure. Then the def operator is used to store the

operations and name in the current dictionary. The set of operations making up the procedure must be enclosed in braces.

For example, the following line defines a procedure named inch.

^ /inch {72 mul} def

Any appearances of the word inch following this line will cause

the interpreter to carry out the operations inside the braces. That

is. the interpreter will put 72 on the stack and then multiply the

top two numbers, the 72 and whatever was on the stack when

inch was called. Thus, the program lines

5 inch

5 72 mul

V have identical results; both leave 360, the product of 5 and 72, on

the stack.

The inch procedure is a useful tool in many programs, since it translates inches into the l/72-inch units of the POSTSCRIPT coordinate system.

4.2 DEFINING VARIABLES AND PROCEDURES 29

191
4.3 USING PROCEDURES AND VARIABLES

The use of procedures and vanables can make an enormous dif- ference in the readability of a program, the ease with which it can be modified, and its length.

Overlapping Boxes

Three Boxes Again

As an example, let us take the last program from chapter two, the

three overlapping boxes, and rewrite it. Looking over the

program, we see that the set of instructions that construct a oneinch-square path is repeated three times. Let us define these in- structions to be a procedure named box and then incorporate this procedure into the program.

o/, ..... Define box procedure —

/box

( 72 0 rlineto

0 72 rlineto -72 0 rlineto closepath } def

% Begin Program

newpath % First box

252 324 moveto box

0 setgray fill newpath % Second box

270 360 moveto box

.4 setgray fill newpath % Third box

288 396 moveto box

.8 setgray fill showpage

Here we stan by defining our new procedure, box. to be the set of operators that create a square path. We then use that procedure

three times to make three filled boxes. First we move to a start- ing point on the current page. Then we call the box procedure,

which contructs a path starting at that point. Finally, we set the

gray value and fill the path we coniructed. These steps are repeated two more times, once for each box in our image.

Chapter 4: PROCEDURES AND VARIABLES
14

T^. Instancing

The concepts of symbol and irMonce are provided in Interpress by composed operators and

transformations. A graphical symbol can be defined as a composed operator. When an

instance, or copy, of the symbol is to be printed, the current transformauoo will be applied to

all coordinates as (he symbol calls isuger operators. The properties of the current transfomu* non will thus determine the posidoru sue. and rotation of the instaiKe on the pnmed page.

The principal use of symbols and instances in Interpress is for printing characters. Each character IS defined by a composed operator, called a ehaneter operator. These operators are invoked, usually by show, with a current transfonnauon that achieves the proper sue. onenta*

uon. and posiuon of the character.

lostancii^ can also be used for other purposes. Graphical objects that are repeated often on a page or throughout a document onay be treated as instances. A symbol is defined as a composed operator and called with an appropriate current transformadon in order to generate each

instance. Since show may not be the best operator to effect these calls, other primitives are

available as well

14.1 Defuiing symbols

A symbol is simply a composed operator that calls imager operaton to construct a graphical

symbol. The symbol expresses coordinates in a coordinate system of its own choice, sometimes

called the symbol coordinate system. Figure 14.1 shows a sock figure and an associated coordinate system. Example 14.1 shows how this symbol could be defined as a composed operator. To Interpress. this symbol is simply a composed operator. Its effecuve use as a sy mbol depends

on the «ays in which the master calls the composed operator.

l* 1-- -0 - ( --1-- 0 2 IS rSCT --2-- 2 18 (SET --3-- -2004 xaSXVECTOe

--4-- 2 0 3 4 Msxvccroe

--5-- 3408 maSXVICTOH

--8-- -2406 nAS<VtCT0«

2 4 0 8 «*4s»ve:-oe

--8-- - 1 9 I 9 x4S4veC’0«

--9-- ) »*/u£Sl»*PuC0 U fStI

- t lywoo) 1l • CO«eos*e oocrttor-*

--*•( ts 0 I linlis-* -•*•1 10 2 (rogno) -- --loft loj--

--rigni lofl-- --lorjo-- -•Ion «pw--

- • ’ g

f 1 *"«-

comooi*^ ao4'‘ti3'‘ •"8 *«*• 't

U7

193
14 lastaac'.of

Figure U 1. a syrr>?ol defined 'n rts :.v»r<inate ^vs'em

14.2 Making instances

la order co piece aa insunce of a symbol on die page, we will need co use a craxuformauon to control Che sue. rouuon. and locauon of the instance. Thu Tansformauon u responsible for mapping from the symbol coordinate system to the current coordinate system. c.ne one

esublished by T. As we observed in Secuon 6.2. it's common to establish a page coordi.-.ace sys- tem that has a convenient ongin and units of measuremenL The examples m this section will assume a page coordinate system as in Example 6.1. which uses units of 10' ’ meter. When we esublish the symbol*to*page transformation, it is usually heipfiil to break the trans- formauon down into two components: (1) a translauoa. which is used to determine where the ongm of the symbol coordinate system will be on the page coordinate system, and (2) a scaling and/or rouuoa transformauon that determines the sue and rouuon of the unstance witn

respect to its origin.

Suppose, for example, that we want instances of the sock figure m Example U.l to be 10 cm.

high from toe^to head. Since 10 cm. is 10000 uniu in the page coordinate system, and since the head*to*to« distance is 9 units m the symbol coordinate system, the scale co convert from symbol co page coordinates will be 10000/9.

The following master pnnts two instances of the symbol with the same sues, with or.gins u

xs5 cm.. ys8 cm., and at xs 15 cm., ys 3 cm.:
In'.roductioo ro Interpress 14

1 1 i-: • I i ^

3‘::s '

4

si

Ta

91C

It

• “ • - *%

: ;e ;si’

-Z 3 : 4 M*SKV£C*0« 2304 MAS^vtC’Oa

j 4 : s MASk.cc'OR

-2 4 3 5 i4*S«v£C’'0a

t 4 - j <4'4.£2*2* -1919 MASiveCTOH

} «4A»ESIMPL£C0 13 £S£T

}

- -a*5 ’ " 3'«i-'c ' 4

• • 4 S/":: '$ 4 ::«-a

'.s ^ 1 - j'.-:»i£.-.; :: 2 v-o-'^a, • • - i«f I 1 #5 • - i«9*-

-- tar S9-- --’•fl «na-- ....... .

coc«oo$*d eo«<‘«lo^ *nd saw* m

--•na B^**«*>*"

12

1314

15

16

{

0 3300 1 SC*t£ COUCATT --paq* eoo^amaia iy$l*« i" unKi of 0 33031 m#t*r-

{ 13000/9 SCALE 5330 8000 T«*i(SLATE COMCAT CONCATT 13 FG£T 00 } OOSAwES I«P l

a00Y

{ 10033/9 scale ISOOO 8330 TRANSLATE CONCAT CONCATT 13 FG£T 00 > OOSAVES IMPLE SOOT

} --*aa of paga oodyENO Lme 13 alters the current transformauon so chat cooriinates in the s>'mbol will be subjected

first to a scaling transformauon. then a cransiauon. and finail>. to the page transformation. Line 13 could equally well be written as <{ 10000/9 scale 5000 3000 TTLanslaTE coscaTT

CONCATT 13 FGET DO }>. but could nof be wntien as <{ 10000/9 scale CO.nCaTT 5000 8000 nLANSLATE CONCATT 13 FGET 00 }> because this would change the order of applicauon of

cransformauons. However, the following vanant would do: Eiampl* 14 3. i-ao 1 tcaMant for Ima 13 in Examol* M 2*-

13-* ( S0C3 8033 TRAnSlATE CONCATT 10003/9 SCALE CONCATT 13 FG£T 00 } OQSAVES IMPlEBOOt

You should see dearly how this is equivalent to the onginal line 13. Understanding the order of applicauon of transformauons. and how cransforcnaooos are concatenated onto r, is extremely uff.oortanu

Note the use of OOSavesi.mpl£BODY to save and restore the current transformauon. At the beginning of line 13. (he current transformauon esublishes the page coordinate system. Because of the saving and restonng. this same system will also be in effect after line 13 is executed. If the transformauon were not restored, the CONCaTT operaoon on line 13 would

have a permanent effect on (he current uansformaucn. leavmg it in the symbol coordinate

sy stem associated with the fint instance of the suck figure. An aJtemauve way to call an instance is to use the current posiuon and movt or trass to accomplish the translauon u’ansformauon. Example 14.3 could be modified to read:

Eitmpl* 14 4 . r*ol(e*M*nt for 1in* 13 In C4*pi*l* 14 2*>

13-- { SCOO 8000 SETXT MOVE 10000/9 SCALE CONCATT 13 FCET 00 } OOSAVE SIMPLE BOOT

Or. after one minor change, to read:

EiAinol* 14 s. rte 1 ac*m*nt for 1ln* 13 in E<aPi#1* 14 2-*

13«-- 5000 8000 SETXT

13B-- { WOVE 13000/9 SCALE CONCATT 13 F6£T OO ) 0OS4VES t»PL EBOOT

If we re going to make lots of instances of the symbol *:th the sane sue and onentacon. this form r.as a nice proper.y line I3b will be the same for each instance because u cor.u..ns no

pcsit.c.m.ng infcrmauon This suggests denning a comoosed operator to achieve une erTcct of

line Jt t.xa.mp:e 14 s restates he master m Exa.mplc 14 3 to usc.h.is idea:

195
105: racing

14 6 1 m«ge a» tia<"e'4 1 * 2 ><

. 0-- BtGIN (

. i.. ( --4 ’» 4 c;<-s:i43 S0t^4l3^-*

- 2 -- 0 2 15 IS£T ••» 4 t ta 3 1 w«t»*-

- 3-- 2 la rstT ••»4t to 2 (^Own«I •*

. 4 . . •2 0 3 4 «*4S*v£C’0» - - 1 *rt I tq-

•

. j.. 233* MasfvecroA --riqM l#q--

- 3431 MASKvccroe --torio--

- •2419 waHvtCT* ••l4rt Jr-T-

. 2439 »*S»v£CTC* - - 1C* t 4<-^-

. 9 -. •19 19 '»»S«vCC’’0* - - -443 • • M?-- } tJ 'OtT -‘^4^4 ;;4-i;j- 4-.: t4>4 't • - U-* ( ••4notft«r co<**03l4a 38fr4ior-*

•12*- WDve 13333/9 SC*t£ C 0 NC*rT 13 fdlJ 00 -13-- ) MAacsiMrieco la rscr •*w4 k« cemeotae oparator ane tava U la ;*e>n«(t 4

] —

-ta-- > --a«e praaneia*-

-18— ( o.oooot scale coMCArr --oaqc eaareiapta «ytta« ia uaita af 0 00001 watar--

-ts-- 9300 8000 serxr --lat curraat potitiaa ta r»9 e*. /•% c«--

-17 — la FGCT OOSAVC ••pnnt first laitanca--

-ts-- tSOOO 9000 SerXT

-19-- ta FGET OOSAVC --pri«t laeenp lattanca--

-20-- > *-anp 9f paqa Body-*

-21-- exo

This example looks a lot like che way character operators work! The composed operator con*

structed in lior? I to 10 corresponds to a character operator, dehacd in the character coor- dinate system. The composed operator constructed tn lines II to 13 corresponds roughl> to the operator created by modify font, which controls the scale and rouuon of the instance. The

lovocauon of the operator by fint setting the current posiuon to the desired origin of the

instance and then cailmg an approprate operator (lines 16 and 17) corresponds roughly to the way SETXY and show are used for characters.

The basic Interpress facilities of composed operators and transformauons allow a great deal of

flexibility in deOmng and using symbolv including applicauons we have not illustrated. Symbols may of course be routed as well as scaled. Symbols can call other symbols, nesung to an arbitrary depth.

196
PostScript Graphical Operators

' 197
6.1 INTRODUCTION

This chapter contains detailed information about all the standard

operators in the POSTSCRIPT language. It is divided into two

parts.

First, there is a summary of the operators, organized into groups

of related functions. The summary is intended to assist in locating the operators needed to perform specific tasks.

Second, there are detailed descriptions of all the operators, or- ganized alphabetically by operator name. Each operator description is presented in the following format:

operator operand^ operand^ ... operand^ operator result^ ... result.^

Detailed explanation of the operator

EXAMPLE;

An example of the use of this operator. The symbol =» designates values left on the operand stack by the example.

ERRORS:

A list of the errors that this operator might execute

SEE ALSO;

A list of related operator names

103

198
At the head of an operator descnption. operand^ through

operand^ are the operands that the operator requires, with

operand^ being the topmost element on the operand stack. The

operator pops these objects from the operand stack and con- sumes them. After executing, the operator leaves the objects

result^ through result^ on the stack, with result^ being the topmost element.

Normally the operand and result names suggest their types. For

example, num indicates that the operand or result is a number, int indicates an integer number, any indicates a value of any type,

and proc indicates a POSTSCRIPT procedure (i.e., an executable

array). The notation 'bool\int' indicates a value that is either a boolean or an integer. Names representing numbers sometimes

suggest their purpose, e.g., .t, y, or anf^le. A matrix is an array of

six numbers describing a transformation matrix (see section 4.4).

A font is a dictionary constructed according to the rules for font

dictionaries (see section 5.3).

The notation ‘I-’ indicates the bottom of the stack. The notation

in the operand position indicates that the operator expects no

operands, and a in the result position indicates that the

operator returns no results. The documented effects on the operand stack and the possible

errors are those produced directly by the operator itself. Many

operators cause arbitrary POSTSCRIPT procedures to be invoked.

Obviously, sUch procedures can have arbitrary effects that are not mentioned in the operator descriptions.

6.2 OPERATOR SUMMARY

Operand stack manipulation operators

any pop - discard top element 193

any, anyj •xcft any

2 any, exchange top two elements 151 any dup any any duplicate top element 148

any, any^ n copy any,..any^ any,..any^ duplicate top n elements I3i any^ any^ n index any^ any, any^ duplicate arOitrary element ? 72

a.., roil

) moo TioO n

roll n elements up y times 205

any. any

clear — discard all elements 127 - any,..any^ count ^any,..any^ n count elements on stack 132 - mark mark push mark on stack 184

1 04 Chapter 6; OPERATORS

199
mark ooi,..ooi„ cleartomark - aiscard elements down tnrougn -nark r^r mark oO|, 00). counttomark mark oO). oO|. n count elements down to marn

Arithmetic and math operators

num. num. add sum

num, num^ div quotient

mt, intj idiv quotient

int, mtj mod remainder num, numj mul product num, numj sub difference num, aba numj

num. neg numj

num. celling num^

num, floor numj

num. round num.

num, truncate num. num sqrt real num den atan angle

angle coa real angle sin real base exponent exp real num in real num log real - rand mt

mt srartd -

- rrand mt Array operators

int array array -

[ mark

mark ob)Q..ob|„., ] array

array Ien5)tb mt

array index' get any

array index any put

array index count getinterval subarray

array, index array

putinterval

array aloed ag..a,_, array

anyg. any^_, array astore array

array, array^ copy subarray^

array proc forall

num. plus num^ 1 15 num, divided Oy num^

integer divide 168 mod /ntj 185 num, times num^ 186 num, minus num^ 230

aosolute value of num, 1 15

negative of num, 187

ceiling of num, 126

floor of num, 157

round num, to nearest integer 206

remove fractional part of num, 23^

square root of num 224

arctangent of numa^n m degrees i2l cosine of angle (degrees) 132

sine of angle (degrees) 223

raise base to exponent oower 154

natural loganthm (Oase e) 180

logarithm (base 10) 181 generate pseuOo-random integer 197

set random number seed 224

return random numoer seed 207

create array of length mt 120

start array construction f 13 end array construction 113 numoer of elements m array 1 79

get array element indexed Oy maex 164

put any into array at maex 195

suOarray of array starting at maex for count elements 165

replace subarray of array, starting at maex

Oy array

2 19€ push all elements of array on stack 1

1

5 pop elements from stack into array i2i copy elements of array, to initial suoarray

of array

2 131 execute oroc for eacn element of array i6l

6.2 OPERATOR SUMMARY 105

200
Dictionary operators

lOt diet diet create dictionary *itr caoacity for rr elements ^46 dia length mt numoer of key-value pairs m aict ? 79

diet mexlength mt capacity of d/cf 185

diet begin - push diet on diet stack - end poo diet stack 149

key value def associate key and value m current

diet 145

key loed value searen diet stack for key and return associ- ated value 181 key value store replace topmost definition of key 227

diet key get any get value associated with key m diet 1 64

diet key value put associate key with value \n diet 195

diet key known Pool test whether key is m diet 1 77

key where diet true or false find diet m which key is defined 238

diet, diet^ copy dietj copy contents of 0/ct, to diet^ 131

diet proe foreil execute proe for each element of diet 161 - errordict diet push errordict on operand stack 151 - syetemdict diet push syetemdict on operand stack 23

- ueerdict diet push ueerdict on operand stack 236

currentdict diet push current diet on operand stack 134 countdictstaek mt count elements on diet stack 133

array dictetack subarray copy diet stack into array 147

String operators

int string stnng create stnng of length mt 228

String length mt number of elements m stnng 1 79

stnng index get mt get stnng element indexed by index 164

stnng index mt put put mf into stnng at index 195

stnng index count getintervei substnng substnng of stnng starting at index for count elements 165

stnng, index stnngj putintervel replace substnng of stnng^ starting at index

by stnng^ 196

stnng, stnngj copy substnng^ copy elements of srnng, to initial suostnng

of stnng^ 131 stnng proe foreil execute oroe for each element of stnng i6i stnng seek anchorseerch post maten true or stnng false determine <f seek is mitial substnng of stnng 116

string seek search oost rnatch pre true or stnng false searen for seek m string 2i 1 stnng token post token true or false read token from start or string 232

106 ChaoterS. OPERATORS

201
Relational, boolean, and bitwise operators

any. anyj eg bool test equal 150

any, any^ ne bool test not equal ^86

num.istr, nurrij.Str, ge bool test greater or equal ^63

num,;Str. numj.str^ gt bool test greater than

num,istr, numjistfj !• bool test less or equal 1 79

num,istr, numjjstrj It bool test less than i82

bool, lint, booijlintj and booi^jint^ logical 1 bitwise and 1 16

bool, lint. not booijiintj logical I bitwise not i89

bool, lint, booljlintj or 00013! int^ logical 1 bitwise inclusive or 79

f

bool, lint, booijimt^ xor bool

3

|int3 logical 1 bitwise exclusive or 2^ 1 - true true push boolean value true 234

- falM false push boolean value false 755

int, shift bitshift mtj bitwise shift of mr, (positive is left) 125

Control operators

any exoe execute arbitrary obtect 1S2

bool proc if - execute proc if bool is tnje 169

bool proc, proc2 ifotao - execute proc, if bool is true, proc^ if bool is false 169

init incr limit proc for - execute proc with values from mit by steps

of /ncrto limit 160

int proc ropoat execute proc mt times 202

'*proc loop - execute proc an indefinite number of times 182 - exit exit innermost active loop 154 - stop terminate stopped context 226

any stoppod bool establish context for catching slop 227

- countoxacatack mt count elements on exec stack 133

array axacatack subarray copy exec stack into array 152 - quit terminate interpreter 197 - start executed at interpreter startup 225

Type, attribute, and conversion operators

any typa name return name identifying an/s type 235

any evlit any make object be literal 74 7 any eyx any make obtect be executable 744 any xehack bool test executable attnbute 240

arrayifilelstnng exacutaoniy arrayifilelstnng reduce access to execute-only i53

arrayidictifileistnng noaccaaa arayidiaifileistnng disallow any access 188

arrayidictlfileistring readonly arrayidictifileistnng reduce access to read-on ly 200

arrayidictifileistnng rchack bool test read access 1 98

arrayidictlfileistring wcnack bool test wnte access 238

numistnng cvi mt convert to integer 74 7 string cvn name convert to name 142' numistnng cvr real convert to real 142 num radix stnng cvrs substring convert to stnng with radix 143

6.2 OPERATOR SUMMARY 107

202
any string CVS suDstring convert to stnng ?44

File operators

string, string^ file file open file identified by srnng, with access

sfnngj 155

file closefile - close file 129

file read mt true or false read one character from file 198

file int write wnte one character to file 239

file stnng readhexstring substnng bool read hex from file into stnng 199

file stnng writehexatring wnte stnng to file as hex 240

file stnng readstring substnng bool read stnr^ from file 201

file stnng writestring wnte characters of stnng to file 240

file stnng readiine substring bool read line from file imo stnng 200

file token token true or falsa read token from file 232

file bytaaavailadio int number of bytes available to read 125 — flush send buffered data to standard output

file 158

file fluahfiio - send buffered data or read to EOF 158

file reaatfila discard buffered characters 202

file statue bool return status ot file 226

string run execute contents of named file 207

- currantfllo file return file currently being executed 135

stnng print write characters of string to standard output

file 193 any 3 — wnte text representation of any to standard

output file 1 14 ^ any, .. any^ Stack H any, .. any„ pnnt stack nondestructively using > 224

any S3 - write syntactic representatran of any to standard output file 1 14 ^ any, .. any„ patack H-any, .any^ pnnt stack nondestructivety using » 194 prompt - executed when ready for interactive input 194

bool echo - turn on/off echoing 149

Virtual memory operators

- save save create VM snapshot 208

save restore restore VM snapshot 203

- vmstatua level used maximum report VM status 238

Miscellaneous operators

proc bind proc replace operator names m proc by

operators 124 - null null push null on operand stack 189 - uaartime mt return time m milliseconds 237

- version string interpreter version 237

1 08 Chapter 6; OPERATORS

203
Graphics state operators

- gsave save grapnics state '66 - g restore restore grapnics state '65

- grestoreall restore to oottommost grapnics state i66 - initgraphice reset graphics state parameters 1 73 num setlinewidth set line width 219

- currentlinewidth num return current line width 137

int setlinecep set shape of ime ends for stroKe (0=outt.

1 »round. 2*square) 217

- currentlinecep mt return current line cap 136

int setllnejoin set shape of comers for stroke (O-miter,

1 around. 2-bevel) 218

- currentlinejoin mt return current line join 137 num setmlterllmit set miter length limit 220

- currentmitertimit num return current miter limit 137

array offset setdeeh set dash pattern for stroking 214 - currentdasP array offset return current dash pattern 134 num setftat - set flatness tolerance 215

- currentflat num return current flatness 135 num setgray set color to gray value from 0 (black) to 1 (white) 216

- eurrentgray num return current gray 136 hue sat brt « aetPaPcoiof set color given hue. saturation, bnghtness 216

* currentPabcoior hue sat brt return current color hue. saturation, bnghtness 136

red green blue setrgbcolor set color given red. green, blue 221 - eurrentrgbcolor red green blue return current color red. green, blue 136

freq angle proc aetacreen set halftone screen 221 - currentacreen freq angle proc return current halftone screen 139

proc settranafer set gray transfer function 222

- currenttranafer proc return current transfer function 139 Coordinate system and matrix operators

- matrix matnx create identity matnx 184 - initmetrix set CTM to device default r 74 matnx identmatrix matnx fill mafnxwith identity transform 167 matnx defaultmetrix matnx fill matnx with device default matnx 145 matnx currentmetrix matnx fill mafnx with CTM 137 matnx setmatrix replace CTM Oy matnx 219

t t

« y translate translate user soace Oy (f,, 233

t^ t^ matnx translate matnx define translation oy i.*^, rp 233

s s

« y scale scale user soace oy s, ano 209

s s matrix

« f scale matrix define scaling oy s, and 209

angle rotate rotate user soace Oy angle degrees 206

angle matnx rotate matnx define rotation oy angle degrees 206

matnx concat replace CTM by matnx x CTM 130

6.2 OPERATOR SUMMARY 109

204
matriXj matrix^ concatmatrix matnx,

* y transform y'

X y matrix transform X' y' dx dy dtransform dx' dy

dx dy matrix dtransform dx' dy'

*

y' itransform X y

x' y' matnx itranaform X y

dx' dy' idtranstorm dx dy

dx' dy' matnx idtransform dx dy

matnx, matnx^ invertmathx matnxj

^ath construction operators

- newpath - eurrentpoint X y

X y moveto

dx dy rmoveto -

X y lineto dx dy rllneto -

X y

r ang, ang^ are -

X y

r ang, ang^ aren -

X. y, Xj yj r arcto xt, yt, xt^

X, y, X, yj X3 y3 curveto

dxj dyj dX3 reurveto - cioaepath

- rtattenpath -

ravcTMpath

strokspath

string bool charpatti

- dippath -

- pathbbox ll, ll^ ur, ur^ move line curve dose pathforall

inttdip - dip -

- eociip -

Painting operators

eraaapaga

- fill -

- eoflll -

stroke

width height bitssampie matnx proc image

fill matrix^ with matrix, x matrix^ i3G

transform ix. /) Dy CTM 233

transform {x. yi Dy matrix 233

transform oistance .Ox, ay) oy CTM

transform distance idx. ay) oy matnx i43

inverse transform [x'. /) by CTM 176

inverse transform (x'. /) by matnx i76

inverse transform distance (<3x'. d/) by

CTM 168

inverse transform distance idr'. a/) by matnx 168

fill matnx^ with inverse of matnx^ 1 75

initialize current path to be empty 187

return current point coordinate 138

set current point to (x. /) 186

relative moveto 204

append straight line to (x. y) 180

relative lineto 204

append counterclockwise arc 1 17 append clockwise arc 1 18 append tangent arc 1 19 append Bezier cube section 140

relative curveto 198 connect subpath back to its starting

point 130

convert curves to sequences of straight

lines 157

reverse direction of current path 203

compute outline of stroked path 229

append character outline to current path 127

set cunent path to clipping path 129

return bounding box of current path 191 enumerate current path 192

set dip path to device default 1 72

establish new dipping path 128

clip using even-odd inside rule 149

paint current page white 151

fill current path with current color 156

fill using even-odd rule 150 draw line along current path 229

render sampled image onto current page 1 70

1 1 0 Chapter 6; OPERATORS

205
height invert matrix proc imagemask render mask onto current page t7i Device setup and output operators

- showpage output and reset current page 223

- copypage output current page ^32

matrix width height proc banddevice install band butter device 123

matrix width height proc framedevice install frame oufter device 162

- nulldevice install no-output device 190

proc renderbands enumerate bands for output to device 201

Character and font operators

key font definefont font register font as a font dictionary f46 key findfont font return font diet identified by key 156

font scale scalefont font' scale font by scale to produce new

font 210

font matnx makefont font' transform font by matnx to produce new

font 183

font satfont - set font dictionary 215

- currantfont font return current font dietKsnary 136

stnng show - pnnt characters of stnng on page 222

a, a^ stnng aahow add (a^ to width of each char while showing stnng 120

c, c char stnng widthahow add (c^ to width of. char while showing

stnng 239

c, Cy Char a, stnng awidthahow combined effects of ashow ar>d widthshow 122

proc stnng kshow execute proc between characters shown

from stnng 1 78

stnng strtngwidth w, w^ width of stnng in current font 228

- FontOlraetory diet diaionary of font dictionanes 1S9 - StandardEncoding an’ay standard font encoding vector 225

Font cache operators

- cachaatatua bsize bmax msize mmax csize cmax blimit return cache status and parameters 126 w w II II ur ur

* y satcachadavica declare cached character methcs 2i2 w w1 y satcharwidth declare uncached character metnes 2i3 num satcachatlmit set max bytes m cached character 2i3

Errors

dictfull no more room m dictionary 146 dictstackovarftow too many oegms 147 dictstackundartlow too many ends 147 execstackoverftow exec nesting 'oo deep '53 handlaarror called to report error information 167

6 2 OPERATOR SUMMARY 1 1 1

206
interrupt exter^’ai interrupt 'eauest e g

control -C) invaiidaccess attempt to violate access attnoute / 74

invaiidaxit exit not m loop 1 7$

invalidfilaaceaaa unacceptaoie access stnng r 75

invalidfont invalid font name or diet f 75

invalidrastora improper restore 1 75

ioarror inpufoutput error occurred f 76

limitchack implementation limit exceeded idO nocurrantpoint current point is undefined i8d rangachack operand out of Pounds 197

stackovarftow operand stack overflow 224

stackundarflow operand stack underflow 225

syntaxarror syntax error m PostScript program

text 230

timaout time limit exceeded 231

typachack operand of wrong type 235

undafinad name not known 235

undafinadfilanafna file not found 236

undafirtadraault over/underftow or meaningless result 236

unmatehadmark * expeaed mark not on stack 236

unraglatarad internal error 236

VMarrof VM exhausted 237

1 1 2 Chapter 6: OPERATORS

207
arc X y

r ang, angj arc -

second

endpotnt

appemi> a counterclockwise arc ot' a circle to the current path. po^'ibK

preceded by a straight line segment. The arc has 1 1. \ i as center. / as radius. un\!^ the angle of a vector from (.v. > » of length r to the fir'^t endpoint of the arc. and ang-, the angle of a vector from i.i. yj of length

r to the second endpoint of the arc.

If there is a current point, the arc operator includes a straight line segment from the current point to the first endpoint of this arc and then adds the arc itself into the current path. If the current path is empty, the arc operator does not produce the initial straight line segment. In any

event, the second endpoint of the arc becomes the new current point.

Angles are measured in degrees counterclockwise from the positive

.i-axis of the current user coordinate system. The curve produced is circular in user space. If user space is scaled non-uniformly (i.e.. dif- ferently in .r and >-). arc will produce elliptical curves on the output

device.

The operators that produce arcs (arc, arcn. and arcto) represent them

internally as one or more Bezier' cubic curves (see curveto) that ap- proximate the required shape. This is done with sufficient accuracy that a faithful rendition of an arc is produced. However, a program that reads the constructed path (using pathforall) will encounter curveto

segments where arcs were specified originally.

EXAMPLE;

newpath 0 0 moveto 0 0 1 0 45 arc closepath

This constructs a unit radius 45 degree pie slice*. ERRORS:

limitcheck, rangecheck, stackunderflow, typecheck

SEE ALSO:

arcn, arcto, curveto

arc I arc 117

208
arcn x /

r ang. ang, arcn -

I arc negative) beha\e> like arc. but arcn build> it> arc ^egme^t in j

clockwise direction (in user space).

EXAMPLE;

newpath 0 0 2 0 90 arc 0 0 1 90 0 arcn closepath

This constructs a 2 unit radius. 1 unit wide. 90 degree windshield

wiper swath'. ERRORS:

limitcheck. rangecheck. stackunderflow, typecheck

SEE ALSO:

arc. arcto. curveto

1 1

8

arcn | arcn

209
arCtO X, y, Xj r arctO xt. yt, xt, yt, appendN an arc ot a circle (o (he current paih. ponmN\ preceJea p> a

'traiL'ht line >c;jnien(. The ar>. in defined h\ a radiU' and ('a>> (anceiii

lines. The tanjiem lines are those dra'.Mi from the current point, nere

called (.V,,. to (.t|. Vj) and from i Vj. V|i to i.v,. \ .i. ilt the current

point is undefined, arcto executes the error nocurrentpoint. i

The center of the arc is located within the inner angle between the tangent lines; it is the onK point located at distance r m a direction perpendicular to both lines. The arc begins at the first tangent point

\r^i on the first tangent line, pusses between its center and the point i.\,. \

I ). and ends at the second tangent point i.u-. w,) on the second tangent line.

Before constructing the arc. arcto adds a straight line segment from the current point (.v„, v,,) to i.vr,. yr|). unless those points are the same. In any event, (.v/-,. vr,) becomes the new current point.

The curve produced is circular in u.ser space. If user space is scaled

non-uniformly (i.e.. differently in v and y). arcto will produce elliptical curves on the output device.

If the two tangent lines are collinear. arcto merely appends a straight

line segment from i.iy,. y^) to <-V|. y, ). considering the arc to be pan of a degenerate circle (with radius 0) at that point.

The values returned by arcto are for information only; they are the two

tangent points in user space.

0.4 1.4 44

EXAMPLE;

newpath 0 0 moveto

0 4 4 4 1 arcto 4 (popl repeat

4 4 iineto

This constructs a 4 unit wide. 4 unit high right angle with a 1 unit radius ’rounded comer.’ ERRORS;

limitcheck. nocurrentpoint. stackunderflow. typecheck.

undefinedresult

SEE ALSO:

arc, aren. curveto

arcto arcto 1 * 9

210
dip - dip -

inrersects the inside of the current clipping path '^ith the inside of the current path, to produce a new i smaller) current clipping path. The

inside of the current path is determined b> the normal PostScript

non-zero winding number rule (see section 4.6). while the inside of the current clipping path is determined by whatever rule was used at the time that path was created. Before computing the intersection, the clip

operator implicitly closes any open subpaths of the current path.

In general, dip produces a new path whose inside (according to the non-zero winding number rule) consists of all areas that are inside both

of the onginal paths. The manner in which this new path is constructed

(order of its segments, whether or not it self-miersects. etc.) is not

specified.

There is no way to enlarge the current clipping path (other than by

initclip or initgraphics) or to set a new path without reference to the current one. The recommended way of using clip is to bracket the clip

and the sequence of graphics to be clipped with gsave and grestore.

The grestore will restore the clipping path that was in effect before the gsave.

Unlike fill and stroke, clip does not implicitly perform a newpath after

It has finished using the current path. Any subsequent path construction

operators will append to the current path unless newpath is executed

explicitly. This can be a source of unexpected behavior.

ERRORS:

limitcheck

SEE ALSO:

eodip, clippath, initclip

1 28 clip I clip

211
ciosepath - closepath -

^.loseN ihe -.urrem 'uhpath appending a 'trai>aht lino 'O^meni ..'n- neamg the current point to the ^ubpath'^ 'tuning point 'generally tne point moM recently 'pecified by mo%eto). If the current 'ubpath i' already closed or the current path i'. empty, closepath doeN nothing.

(See section 4.5.)

closepath terminates the current subpath. .Appending another segment

to the current path will begin a new 'ubpath. even if it is drawn from

the endpoint reached by the closepath.

ERRORS:

limitcheck

SEE ALSO:

nil, stroke

closepath | concatmatrix
curveto X, y. curveto -

adds a Bezier cubic section to the current path between the current

point, referred to here as i.Vq. and the point ( v,. > ,). using (.ip i and ( V,. V,) as the Bezier cubic control points. .After constructing the curve, curveto makes (.V 3

, v^) become the new current point. If the current point is undefined (because the current path is empty), curveto

executes the error nocurrentpoint.

The four points define the shape of the curve geometncally. The curve

Stans at (.Cg. >gj. it is tangent to the line from (.rg, Vg) to (.r,. >,) at that point, and it leaves the point in that direction. The curve ends at

(.r^, y^). it IS tangent to the line from (.t,. y-,) to (.^ 3

, >’ 3) at that point, and

it approaches the point from that direction. The lengths of the lines

(.tg, Vg) to (.r,. y,) and (,r,, y-^) to represent in some sense the velocity' of the path at the endpoints. The curve is always entirely

enclosed by the convex quadrilateral defined by the four points.

The mathematical formulation of a Bezier cubic curve is derived from a

pair of parametric cubic equations:

xU) = + c/ + .tg

yit) = -t- -t- cj + Vg

The cubic section produced by curveto is the path traced by .cm and

y(r) as t ranges from 0 to 1 . The Bezier control points corresponding to

this curve are:*

.r, = .to + c/3

.c, = .Cj (c^ > b^)/3

ERRORS:

limitcheck, nocurrentpoint, stackunderflow, typecheck

SEE ALSO:

lineto. moveto, arc, arcn, arcto

y\=yo*'=P

y^ = >1 + (c^ + b^)/3

V, = Vrt (• c + b a '3 '0 V V y

For a more thorough treatment of the mathematics of Bezier cubics. see

J. D. Foley and A. Van Dam. Fundamentals of Interactive Computer Graphics.

.Addison- Wesley. 1982.

1 40 curveto | curveto

213
moveto X y moveto -

>tarts a ne'A subpath of the current path, moveto sets the current point

in the graphics state to the user space coordinate i.r. vi without adding

any line segments to the current path.

If the previous path operation in the current path was also a moveto (or

rmovetoj. that point is deleted from the current path and the new

moveto point replaces it. ERRORS:

limitcheck. stackunderflow, typecheck

SEE ALSO:

rmoveto, lineto« curveto, arc, closepath

-4

1 86 moveto | ne

214
rcurveto dx, dy, dxj dyj dxj dyg rcurvcto -

(relative curveto) adds a Bezier cubic section to the current path in the same manner as curveto: however, the three number pairs are inter- preted as displacements relative to the current point (.Vq, Vq) rather than

as absolute coordinates. That is, rcurveto constructs a curve from

(.Vq. Vq) to Vg+dVj), using (.rg+d-r,. VQ+dv,) and

^ (.Vg+dLr-,. Vg+dv-,) as Bezier control points. See the descnption of

curveto for complete information.

ERRORS:

limitcheck. nocurrentpoint, stackunderflow, typecheck,

undefinedresult

SEE ALSO:

curveto, rlineto, rmoveto

1 98 rcheck | read

215
rlineto dx dy rlineto -

(relative linetoi appends a straight line segment to the current path m

the same manner as lineto: however, the number pair is interpreted as a displacement relative to the current point (.i. >

) rather than as an ab- solute coordinate. That is. rlineto constructs a line from i r. vi to

(.r-t*d.v. and makes (.r-t-dr. yt-d> ) be the new current point.

ERRORS;

limitcheck. nocurrentpoint. stackunderflow, typecheck

SEE ALSO:

lineto. rmoveto, rcurveto

rmoveto dx dy mnovoto -

(relative moveto) starts a new subpath of the current path in the same manner as moveto: however, the number pair is interpreted as a dis- placement relative to the current point {x, y) rather than as an absolute

coordinate. That is. rmoveto makes (x*dx, y**dy) be the new current

point, without connecting it to the previous point. If the current point is undefined (because the current path is empty), rmoveto executes the error operator nocurrentpoint.

ERRORS:

limitcheck, nocurrentpoint, stackunderflow, typecheck

SEE ALSO:

moveto, rlineto, rcurveto

204 rlineto ! rmoveto

216
stroke - stroke -

strokepath

paints a line following the current path and using the current color. Thi>, line IS centered on the path, has sides parallel to the path >egments. and

has a width (thickness) given by the current line width parameter in the graphics state (see setlinewidth). stroke paints the joints between con- nected path segments with the current line join (see setlinejoin) and the ends of open subpaths with the current line cap (see setlinecapi. The

line is either solid or broken according to the dash pattern established

by setdash.

The parameters in the graphics state controlling line rendition (line

width, line join, and so forth) are consulted at the time stroke is ex- ecuted: their values dunng the time the path is being constructed are

irrelevant.

If a subpath is degenerate (consists of a single point), stroke paints it only if round line caps have been specified, producing a filled circle centered at that point. If bun or projecting square line caps have been

specified, stroke produces no output, since the orientation of the caps would be indeterminate.

stroke implicitly performs a newpath after it has finished painting the current path. To preserve the current path across a stroke operation, use

the sequence: gsave stroke grestore.

ERRORS:

limitcheck

SEE ALSO:

setiinewidth. setlinejoin, setmiteriimit, setlinecap, setdash

- strokepath -

replaces the current path with one enclosing the shape that would result

if the stroke operator were applied to the current path. The path result- ing from strokepath is suitable as the implicit operand to fill, clip, or pathbbox. In general, this path is not suitable for stroke, as it may

contain intenor segments or disconnected subpaths produced by

strokepath 's stroke to outline conversion process. ERRORS;

limitcheck

SEE ALSO:

nil, clip, stroke, pathbbox. charpath

Strok* I strokepath 229

217
settlat num Mtfiat -

t

4

>ets the rlames's parameter in the current graphics ^fate to nnm. Ahich

must be a positive number. This controls the accuracv airh 'Ahu.n curved path segments are to be rendered on the raster output device b>

the stroke, fill, and clip operators. Those operators render curves b> approximating them with a senes of' straight line segments. ’Flatness' is an informal term for the error tolerance of this approximation, it is the maximum distance of any point of the approximation from the cor- responding point on the true curve, measured in output device pixels.

The choice of flatness value is a tradeoff between accuracy and execution efficiency. Very small values (less than I device pixel) produce

very accurate curves at high cost, since enormous numbers of tiny line segments must be. produced. Larger values produce cruder approximations with substantially less computation. A default value of the flat- ness parameter is established by the device setup routine for each raster output device: this value is based on characteristics of that device and is the one suitable for most applications.

ERRORS:

stackunderflow, typecheck

SEE ALSO:

currentflat, flattenpath, stroke, fill

Mtflat I Mtfont 215

218
PostScript Image Capabilities

219
image width height oits/sampie matrix proc image -

renders a sampled image onto the current page. The description here only summanzes the image operator: see section 4 T for full details The sampled image is a rectangular array of v>.idth x height sample

values, each of which consists of bits/ sample bits of data ( 1. 2. 4. or 8). The data is received as a sequence of characters, i.e.. 8-bit integers in the range 0 to 255. If bits/sample is less than 8. sample values are packed left to right within a character (but see the note in section 4.7). The image is considered to exist in its own coordinate system. The

rectangular boundary of the image has its lower left comer at (0. 0) and

its upper nght comer at {width, height). The matrix operand specifies a transformation from user space to the image coordinate system.

image executes proc repeatedly to obtain the actual image data, proc

must return (on the operand stack) a saing contaimng any number of

additional characters of sample data. (If proc returns a string of length

zero, image will terminate execution prematurely.) The sample values

are assumed to be received in a fixed order (0, 0) through {width~[, 0), then (0. I) through (width-l, I), etc. Use of the image operator after a sctcachedevice within the context of

a BuildChar procedure is not permitted (an undefined error results);

however, use of imagemask in that context is permitted (see the setcachedevice operator and section 5.7). EXAMPLE;

/picstr 256 string def

45 140 translate

1 32 1 32 scale

256 256 8

(256 0 0 -256 0 256]

(currentfile

picstr readhexstnng pop)

image

% stnng to hold image data

% locate lovver left comer of image

% map image to 1 32 point square

% dimensions of source image

% map unit square to source % read image data from program file

4c47494b4d4c524c4d5053505 1 554c5 152... 5959565c5 ... (131072 hex digits of image data)

ERRORS;

stackunderfiow, typecheck, undefined result, undefined

SEE ALSO:

imagemask

170 image | Image

220
imagemask ^lOtn neignt nvert matr'x proc imagemask -

IS similar to the image operator: however, it treats the source image as a rttask of 1 bit sample^ that are u.^ed to control vv,here to acpl> paint

(With the current color) and 'Ahere not to. See me de^cnption or :ne image operator and the presentation of sampled images in section 4.'

imagemask uses the width, height, matrix, and proc operands in precisely the same way as image. The invert operand is a boolean that determines the polanty of the mask. If invert is false, portions of the image corresponding to source sample values of 0 are painted, while

those corresponding to sample values of 1 are left unchanged. If invert

is true, sample values of I are painted and sample values of 0 are left unchanged.

imagemask is most useful for printing characters represented as bit- maps. Such bitmaps represent masks through which a color is to be

transferred; the bitmaps themselves do not have a color (see secuon

4.7). EXAMPLE;

45 228 translate 132 132 scale

% locate lower left comer of square

% scale 1 unit to 132 points

0 0 moveto 0 1 lineto % fill square with gray background

1 1 lineto 1 0 lineto closepath

.9 setgray fill

0 setgray

24 23

% paint mask black

% dimensions of source mask

true % oaint the 1 bits [24 0 0 -23 0 23] % map unit square to mask

{<003800 002700 002480 0E4940 114920

148220 3CB650 75FE88 17FF3C 175F14

1C07E2 3803C4 703182 F8EDFC 02BBC2

BB6F84 31BFC2 18EA3C OE3EOO 07FC00

03F800 1 El 800 1 FF800>} % mask data

imagemask

ERRORS:

stackunderflow, typecheck. undefinedresuit

SEE ALSO;

image

imagemask | imagemask 1 7

221
This page left intentionally blank.

222
Appendix C. IGES Entities and Capabilities

4

223
APPENDIX 3 IGES ENTITIES AS RENDERED BY GRAPHICS STANDARDS SYSTEM

This Appendix describes each of the IGES entities in turn, noting

how well these entities could be rendered by a system based upon

the graphics standards.

1. Geometric Entities

CIRCULAR ARC. Not available in GKS/PHIGS. Present as CIRCLE and

3 -POINT ARC in CGI/CGM.

COMPOSITE CURVE. Rendered by POLYLINE in GKS/PHIGS; by POLYLINE,

ARC, and ELLIPTICAL ARC in CGI/CGM. The full conics and splines

of IGES are not directly supported, but would have to be

approximated by POLYLINE.

CONIC ARC. Not available in GKS/PHIGS. Present as CIRCLE,

ELLIPSE, 3-POINT ARC, and ELLIPTICAL ARC in CGI/CGM. Parabolas

and hyperbolas are not directly supported.

COPins DATA. ^ Directly available as POLYLINE with different line

types . *

PLANE. Unbounded planes need no direct visualization. Bounded

planes correspond to POLYGON SET in GKS/PHIGS/CGM and are supplemented by CLOSED FIGURE in CGI.

LINE. Available as a two-point POLYLINE.

PARAMETRIC SPLINE. Can be visualized by lines, arcs, etc.

However, information about the shape is lost.

PARAMETRIC SPLINE SURFACE. Can be visualized by rectangles,

lines, arcs, etc. However, information about the shape is lost.

POINT. Available as POLYMARKERS for pre-defined symbols and

positioned SEGMENTS (GKS/CGI but not CGM) or STRUCTURES (PHIGS)

for user-defined symbols.

RULED SURFACE. Can be visualized by lines, etc. However,

information about the shape is lost.

SURFACE OF REVOLUTION. Can be visualized by lines, arcs, etc.

However, information about the shape is lost.

103

224
TABULATED CYLINDER. Can be visualized by lines, arcs, e~c.

Hcv/aver , infornarion about the shape is lost.

TRANSFORMATION MATRIX. Really used like an attribute in IGES

Also special form numbers are used with certain contructs for

Finite Element Analysis and viewing. Closely related to SEG?^E!.’T

TP.A.'.'SFCPl-LATICN’S of GK3 and PHIGS transformation matrix structure

elements used for modelling and viewing. No direct parallel in

CGI or CGM.

FLASH ENTITY. In GKS, only have POLYMARKER or segments to

realize the forms. In CGI/CGM, you also have CIRCLE and

RECTANGLE. IGES flash entity form 4, rounded rectangle, is not

directly available in any of the graphics standards.

RATIONAL BrSPLINE CURVE. Can be visualized by lines, arcs, etc.

However, information about the shape is lost. Parabolas and

hyperbolas not directly supported by the graphics standards.

RATIONAL B-SPLINE SURFACE. Can be visualized by lines, arcs,

etc. However, information about the shape is lost. Parabolas

and hyperbolas not directly supported by the graphics standards.

OFFSET CURVE. Can be visualized by lines, arcs, etc. However,

information ^ about the relationship between the two entities is

lost.

CONNECT POINT. Can be visualized by lines. However, information

about the relationship between the entities is lost.

NODE. Not directly visualized, so no need for support from the

graphics standards. However, not unlike a PHIGS structure label.

FINITE ELEMENT. Thirty-three ' topologies are currently defined by

IGES version 3. All can be visualized using the graphics

primitives of line, arc, ellipse, etc., with loss of infomation

concerning the relationships between the lines and curves making

up the wire-frame model. Furthermore, the IGES specification is

much more compact.

NODAL DISPLACEMENT AND ROTATION. These are attributes that are used to communicate finite element post processing data.

OFFSET SURFACE. Can be visualized by lines, arcs, etc.

However, information about the relationship between the two

entities is lost.

CURVE ON PARAMETRIC SURFACE. Can be visualized by lines, arcs,

etc. However, information about t.he relationship between t.ne curve and t.he surface is lost.

109

225
TRIMMED (PARAMETRIC) SURFACE. Can be visualized by l.r.es, arcs,

etc. However, infcrration about t.de reiat ic.-.snips ar.cr.g tr.e boundary lines and other curved lines used to represent tne

surface is lost.

ANGULAR DIMENSION. Visualize using text, lines, arrovs, and arcs. Only arrows not directly supported in the grapn.cs

standards. See discussion under LEADER entity below.

CENTERLINE. Use graphics circles (in CGI/CGM) only and special

line types. Could be made available in GKS/PHIGS through special

marker types.

DIAMETER. Visualize using text, lines, arrows, and arcs. FLAG NOTE. Visualize using text and fill area (polygon)

primitives.

GENERAL LABEL. Visualize using text, lines, and arrows. GENERAL NOTE. A general note entity consists of one or more text

strings. Each text string contains text, a starting point, text

size, and angle of rotation of the text. A single font number

applies to the whole note and incorporates the separate concepts

of type face .^'appearance of the characters; e.g., bold Helvetica,

italic Futura) and character set (shape of the characters; e.g.,

ASCII, German National Set, Math, Greek). Only 7-bit character

codes are supported. In addition, a form number is used to

designate the layout of the (possibly multiple) text strings, the

justification of the strings within a text rectangle, and whether

there are subscripts, superscripts, fractions, and embedded font

changes. The GKS/PHIGS TEXT and CGI/CGM TEXT, APPEND TEXT, and

RESTRICTED TEXT primitives with their numerous text attributes

are capable of visualizing any general note entity. With

RESTRICTED TEXT and APPEND TEXT, CGI/CGM are a bit more capable

than GKS/PHIGS.

LEADER, Eleven arrow head types are specified in IGES version 3. Although all can easily be rendered using more primitive lines

and polgons, the information that the arrowhead belongs with the

leader line is lost when described using graphics standards

primitives

.

LINEAR DIMENSION. Visualized using text, lines, and arrows. ORDINATE DIMENSION, Visualized using text, lines, and arrows. POINT DIMENSION. Visualized using text, lines, arrows, circles,

and polylines/polygons (hexagons)

.

110

226
RADIUS DIMENSION. Visualized using text, lines, arrows, and arcs

SECTION. Visualized using FILL AREA with HATCH patterns. Of the

eight pre-defined IGES patterns, two correspond to CGI/CGM hatch

patterns; namely, IGES form 31 is CGM hatch style 3 and IGES form

37 is CGM hatch style 6. GENERAL SYMBOL. Visualized using text, lines, arrows, etc., and

possibly grouped in SEGMENTS (GKS or CGI but not CGM) or STRUCTURES (PHIGS).

SECTIONED AREA. Visualized with POLYLINE and FILL AREA in

GKS/PHIGS/CGM and also using CLOSED FIGURE with fill in CGI.

However, the IGES representation is generally more compact,

because there is control over the angle and spacing of the lines

that maJce up the cross-hatched fill pattern. In these cases, the

DISJOINT POLYLINE element of CGI/CGM may help. In its default

state, IGES line pattern code I corresponds to CGM hatch style 3,

line pattern code 16 to CGM hatch style 6, and line pattern code

13 to CGM hatch style 5. WITNESS LINE. Visualized using POLYLINES, although the DISJOINT

POLYLINE of CGI/CGM may be useful in certain special cases. ASSOCIATIVITY DEFINITION. Defines the relationship among

entities. These relationships are lost in CGM, occasionally can

be represented by GXS/CGI segments, and with somewhat greater

likelihood can be represented by PHIGS structures.

ASSOCIATIVITY INSTANCE. Many predefined associativity

relationships exist in IGES. These include simple and ordered

GROUPS (both doubly linked and forward-only linked entities)

,

external references and external reference files, labels, and

parent-child structures. These have some parallels in PHIGS

structures, but in general need not be directly handled by a graphics viewing system like CGI/GKS. Likewise, the PLANAR and

FLOW instance types do not require direct support from the

graphics system. The VIEWS VISIBLE and VIEWS VISIBLE, COLOR,

LINE WEIGHT instance type have an effect on the visualization of

the IGES model. The necessary controls for proper visualization

are available in the graphics standards, using viewports, color

tables, and line width specification mode. Finally, the

DIMENSIONED GEOMETRY instance type has already been discussed in

Section 1 above, under the separate elements for ANGULAR

DIMENSION, LINEAR DIMENSION, POINT DIMENSION, DIAMETER DIMENSION,

RADIUS DIMENSION, and ORDINATE DIMENSION.

Ill

227
DRAWING. A drawing is a coilecticr. of annotation antitoas and

views. Multiple drawings can be included in a single file.

Drawings by/e nar.es and size; units ray be specified for t.'.-a drawing. A drawing closely corresponds to a CGM or to any i.rage

displayed on a graphics view surface by any. of the prograrr.er

interface standards: GKS, CGI, or PHIGS.

LINE FONT DEFINITION. Two types of line fonts ray be defined.

One type considers a line font as a repetition of a basic pattern

of visible-blanked segments superi.mposed upon a straight line or

a curve. The other type considers a line font as a repetition of

a template figure that is displayed at regularly spaced locations

along a planar anchoring curve. None of the graphics standards,

at present, support user-defined line types; the type 1 capability would have to be visualized by POLYLINE (in GKS/PHIGS)

and DISJOINT POLYLINE (in CGI/CGM) ; the type two capability by

using segments or structures in PHIGS/GKS/CGI and only lines,

rectangles, etc. in CGM.

I MACRO Capability. This facility allows the IGES specification to

be extended beyond the common entity subset, utilizing a formal

mechanism which is a part of the IGES Specification. This

facility is available in an extremely limited fashion in the

graphics standards as ESCAPE and GENERALIZED DRAWING PRIMITIVE

(GDP)

. ^ PROPERTY. This facility is available in the graphics standards

as APPLICATION DATA and MESSAGE. Many engineering specific

properties are defined in the IGES specification. A few of them

correspond to graphics elements, generally useful for rendering a picture. These are Region Restriction, Hierarchy (partial)

,

Name, Drawing Size and Drawing Units.

SUBFIGURE Definition. All such relationships can be visualized

fairly straightforwardly using PHIGS structures, somewhat more difficultly using GKS and CGI segments, and much more difficultly

in CGM.

TEXT FONT Definition. This IGES facility provides for the

exchange of font definitions, which are limited to a model of

the motion of an imaginary pen moving between t.he points of an integer Cartesian "font coordinate system." None of the graphics

standards provide support for "user-defined" fonts. However,

such a stroke-precision text capability can easily be built on top of all the graphics standards. Compactness of

representation is lost, but speed of picture generation should

not be much worse.

112

228
VIEW ENTITY. This IGES entity defines a framework for specifying

a viewing orientation of an object in three dimensional model

space. The '•framework is also used to support the projection of

ail or part of model space onto a view plane. One type of

projection,. an orthographic parallel projection, can be

specified. Clipping to a view volume is supported.

The 3-D graphics standards, GKS-3D and PHIGS, have a much richer

viewing model. They allow a full 4x4 transformation matrix to be

used, thus obtaining perspective projections and various oblique

parallel projections as well.

EXTERNAL REFERENCE ENTITY. PHIGS Archive Files would directly

support this element. The other standards (GKS/CGI/CGM) would

have to do a lot more processing to directly support this

feature.

NODAL LOAD/CONSTRAINT ENTITY. A special element to support

Finite Element Modelling.

COLOR DEFINITION ENTITY. Not directly available in GKS/PHIGS,

but is present in CGI/CGM as the MAXIMUM COLOR EXTENT element.

In GKS/PHIGS, the application would query the workstation

description tables to gather sufficient information to adjust for

this entity i:^fore rendering the picture with a graphics system.

TEXT DISPLAY ENTITY. See the earlier discussion under the IGES

GENERAL NOTE ENTITY. The attributes of text include height and

width, font index, slant angle, rotation angle, mirror flag, and

horizontal/vertical text path. All such entities can be

correctly displayed by a proper setting of the graphics- standards

text attributes, which are common to PHIGS/GKS/CGI/CGM.

113

229
This page left intentionally blank.

230
IGES Text Capabilities

231
310 - TEXT FONT DEFINITION

^*.3.10 Text Font Definition Entity.

This entity defines the appearance of characters in a text font. The

data describing the appearance of a character may be located by the

Font Code (FC) and the ASCII character code. This entity may describe

any or ail the characters in a character set. Thus, this entity may be

used to describe a complete font or a modification to a subset of

characters in another font. Font Number and Font Name are the

number and name used to reference the font on the originating system.

When this entity is a modfication to another font, the Supersedes Font

value (Parameter 3) indicates which font the entity modifies. This

value is an integer which indicates the font number to be modfied or the negative of the pointer value to the directory entry of another text

font definition entity. When this entity modfies another font, i.e.. Parameter 3 references another font, the definitions in this entity

supersede the definition in the original font. For example, a complete

set of characters may have their font definition specified by this entity.

Another text font definition entity could reference the first definition

and modify a subset of the characters.

Each character is defined by overlaying an equally spaced square grid over the character. The character is decomposed into straight line

segments which connect grid points. Grid points are referenced by

standard Cartesiaif coordinates. The position of the character relative

to the grid is defined by two points. The character's origin point is placed at the origin (0,0) of the grid and defines the position of the

character relative to the text origin of that character. The second

point defines the origin point of the character following the character

being defined. This allows the spacing between characters to be

specified. Construction of text strings consists of placing the character

origin of the first character at the text string origin and placing

subsequent character origins at the location specified in the previous

character as the location of the next character's origin.

40S

232
310 - TEXT FONT DEFINITION

The parameterization of the character appearance is described by the

motion of an imaginary pen moving between grid points. Commands to move the pen reference the grid location to which the pen is to move. The pen may be "Uftetf* such that its movement is not displayed. The

representation of the movement of the pen is a sequence of pen

commands and grid locations. Each movement of the pen is represented

by a pen updown flag and a pair of integer grid coordinates. The pen

up/ down flag defaults to pen down. A flag value of 1 means the pen is to be lifted G.e., display off) and moved to the next location in the

sequence. Upon arrival at this location the pen is returned to a **down”

position (i.e.y display on)

The grid size is related to the text height through the scale parameter.

This parameter defines how many grid units equal one text height init.

4.3.10.1 Directory Data

Entity type number : 3io

4.3.10.2 Parameter Data

Index Name Type Description

1 FC Integer Font Number

2 FNAME String Font Name

3 Integer Number of the font which

this definition supersedes

4 SCALE Integer Number of grid units which

equal one text height laiit

5 N Integer Number of characters in this

definition

6 ACl Integer ASCII code for first

character

7 NXl Integer Grid location of the next

character's origin

406

233
310 - TEXT FONT DEFINITION

Index Name Type Description

S NYl Integer

9 NMl Integer Number of pen motions for

first character

10 PFlj . Integer Pen up flag

0 3 Down, 1 s Up

11 Xlj Integer Grid location to which the

pen is to move

12

• •

Integer

•

• 9^NM1^3

e

•AC2•

Integer ASCII code for second

character

104.NM1«3 NX2 Integer Grid location of the next

character origin

1UNM1^3 NY2 Integer N 12^NM1«3 NM2 Integer Number of pen motions for

e • •

second character

•

N

• •

U4N<»>2«3*NMi • Integer Last grid location of last

is I character

Additional Pointers as required (see 2.2.4.4.2).

407

234
310 - TEXT FONT DEFINITION

An example of this entity using the character in Figure is

FC

FNAME

SF

SCALE

t N

ACl

NXl

NYl

NMl

PFl

XI

Y1

PF2

X2

Y2

PF3

X3

Y3

PF#

X4

Y%

1SH STANDARD

5

60

63

11 0

6

0

6

5

0

s

0

12

6

0

6

6

In the parameter section of the ICES file it would look like

USHSTANDARDmS.60,63,1UO,4.*4»S«>S«0,1,2,4„6,4^.

Figure 4-42 provides another example.

408

235
310 - TEXT FONT DEFINITION

FIGURE 4-41 EXAMPLE OF A CHARACTER DEFINITION

409

236
31C - TEXT FONT DEFINITION

SCALE

GRI

ORIGIN

4

P.2) P.2)

4 4

4 4

4 4

P.0) OMdrigin of

NEXT CHARACTER

4 4 4 4 4

4 4

FIGURE 4-42 SECOND CHARACTER DEFINITION EXAMPLE

410

237
212 - general note

4.2.9 General Note Entity.

A general note entity consists oi one or more text strings. Each text string

contains text, a starring point, text size, and angle of rotation of the text. Examples of general notes are shown in Figure 4-9. The PC value indicates the

font number and is an integer. Positive values are pre^defined fonts. Negative

values point to user defined fonts or modifications to a pre-delined font.

The following fonts will be defined:

0. Symbol Font (use no longer recommended)

1. Standard Block

2. LeRoy

3. Futva

4. Fastfont

5. Caleomp

6. Comp SO

7. Micr^Film Standard

S. ISO Standard

9. OIN Standard

10. Military Standard

11. Gothic

12. News Gothic

13. Lightiine Gothic

14. Simplex Roman

13. Italic

16. APL

17. Century Schoolbook

15. Helvetica

1001. Symbol Font 1 1002. Symbol Font 2

Fonts in the 1000 series display symbols mapped onto ASCII characters as shown

in Figures 4-10 and 4-11. They do not specify a character display font.

223

238
239

FI6.

4>9

EXAff>LES

OF

THE

6ENEIUL

NOTE

ENTITY
- general not

7 0 0 • 0 P P

\

p ©

1 1

•

1 1 A A Q Q • q t

• M 2 2 8 B R R b OJ r o

• # 3 3 C C S S c o t ®

• $

4 4 0 D T T d t 0

% % S 5 e E U U • O u o

%

s.

6 6 f F V V f // V A

S 7 7 c G w w 9 /y V O

C c

8 8 H H X X h y X 4^

) )

8 9 1 I

Y Y I -=• y y

1 •

• J J z Z J X Y

« - 1 •

• K K c C

k r\ c c

• • < < L L

\ \ i ± 1

1

• - • - H M 3 ] ® } }

• • > > N N

A /\ n 0

- —

/ / ? ?

0 0 - 0 o

FONT CODE 100

1

FIGURE 4-10

225

240
212 - GENERAL NOTE

0 0• (5 P CL % \ P

1 1•

1 1 A A Q Q • X q

• u 2 2 B B R R b • p -

t ± 3 3 C C S S c < t

• o

4 4 D D T T d > t 0

%

0/

/o s 5 E UJ U U t A u e

i 6 6 F F V V f >r V T

# #

7 7 6 •G w W g X V

c C

8 8

H H X X h ZZI X UJ

) 9 9 I 1

—

Y Y 1 y X

I •

• J J Z Z J s

z a

« + 1 •

• K K t 1

—

k => C 5

• • < < L L\ \ { V 1

- - • m H M 3 f

—

m A } TT

• • > > N N

A /\ n -

/

/ 7 ?

0 0 - 0 I

FONT CODE 1002

FIGURE 4-11

226

241
212 - G£M£RAL MCTI

Font I do«s not h*vo 4 dolinod diapioy. Uso of Font I impiio* tho rocoivmg

system may use any font whic^ dispieys the appropriate ASCII characters. The

intent of this font Is for usage when the actual display of the characters is not

critical for the application.

. Font 0 is an old symbol font and should no longer be used. Flgt^e a • 12 Is a mapping symbol definition for font 0.

If the FC number Is not sufficient to describe the font, a text font definition

entity may be vjMd to define the font. II a text font definition is being uMd, the

negative of the pointer value for the directory entry of the text font definition

entity Is placed In the FC parameter. The um of the values VT, HT, A, and

text start point are shown In Figve a. 13.

Vithin definition space, the parameters for the text Mode are applied in the

following order (See Figure wiab

1) Define the box height Q4T) and box width (TT).

The rotate Internal text flag Indcates whether the text box Is filled srith horUontal text or vertical text. The bos width is meas>xed from the text

start point In the poeitivo XT direction and the bos height is measured In the podtive YT drection from the text start point, before the rotation

angle (A) Is applied.

2) The slant angle Is then applied to each individual character. For horiaontai

text it Is measvred from the XT axis In a eo«mterciedcwise directien. For

vertical text the slant angle is measured from the YT axis.

3) The rotation angle Is then applied to the text block. This rotation Is applied In a counterclockwise direction about the text start point. The

plane of rotation Is the XT, YT plane at the depth ZSn (where ZSn Is the

value given for the text start point).

227

242
212 - GENERAL NOTE

0 z 26 54 t 102 B 130 X 1S6 0

1 • 27 (jU 55 - 103 C 131 Y 157 0

2 < 30 X

56 • 104 D 132 Z 160 ©

2 > 31 a 57 / 105 E 133 c

161 t

4 32 5

60 0 106 F 134 \ 162 o

5 33 M 61 1 107 G 135 ]

163

6 X 34 TT 62 2 1 10 H 136 164

7 — 35 63 3 1 1

I

137 165 o

10 36 ± 64 4 1 12 J 1401 \ 166 A

1

S

37 0 65 5 1 13 K 141 -c 167 o

12 => 40 66 6 1 14 •L 142 0 170

13 V 41 I• 67 7 115 M 143 CJ 171 7

U A 42 M 70 8 1 16 N 144 o 172 Y

15 — 43 # 71 9 1 n 0 14S o 173 C

16 I 44 $ 72 • •

• 120 P 146 // 174 1 17 f 45 % 73 •

t 121 Q 147 17S }

20 * 46 8. 74 < 122 R 150 176

21 47 s 75 m 123 S 151 177 2

22 50 C

76 > 124 T 152

23 0 5) D 77 ? 1251 U 153 r\

24 d 52 100 O' 126 V 154 j.

25 T 53 101 A 127 W 155 ©

FIGURE 4-i2 CHARACTER SET & OCTAL COOeTOR

FONT CODE ZERO

228

243
212 - GENERAL NOTE

k) The mirror operation is performed next. The value 1 Indicates the mirror

axis is the (rotated) line perpendicular to the text base line and through the

text start point. The value 2 indicates the mirror axis is the (rotated) test base line.

Finallyt the Transformation Matrix entity is used to specify the relative position of

definition space within model space.

The number of characters (NCn) must always be equal to the character comt in its corresponding text string (TEXTn).

229

244
IF

(mirror

flag

<

TEXT

IS

MIRRORED

212 - GENERAL NOTE

230

245
HORIZONTAL

TEXT

5

VERTICAL

TEXT

212 - general note

fnn tun

231

246

FIG.

4-14

GENERAL

NOTE

EXAMPlf

OF

TEXT

OPERATIONS
212 - :

k,2,9A

^.2.9^

*.2.9.3

*.2.9.*

*.2.9.*.

*.2.9.*.2

RAL HU is.

The graphical representation and recreation oi notes with a special structure are handled by the use oi the Form Number in Field 13 oi the

Directory Entry tor this entity. A system to accommodate these notes is outlined below. Any strings aiter those spediled by the form number are considered additional* appended strings that are not related In any partio

lar manner to the previously referenced strings.

In the event that a string necessary for the defined structure Is not present

in the originating system's note, a null string shall be inserted in the

general note entity to take the place of the non-existent string to maintain

the structure of the data.

Notes that contain fractional notation will be represented as mixed

numerals. This is done through the use of four consecutive strings

representing the whole number, the numerator, the denominator, and the

^visor bar. These are examples of the divisor bar string

IH/ IH- 2H- 1H_

The following form numbers for the general note are used to maintain the

graphical representation of the originating system's notei

Form Oi Simple Note (default) - A general note of one or mere strings

such that a text string is not related in any manner to another

string in the same general note entity. -

Form 1: Dual Stack - A general note oi two or more strings where the

first two are related in a manner such that they are both left justified and the second string is displayed 'below* the first.

xxxzxx yyyyy

232

247
212 - general no

4.2.9.4.3

4.2.9.4.^

k.2,9.k,5

%.2«9.A.6

A.2.9.4,7

4.2.9.A.3

Form 2i Imbedded Font Change - A general note of two or more strings

that is intended as a single string but was divided to accommodate

a font change in the string. uce:t yyy xxxx

Form 3: Superscript • A general note of two or more strings where the

second string is a superscript of the first string.

yyy“

Form Subscript - A general note of two or more strinp where the

second string is a subs^ipt of the first string.

XXXyyy

Form 3t Super-/Su^script - A general note of three or more strings where

the second string is a superscript of the first string and the third

string is a subscript of the first string.

yyy“

zzz

Form Multiple Stack/Left Justified - A general note where all strings are left justified to a common margin. These strings originated as a "paragraphed* note. ucauocxxxxx yyyyyyyyy

TTZ2XIIX1SX

Form 7: Multiple Stack/Center Justified • A general note where all strinp

are center jusdlied to a common axis.

yyyy

ZZ2222X

233

248
212 - GENERAL NOTE

4.2.9.4.9 Form S: Multiple Stack/Right Justified - A general note where all strings are right justified to a common margin, xxxxxxxxxx

yyyyyyy

Z2Z22222

4.2«9.4».10 Form 100: Simple Fraction - A general note of four or mere strings

where the first four strings define a mixed numeral as defined in 4.2.9.J. yyy

XX —

22Z

4.2.9.A.U Form 101: Dual Stack Fraction • A general note of eight or more

strings which represent two mixed numerals as defined in 4.2.9.J. These mixed numerals are related such that the

fifth through the eighth strings are displayed below the first through the fourth strings respectively.

yy

XX —

zx

Jju —

kk

4.2.9.4.12 Form 102: Imbedded Font Change/Oouble Fraction - This general note

originated as a single string but was split to accommodate a

font change for a special character in the fifth string. This

is a general note of nine or more strinp where the first and

sixth strings represent the whole number string of a mixed

numeral as defined in 4.2.9.J. The fifth string is a character

(or characters) that was set apart to accommodate the font

change.

yy jj XX — - ii —

zz kk

234

249
212 - CENSaAL NC

<>.2.9.4.13 Form 105: Super-/Subscript Fraction - A general note o£ twelve or more strings where the first, fifth, and ninth strings

represent the whole number string of a mixed numeral as defined in 4.2.9. 3. The second and third mixed numerals are the superscript and subscript respectively of the first mixed

numeral.

idc

ss

rr —

tt

235

250
212 :meral mote

4.2.9.3 Directory Data

ENTITY TYPE NUMBER : 212

4.2.9.6 Parameter Data

Index Name Type Descriotion

1 NS Integer Number of text strings in general note

2 NCI Integer Number of characters in

first string (TEXTl) or

zero. The number of

characters (NCn) must

always be equal to the

character count of its corresponding text string

(TEXTn)

3 WTl Real Box width

6 HTl Real Box height

5 PC Integer or Pointer Font characteristic

(Default « 1)

6 SLI Real Slant angle of TEXTl in radians (pi/2 is the value

for no slant angle and is the default value)

7 A1 Real Rotation angle In radians for TEXTl

S Ml Integer Mirror flag

0-no mirroring

1 - mirror axis is perpendicular to text base line

2 - mirror axis is text base line

9 VHl Integer Rotate internal text flag

(0-text horizontal, 1-text

verPcal)

10 XSl Real First text start point

11 YSl Real

236

251
212 - general NC

12 ZSl Real 2 depth from XT, YT

plane

13 TEXTl String First text string

U NC2 Integer Number of characters in second text string

UNS*12 TEXTNS String Last text string

2*NS*12 NCNS Integer Number of characters in last text string

Additional Pointers «s required (see 2«2.^.4.2)

237

252
IGES Curve Capabilities

253
100 CIRCULAR ARC

3.2 Circuif Are Entity

A circtiiar are Is a connected portion oi a parent circle which consists of more than one point. The definition space coordinate system is always

chosen so that the circular arc lies in a plane either coincident with or

parallel to the XT, YT plane.

3.2.1 A circular arc determines laiique arc end points and an arc center point (the

center of the parent circle). By considering the arc end points to be

enumerated and listed in an ordered manner, start point first, followed by

terminate point, a direction with respect to definition space can be asso> dated with the arc. The ordering of the end points corresponds to the

ordering necessary for the arc to be traced out in a counterciockwise manner.

This convention serves to distinguish the desired drcuiar arc from its complementary arc (complementary with respect to the parent circle). Refer

to Section 3.1.2 for information relating to use of the term cotaiterciockwise.

3.2.2 The direction of the arc with respect to model space is determined by the

original counterclockwise direction of the arc within definition space, in eonj^mction with the action of the transformation matrix on the arc.

3.2.3 In the event that a parameterixation is required but not given, the default

parameterization isi

C(t) . (XI R^cos t, Yl R^sin t, ZT)

for t2 4 t < t3

where, for i « 2 and 3,

Q) R « sqrt((Xi.Xi)*^2 (Yi-YI)**2)

(ii) ti is such that (R*cos tl, R*sin ti) » (Xi - XI, Yi - Yl)

and

0 4 t2 < 2*P!

0 4 t3 - t2 4 2^P1

108

254
100 - CIRCULAR ARC

3.2.4 Exampiea of the circuiar arc entity are shown in Figure 3-1. In Example 3 of Figure 3-Iy the solid arc is defined using point A as the start point and point

B as the terminate point. If the complementary dashed arc were desired, the

first endpoint listed in the parameter data entry would be B, and the second

would be A.

3.2.3 Directory Data

ENTITY TYPE NUMBER : 100

Parameter Data

Index Name Type Oescriotion

1 rr Real Parallel ZT displacement of arc from XT, YT plane

2 XI Real Arc center abscissa

3 Yl Real Arc center ordinate

4 X2 Real Start point abscissa

3 Y2 Real Start point ordinate

6 X3 Real Terminate point abscissa

7 Y3 Real Terminate point

ordinate

Additional Pointers as required (see 2.2.b.4.2).

109

255
100 - CIRCULAR ARC

no

256
102 - COMPOSITE CURV

3.3 Composite Cirve Entity

A composite ojrve is a connected curve that results from the grouping of certain

individual constituent entities into a logical unit.

3.3.1 A composite ctrve is defined as an ordered list of entities of the following types:

point, line, circular arc, conic arc, parametric spline, rational B-spline, and

connect point. The list of entitles appears in the parameter data entry. There,

each entity to appear in the defining list is indicated by means of a pointer to the directory entry of that entity. The order within the defining list is derived

from the order of the listing of these pointers.

3.3.2 Each constituent entity has its own transformation matrix and display attributes.

Each constituent entity may have text or properties associated with it. Because

the constittient entities are subordinate to the composite entity, the Subordinate

Entity Switch (digits 3-4 in directory entry field 9) of each constituent entity

should indicate a physical dependency.

3.3.3 A composite aawe is a directed curve, having a start point and a terminate

point. The direction of the composite curve is induced by the direction of the

constituent ewe entities Q.e.« those constituent entities other than the point

entity) in the following way: The start point for the composite curve is the start

point of the first ewe entity appearing in the defining list. The terminate point

for the composite cjrve is the terminate point of the last curve entity appearing

in the defining list. Within the defining list itself, the terminate point of each

constituent cirve entity has the same coordinates as the start point of the

succeeding curve entity.

3.3.^ The point and connect point entities are included as allowable entity types so that properties or general notes can be attached to either the start point or the

terminate point of any constituent curve entities in the defining list.

A logical connection relationship can be indicated by having two composite

cxirves or a composite curve and a network subfigure reference the connect point

entity. For the special case of the logical connection of a connect point on one

subfigure instance to a connect point on another subfigure instance a

111

257
SPLINE

102 - COMPOSITE CURVE

112

253
102 - COMPOSITE CURV

composite curve is allowed whose list contains only two connect point entities

with no intervening curve entity. There are certain restrictions regarding the use oi the point entity in a composite entity. They are:

a. Two point or connect point entities cannot appear consecutively in the

defining list vatiess they are the only entities in the composite curve.

b. II a point or connect point entity and a ewe entity are adjacent in the

defining list, then the coordinates of the point or connect point entity must

agree with the coordinates of the terminate point of the curve entity

whenever the cirve entity precedes the point or connect point entity, and

must agree with the coordinates of the start point of the curve entity

whenever the curve entity follows the point or connect point entity.

c. A composite curve cannot consist of a point entity alone or a single connect

point.

3.3.J In the event that a parametrization Is required but net given, the default

parametrization of the composite curve is obtained from the parametrization of

the constituent curves as defined below. As point and connect point entities do

net contribute to the parametrization of a composite curve, they are not

considered in the definition below.

Let

C

N

CCU)

be the composite oxve;

be the number of constituent cirves (N> 1); be the i-th constituent curve, for each i such that 1414N

be the parametric value of the start of CCQ)

be the parametric value of the end of CC(i)

be 0.0

be the sum from j»l to jai of (PE(j) - PS(j)),

for each i such that l^i 4 N.

PSG)

PEG)

T(0)

TG)

113

259
102 - COMPOSITE CURVE

Then

(1) the pvametric values of C range from T(0) to T(N) ; and

(2) C(u) a CCQ) (u • TQ*1) PS (i)) where u is a parametric value such that

Ta-l)4u4T0).

A campoaite curve consisting solely of point and/or connect point entities, will

net be given a parametrization.

3.3.6 In this section, an example of a parametrization of a composite curve entity is given.

Let Na3 and for each I such that Ki 43, let CCQ) be the i«th constituent curve

of the composite curve C. Assume the parametric values of the start and end

points of each CCQ) are given by the table

I PSQ) PEQ)

1 0.0 0.6

2 3.3 3.3

3 0.0 0.3

/ Then T(0) a 0.0, T(l) a 0.6, T(2) a 0.6, T(3) a 0.9, and the composite cirve C, is defined from 0.0 to 0.9.

This situation described is illustrated by

The curve combining CC(1), CC(2), and CC(3) represents the composite cvrve C.

114
T02 - COMPOSITE CURV

3.3.7 An example of a composite ojrve entity is shown in Figure 3-2

3.3.S Directory Data

E.NTITY TYPE NUMBER : 102

Description

Number of entities

Pointers to directoryentries for the constituent

entities

3.3.9 Parameter Data

Index Name Type

1 N Integer

2 DE Pointer

N«1 DE Pointer

Additional Pointers as required (see 2.2.^. %.2).

115

261
10M - CONIC ARC

3.A Conic Are Entity

A conic are is a bounded connected portion of a parent conic curve which

consists of more than one point. The parent conic curve is either an ellipse, a

parabola, or a hyperbola. The definition space coordinate system is always

chosen so that the conic arc lies in a plane either coincident with or parallel to the XT, YT plane. Within such a plane, a conic is defined by the six

coefficients in the following equation.

A^XT^ B*XT*YT C*YT^ XT E^YT P • 0

3.A.1 Each coefficient is a real number. The definitions of ellipse, parabola, and

hyperbola in terms of these six coefficients are given below.

3.A.2 A conic arc determines latique arc endpoints. A conic arc is defined within

definition space by the six coefficients above and the two endpoints. By

considering the conic arc endpoints to be enumerated and listed in an ordered

manner, start point followed by terminate point, a direction with respect to

definition space can be associated with the arc. In order for the desired

elliptical arc to be distinquished from its complementary elliptical arc, the

direction of the desired elliptical arc must be cowterciodcwise. In the case

of a parabola or hyperbola, the parameters given in the parameter data

section latiquely define a portion of the parabola or a portion of a branch of

the hyperbola; therefore, the concept of a counterclockwise direction is not

applied. (Refer to Section 3.1.2 for information concerning use of the term

’*counterciockwisef .)

3.A.3 The direction of the conic arc with respect to model space is determined by

the original direction of the arc within definition space, in conjtaiction with

the action of the transformation matrix on the arc.

116

262
104 - CONIC AR

3.4.4 The definitions of the terms ellipse, parabola, and hyperbola are given in terms

of the quantities Ql, Q2, and Q3. These quantities ar«

01 - determixuat of

A Bn D/2

Bn c E/2

on m F

02 * deurminant of [ A Bn

[j/2 C

03 - ^ C

3.4.3 A parent conic cifve is An ellipse if Q2X and Ql * Q3<0.

A hyperbola if Q2<0 and Ql ^ 0. A parabola if Q2 « 0 and Ql ^ 0. An example of each type of conic arc is shown in Figure >3.

3.4.6 These entities which can be represented as various degenerate forms of a conic

equation (Point and Line) must net be put into the Entity Type 104; more

appropriate Entity Types exist for these forms.

Because of the numerical sensitivity of the implicit form of the conic

description, a receiving system not using that form as its internal representation

for conics need not be expected to correctly process conics in this form criess

they are put into a standard position in definition space. A conic arc entity is said to be in a standard position in definition space provided each of its axes is parallel to either the XT axis or YT axis and provided it is centered about the ZT

axis. For a parabola, use the vertex as the origin. The conic is moved from this position in definition space to the desired position in space with a transformation

matrix (Entity type 124).

The form number is regarded as purely informational by such a postprocessor.

Further details may be found in Appendix E.

117

263
104 - wwNxO AAC

IIS

264
104 - CONIC AR

3.4.7 In the event that a parameterization is required but not given, the default

parameterization is:

Parabola

case A and £ / 0.0

if XI < X2

C(t) a (t, -(A/E)*f*2, ZT)

where, for i s 1 and 2, ti a Xi.

if X2 < XI

C(t) a (-t, -(A/E)*t*^2, ZT)

where, for i a 1 and 2, ti a -Xi.

case C and 0 ^0.0

if Yl 4 Y2

C(t) a (.(C/0)*t^*((2, t, ZT)

where, for i a i and 2, ti a Yi.

ifY2 < Yl

C(t) a «C/0)*f*2, -t, ZT)

where, for i a 1 and 2, ti a -Yi.

for tl ^ t 4 t2

for ti 4 t 4 t2

for tl 4 t 4 t2

for 1 1 4 t ^ t2

Ellipse

C(t) a (a^cos t, b*sin t, ZT)

for tl ^ t 4 t2

where

a a sqrt(-F/A)

b a s<|rt(.F/C)

and, for i a 1 and 2, ti Is such that

Q) (a*cos ti, b*sin ti, ZT) a (Xi, Yi, ZT)

Gi) 0 4 ti 4 2*P1

Gu) 04 t2-tl4 2*PI

Hyperboia

case F^A < 0.0 and F*C > 0.0

a a sqrt<-F/A)

b a s^tiF/C)

and, for i a 1,2

ti is such that

G) (a*sec ti, b^tan ti, ZT) a (Xi,Yi,ZT)

Gi) - Pl/2<tl,t2<PI/2

119

265
loa - CONIC ANC

3.A.1

li tl < t2

C(t) = (a*sec t, b^tan t, ZT) for i ^ t ^ :2

if t2 <tl

C(t) a (a^secf-t), b*tan(-t), ZT) for -ti ^ t ^ -t2

caM F*A > 0.0 and F*C <0.0

l«t a a sqrt(F/A)

b a iqrt(-F/C)

and, for i a 1,2

ti is such that

G) (a^tan ti, b*sec ti, ZT) a (Xi,Yi,2T)

Gi) - Pl/2 <tl,t2 <Pl/2

if tl<t2

C(t) a (a^tan t, b*s«c t, ZT) for tl ^ t ^ t2

if t2 < tl

C(t) a (a«tan(-t), b*s«c(-t), ZT) for *tl ^ t ^*t2

Field 15 of the directory entry accommodates a Form Number. For this entity,

the options are as foilowsi

FORM Meanini

0 Form of parent conic ctrve must be determined from the general

equation.

1 Parent conic cirve is an ellipse (See example 1, Figure 5>3).

2 Parent conic curve is a hyperbola (See example 2, Figure 3-3).

3 Parent conic cvrve is a parabola (See example 3, Figure V3).

120

266
104 - CONIC ARC

3.4.9 Directory Data

ENTITY TYPE NUMBER : 104

3.4.10 Parameter Data

Index Name Type

1 A Real

2 B Real

3 C Real

4 0 Real

3 E Real

6 F Real

7 ZT Real

1 XI Real

9 Yl Real

10 X2 Real

11 Y2 Real

Additional Pointers as required (see 2.2*^4^.2).

121

Description

Conic Coefficient

Conic Coefficient

Conic Coefficient

Conic Coefficient

Conic Coefficient

Conic Coefficient

ZT Coordinate of

plane of definition

Start Point Abecisaa

Start Point Ordinate

Terminate Point

Abscissa

Terminate Point

Ordinate

267
106 - COPIOUS DATA

3,3 Cooious Data Entity

This entity stores data points in the form of pairs, triples, or sextupies. An

interpretation flag value signifies which of these forms is being used. This value

is one of the parameter data entries. The interpretation flag is abbreviated

below by the letters IP.

Data points within definition space which lie within a single plane are specified

in the form of XT, YT coordinate pairs. In this case, the common ZT value is also needed. Data points arbitrarily located within definition space are specified

in the form of XT, YT, ZT coordinate triples. Oata points within definition

space which have an associated vector are specified in the form of sextupies; the

XT, YT, ZT coordinates are specified first, followed by the t, j, k coordinates of

the vector associated with the point. (Note that, for an associated vector, no

special meaning is implicit.)

Field 13 of the directory entry accommodates a Form Number. For this entity,

the options are as follows:

FORM Meaninf

1 Data points in the form of coordinate pairs. All data points lie in a plane ZTa constant. (1P«1)

2 Data points in the form of coordinate triples. QP«2)

3 Data points in the form of sextupies. CIP«3)

11 Data points in the form of coordinate pairs which represent the

vertices of a planar, piecewise linear curve (piecewise linear

string is sometimes used). All data points lie in a plane

ZTsconstant. (1P«1)

12 Data points in the form of coordinate triples which represent the

vertices of a piecewise linear curve (piecewise linear string is sometimes used). (lPa2)

13 Data points in the form of sextupies. The first triple of each

sextuple represents the vertices of a piecewise linear curve

(piecewise linear string is sometimes used). The second triple is an associated vector. UPs3)

20 Centerline Entity through points (IPsl)

122

268
106 COPIOUS OATA

21 Centerline Entity through cirde centers (IPsl)

31 Section Entity Form 31 (IP=1)

32 Section Entity Form 32 (IP»1)

33 Section Entity Form 33 (IPal)

36 Section Entity Form 36 (IPal)

33 Section Entity Form 33 QP«1)

36 Section Entity Form 36 (IP«1)

37 Section Entity Form 37 dP*l)

3S Section Entity Form 3S (IP*1)

60 Witness Line Entity (IP«1)

63 Simple Closed Area Entity QPsl)

Th« Un«ar path is an orPtred sat of points in aithar 2* or Vdimansienai spaca.

ThaM points daHna a sarias of linaar safmants along tha consacutiva points of

the path* Tha sagmants may cross or ba coinddant with aach othar. Paths may

dosa, i*a*, tha first path point may ba idanticai to tha last*

Tha linaar path is implamanted as two forms of tha copious data block (antity

numbar 106)* Form 11 is for 2-dmansional paths and form 12 is for 3- dimansional paths* This antity will ba doaaly associated with propartios

indicating fisKtionality and fabrication paramatars, such as Lina Vidaning*

Rafar to tha canterilna and witness line entities in Section S of this specification

for examples of Form Numbers 20« 21 and 60* Each of these annotation entities

contains a description of how tha associated copious data are to ba interpreted.

Forms 3U3S provide for tha transfer of graphical Information and are defined

hare for compatability with previous versions of the specification. The

Sectioned Area Entity (type 230) provides a more compact method for

transferring this information.

A simple dosed area Is a bounded region of XY coordinate space represented by

a set of points that forms a series of connected linear segments. These segments

must form a dosed loop, i.e., the first point of the boundary of the area and the

last point must be identical. No segments of this entity are allowed to intersect

or be coinddent except for the dosing of the entity at the initial and final

123

269
106 - COPIOUS DATA

points. This entity will be closely related to properties that indicate

functionality of closed regions, such as Region Fill and Region Restriction.

The area is implemented as Form 63 of entity 106, the copious data block.

3.3.1 Directory Data

ENTITY TYPE NUMBER * 106

3.3.2 Parametar Data

Index Name Type Descriotion

1 IP Integer Interpretation Flag

IP«I x,y pairs, common z IP«2 x,y,z coordinates

IP«3 x,ya coordinates and

i,j,k vectors

2 N1 Integer Number of rvtuples

For IP*1 (x,y pairs. common zk

3 ZT Real Common z displacement

% XI Real First data point absciasa

3

e Yl

•

Real

e

First data point ordinate

e

e

#3^2N

•

eYN

e

eReal

e

e Last data point ordinate

For IPs2 {XfYtZ triples)i 3 XI Real First data point x value

a Yl Real First data point y value

3

•

ZI

•

Real

e

First data point z value

e

e

•2#3N

e

•2N

e

eReal

•

Last data point z value

124
106 - COPIOUS DATA

For IPs3 (x,y,2,i,j,k sextupies);

3 XI Real First data point x value

4 Yl Real First data point y value

3 21 Real First data point z value

6 11 Real First data point i value

7 :i Real First data point j value

S K1 Real First data point k value

•

e

2o^N

•

KN Real

•

Last data point k value

Additional pointers as required (see sec. 2.2.4.4.2).

125

271
^08 - PLANE

\ \

\ * \

\ \

I 1

I « I

I I 2 O

< to

127

272
CO

108 - PLANE

INGLE PARENT ASSOCIATIVITY AS USED WITH A COLLECTION

OF BOUNDO ?mZZ

128

273
112 - PARAMETRIC SPLINE CURVE

3.S Parametric Spline Cirvg Entity

(Consult Appendix 0 for additional mathematical details)

The parametric spline cxjrve is a sequence of parametric polynomial segments.

The CTYPE value in Parameter 1 indcates the type of curve as it was

represented in the sending (pre-processing) system before conversion to this

entity.

3.5.1 The N polynomial segments are delimited by the breakpoints T(l), T(2),

...,T(N^1). The coordinates of the points in the i-th segment of the cvrve are

given by the following cubic polynomials (the coefficients 0* or C and 0 will be

zero if the polynomials are of degrees 2 or I, respectively)!

j(e)«^(/)-*>ix(/) *!i4>cr(i) V4-ar(/> V

r(e)-^ r(/)+jy(/) *t^Dru) v

2(M)mA2i/)*M2U) •»*€2{i) •t^D2U) V

where

r-e-n/)

In order to avoid degeneracyt for each i at least one of the nine real coefficients,

BXQ), eXQ), OXQ), BYQ), CYU), OYQ), BZQ), CZQ), and OZQ) must be non-zero.

3.5.2 If the spline is planar, it must be parametrized in terms of the X and Y

polynomials only. The Z polynomial will then be zero except for each I, the AZQ)

term which indicates the Z-depth in definition space.

3.1.3 The parameter H Ls used as an indicator of the smoothness of the curve. If HsO,

the curve is continuous at all breakpoints. If Hal, the orve is continuous and

has slope continuity (see section 6.3 of FAUX79) at all breakpoints. If Ha2, the

ctrve is continuous and has both slope and cirvanjre continuity at all breakpoints

(see section 6.3 of Paux79).

132

274
112 - PARAMETRIC

3.S.4 To enabie determination oi the terminate point and derivatives without

computing the polynomials, the Nth polynomials and their derivatives are evaluated at u « T(N<*1)« These data are divided by appropriate factorials and

stored following the polynomial coefficients. For example, the name TPY3 will be used to designate 1/3! times the third derivative of the Y polynomial for the

Nth segment evaluated at u«T(N<^l), the parameter value corresponding to the

terminate point. Note that these data are redundant as they are derived from

the data defining the Nth polynomial segment.

3.S.3 An example of a parametric spline is shown in Figtre 3-7. Additional examples

are shown in Figure 3-S.

3.S.6 Directory Data

ENTITY TYPE NUMBER : 112

3.1.7 Parameter Data

Index Name I22S Deseriotion

1 CTYPE Integer Spline Type

(NLinear

2sQuadratic

3«Cubie

AaWilsofwFowler

SaModfied

WilsofwFowIer

gsB Spline)

2 H Integer Degree of coiv

tinuity with

respect to arc

length

3 NDIM Integer 2aplanar

3anon-planar

A N Integer Number of segments

3 T(l) Real Break points of

• • piecewise

• 3^N

•

T(N-l)

polynomial

133

275
CURVE

-(

X(U),

V(U).

Z(U)

),

FOR

T(U

$U

^

T(N»1)

N

-3

SEGNENfS

112 - PARAMETRIC SPLINE CURVE

W^

• • CM CM

CM

I

CM

CM CM CM

CM CM CM

O U)

CM CM CM

III

X ^

rM

134

276

FIGURE

3-7

EX/WPLE

OF

THE

PARMCTRIC

SPLINE

CURVE

ENFIIY
112 - parametric spline curve

135

277
- r'AnArttraic SPLiNt uwrtwi

Index Name Type Description

AX(1) Real X coordinate

polynomial

BX(1)

CX(l)

0X(1)

AY(1) Y coordinate

n*N BY(1) polynomial

12^N CY(1)

13-^N DY(1)

Ib^N A2(l) Z coordinate

IS^N BZ(1) polynomial

16^ CZ(1)

17^N 0Z(1)

e Subsequent X, Y, Z

e polynomials concludng

with the twelve

coefficients of the Nth

a polynomial segment.

(The parameters that follow comprise the evaluations of the polynomials of the Nth

and tftctr darivativcs at tha paramatar yaiua usT(N^l) corraspondinf to the

tarminata point. Subsequently these evaluations are divided by appropriate factorials.)

136

278
112 - PAflAMETRIC SPLIHE CURVE

TPXO Real X value

TPXl X first derivative

TPX2 X second derivative/ 2! TPX3 X third derivative/ 3t TPYO

TPYl

TPY2

Y value

TPY3

TP20

TP21

TP22

TP23

Z value

Additional Pointers as required (see 2«2.A.A.2)

Software to convert between parametric spline curves or surfaces and the corresponding

rational &-spUne curves or surfaces is available from the IGSS office at the National

Bureau of Standards. Materials provided include a magnetic tape of Pascal source code, a

listing of the cade, and accompanying documentation.

137

279
126 - RATIONAL B SPLINE CURVE

3.16 Rational S-Spline Entity

The rational B-spline curve may represent analytic curves of general interest.

This information is important to both the sending and receiving systems. The

directory entry form number parameter is provided to comminicate this information. It should be emphasised that use of this curve form should be

restricted to commimications between systems operating directly on rational ^

spline ctfves and not used as a replacement for the analytic forms for

communication. For a brief description of a rational B-spUne ewes, see Section

A of Appendix O.

If the rational B-spline orve represents a preferred ewe type, the form number

corresponds to the most preferred type. The preference order is from i through

3 followed by 0. For example, if the curve is a drele or circular are, the form

number is set to 2. If the cxrve is an ellipse with vmequal major and minor axis

lengths, the form msnber is set to 3. If the ewe is not one of the preferred

types, the form number is set to 0.

If the cvrve lies entirely within a unique plane, the planar flag (PROPl) is set to

I, otherwise it is set to 0. If it is set to I, the plane normal (parameters

ia<»A^4K through 16^A^AK) contain a tmit vector normal to the plane containing

the owe. These fields exist but are i^sored if the owe is nosvplanar.

169

280
126 ra::omal b splihe curve

II the beginning and ending points on the curve are identical, PROP2 is set to 1.

II they are not equal, PROP2 is set to 0.

If the curve is rational (does not have all weights equal), PROP3 is set to 3. If

all weights are equal to each other, the curve is polynomial and PROP3 is set to

1. The curve is polynomial since in this case all weights cancel and the

denominator sums to one (see Appendix 0%).

If the orve is periodic with respect to its parametric variable, set PROP4 to 1, otherwise set PROP4 to 0.

3.16.1 Directory Data

ENTITY TYPE NUMBER: 126

Form Meanine

0 Form of cvve must be determined from the rational B-spline

parameters.

1 Line

2 Circular arc

3 Elliptical arc

4 Parabolic arc

5 Hyperbolic arc

3.16.2 Parameter Deta

Index Name Description

1 K Integer Upper index of sum. See

Appendix D

2 M Integer Degree of basis

functions

3 PROPl Integer sO « noivplanar

si • planar

4 PROP2 Integer sO - open curve

si - closed oa-ve

3 PROP3 Integer sO - rational

si - polynomial

6 PROP4 Integer sO - nonperiodic

al - periodic

Let NsK.M<».l and let A*N-2M

170

281
126 - RATIONAL B SPLINE SURFA

7

•

T(-M)

•

Real Knot Sequence

•

7*^

• T(N»M)

e

W(0)

0

Real Weights

•

•

•

• woo

XO Real Control Points

\0*A*K YO

ll^A^K

•

ZO

•

•

s

•

• XK

104>A<i>AK YK

iUAi>4K ZX

12«A^AK V(0) Real Starting parameter value

13<I<A<KAK V(l) Real Ending parameter value

ia4.A<i>aK XNORM Real Unit Normal Qf curve is planar)

13<kA<k4K YNORM

16<kA<kAK ZNORM

Additional Pointers as required (see 2.2.^.4«2).

Software to convert between parametric spline curves or surfaces and the corresponding

rational ^-spline curves or surfaces is available from the ICES office at the National

Bureau of Standards* Materials provided include a magnetic tape of Pascal source code« a

listing of the code, and accompanying documentation.

171

282
Appendix D. CGM Extracts

283
Graphic*! Primitive Elements Abstract Specification of Element

.3.1.10 GENERALIZED DRAWING PRINIITINE fGDP)

Paramtcers:

. i'-nnii-*r I

.

point iiat , llP' -Jata record i D)

Descriptioa:

A Generalued Drawing Primitive I GDP' of the type specified by the identifier is fener.ireo on the

-basis of the fiven points and the data record. \’on-net;auve \aluc# of t!ie i lenfilt<-r ar» reserved for re^i-truion ind funire -r ondar litat ion. ind negative values are available for private use The appearance of the GDP is determined by tero or more of the actnbute sets of the standard*

lied graphical primitive elements, depending on the particular GOP The parameters of the GOP

are interpreted and utilized in an interpreter dependent manner NOTE • GOP provides convenient access to non*«tandardized graphical primitives that a device may support. GOP is similar to ESC.APE in this sense, but GOP provides a mechanism for han*

dling of coordinate data whereas ESCAPE does not. GOP is thus preferable for generating

graphical output, and ESCAPE is designed for such applications as non«standardized control

fuactions. ^ When registration of GDPs occurs there may be regutcred GDPs which correspond with some of the standardised metafile graphical primitive elements, e.g.. CIRCLE.

GDP identifiers are registered in the ISO International Register of Graphical Items, which is maintained by the Registration .Authority VVhen a GDP identifier has been approved by the ISO Working Group on Computer Graphics, the GDP identifier v-iiue will be assigned by the Regutra*

tion .Authority

Refsroaesst

4 9

70 A.N5I X3.122 . 1988 Part I

284
Escape Elements Abstract Specification of Elements

5.8 Escape Elements

5.8.1 ESC.APE

Parameters:

function identifier (I) data record (D)

Description: ESC.APE provides access to devic* ••apabilif les not specified hy this 5randard. The function

identifier parameter specifies the particular escape function. .Non-ne^ative values tvre reserved for refistraiion and future standardization, and negative values are available for implementation

dependent use. NOTE • This element has been deliberately underspecified. Software making use of the ESC.\PE

element is less portable. ESC.APE is designed for access to non-standardized control features of graphics devices, as opposed to non-stanaardized geometnc primitives. The GENERALIZED DR.AWING PRIMITPi'E

element is designed for specification of non*staadardized primitives. Function id8htifiers are registered in the ISO International Register of Graphical Items, which is maintained by the Registration Authority. When a function identifier has been approved by the ISO Working Group on Computer Graphics, the function identifier value will be assigned by the Registration Authority.

Rcferoneew

4.8

98 .A.N3I X3.122 - 1988 Part I

285
Abstract Specification of Elements External Elements

5.9 External Elements

5.9.1 MESSAGE

Parameters:

action required fla? (one of no action, action) (E)

text (S)

Deseriptionf

The ME5S.-\CtE element >p**<*irie? a 'trm^ of characters u«ed to comrminic.ite information to operators at Metatile interpretation 'ime through a path .-eparafe from normal graphical output

If the action required Ha; parameter is action . the metafile interpreter may need to pause to wait for an operator response Because the message and an associated pause may be directed at a particular device, only the interpreter may determine if a pause is appropriate. Character <et selection for the text parameter is independent of any character set selection specified by this standard.

References:

4.9

5.9.2 APPLICATION DATA

Parameters:

identifier (I) data record (0)

Description:

This element supplements the information in the metafile in an application-dependent way It has no effect on the picture generated by interpreting the metafile, or on the states of the

metafile generator or interpreter

The content of the identifier and data record parameters is not standardized NOTE - The contents of the data record may include such information as history data associated with pictures, description of algorithms used. etc.

References:

4 9

A.NSI X3.122 - 1988 Part I 99

286
NBS«n4A (REV. 2«ac) U.S. DEPT. OF COMM. 1. PUBLICATION OR 2. Performing Organ. Report No. 3. Publication Date

BIBLIOGRAPHIC DATA

REPORT NO.

MARCH

SHEET (See instructions) NBSIR 88-3728

4. TITLE AND SUBTITLE

CGM REGISTRATION FOR CALS REQUIREMENTS

A Technical Study Completed for the Computer-aided Acquisition &

Logistic Support (CALS) Program - Fiscal Year 1987 (Vol. 3 of 4)

5. AUTHOR(S)

Edited by Sharon J. Kemmerer

6. PERFORMING ORGANIZATION (If joint or other than NBS, see instructions)

NATIONAL BUREAU OF STANDARDS

U.S. DEPARTMENT OF COMMERCE

GAITHERSBURG, MD 20899

7. Contract/Grant No.

8. Type of Report & Period Covered

SIBSIR, 10/86 through

9/87

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street, City, State, ZIP)

Office of Assistant Secretary of Defense (A&P)/WSIG

Department of Defense, Pentagon

Washington, DC 20301-8000

10. SUPPLEMENTARY NOTES

I ! Document describes a computer program; SF-185, FlPS Software Summary, is attached.

11. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bi bl iography or literature survey, mention it here)

The overall objective of the Department of Defense Computer-aided

Acquisition Sc Logistic Support (CALS) Program is to integrate the

design, manufacturing, and logistic functions through ^ the

efficient application of computer technology. The National

Bureau of Standards has been funded since Spring 1986 to

recommend a suite of industry standards for system integration

and digital data transfer, and to accelerate their

implementation. A major FY87 thrust was the completion of

initial documentation of the high-priority standards required in

the CALS environment. Volumes one, two and four provide a

collection of the final reports presented to the CALS Policy

Office. They cover such topics as text, product data, data

management, raster compression, media, conformance testing, and

grap.l'dcs. This volume specif.cally addresses Computer Graphics

Metafile (CGM) registration requirements for CALS.

12. KEY WORDS fS/x to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolon s) CALS; CGEM; CGM; DoD; graphics; interpress; PostScript; registration

13. AVAILABILITY

!

I For Official Distribution. Do Not Release to NTIS

'PP Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402. A_ Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

29 7

15. Price

$ 24.95

USCOMM-OC 6043-P80
01 I9*>l 109 .T«»0 ^.U

ATM

3JT1T > I 1 yOITAHTaiOaH KDD

XcDxnilofijT A

E .16V)I'T88X 5aeV Isaal’S -.«W3B0a*I (EJA3» ^:ioqqu3 siaaipoJ

'""~ -' - 'H -«,,». ik-i .

»ti .26 M i*mo i*

(2)flO>^UA

«T:0nin»?l .ti nott&d8 yd

sDitaMiAOO TvgicriUTOr2>g

>e»i <XM

TO

' i^£ ZdJlAOHATt lO aAMUH lAKOfTAH

'"“’*^ .'. •‘* "<'T|ggii i " aWdOA hi*<k'»Uw'^rrA;i>i>^M'atti^

’«M» ao yt63»io*8 inisaisaA io eo^ilO ^ '»<»-iW ' •-“'t[ffc|||f||B . j«|noewn»1 ,»an9loa 5o 3.i^'ni3-x»<j*a

• OomtMwv 0008-I0£0r oa ,!ioapnxda«W

T>.i^|S.>t»t .!«»' *'»>»'* 1 *'i*5 • •'"«•»*«• i«

I .. 'X 1 ....?_ -If ^ J t jiSjAMipy* **B'*t^>- * Iw tM p***em*<*i ^7

^' '

. o. . . - . - . _ ' A ikjh IQ —- — • i lOtfi iiAAiA*

, ''?%« for •» ap*r%*<rr •• «n*^‘*w4' !*of ^

tA* • «* «v*»v# « t OM#*r^i' »**i •* rnUmim »*oiil*6 *r »A'* ,^Voe ;^>|o>0 ^Wi»woo « »»<«VO«L*«>

*K.

bsbis-isauqmoD aensisa 5o ansffiJiBqaO srfa 3o aviio»t^o llsi&vo arfT

mBiCO-iS (3JA3) Jioqqua siaelpoJ 2 noiaiaiupoA

« aria ripwoiria 2/i<5Jao(tu3 oXaalpoX ,pnl.axjao*3unBm ,npl8»b

XBno!i!*JWrW!T "* laax-qmos 3o noiaBaXIqq* aasiailSa

.oaspSaBA^SoBlacjE atJflle bsbuuJ aaad sari ebiBbnBae lo L-esaiJS

noXaB-j^pfarf# »t»a8Y« ao3a abiabOBaa viaew&fl-i 3o aaiy* b bnanmooaa

..-t >«f<

p

: a.

, aaa«IsssB . ' da bnfi ,aoi#nBaa * eaeb XBaipib ^tcia

3o ®nol3a#ij<t«<i>a»*»i'*«iiB ftKa0W T«<i»<6M’a«iB»-«‘C8iV8 -»i<ioi*i%i"«Ai'’ ”»»rioiaBaiiafli9-iqiiu

ni b9^il«djKaBi«OT5S?d'»?mwi‘«?^ 9«3‘*Ib'* fte>»«ah8Aiu»ob Xaiaini

B abxypaq owa "".ano BamuXoV . anemnoaivn® 2JA9 stla

Y3xXo’rSa*9'id!»'*^‘irb»VA'Aa'S^^ »ri? io noiaasXXoo

fbfiB ,nol829tiqmoo

t ,^oiri«ifr;5£L^:^uqmoO 89«0dibb9 YXlACxlxooqB smxilov airiT .KUiff^'psTp

A - >i; . .. ^ .aJA!) iolt8:Jn9/n9i.i.x/p93 noi^ft“i:5aJ:g90 (KDO) slilfcOsM

^^noiaBiaaxBea,.saqiaoaa8b^miBe*25a*='‘’^ tspidqBxp ;OoO -.K33 .M30D \H-A3

.'',iWBsa0^^ B

' . 'hi

,0M

oyrvilHV

laW'i-'lliB i

'l^

all tAi _

o» JoM *0 .oo«»ijii-»»t*a »oi9n»C '*0^ O

^ ****^"*‘***;;^v^.^

>0 *noJ>r^»«»»Ou2 J

^

JUn^pW«BK

^

^ (*UI®lv .»l.iV|Wi^,,lSlTM:i «.*'»« <*.l»-mo'"l l.nol»tt «.’=< ’t’O ^ ;C

l>,