• - to allow very highly interactive graphics application programs using 2D or 3D hierarchically structured graphics data to be easily transported between installations. This will reduce costs associated with the transfer of programs among different computers and graphics devices, including replacement devices.

• - to aid the understanding and use of dynamic hierarchical graphics methods by application programmers.

• - to aid manufacturers of graphics equipment by serving as a guideline for identifying useful combinations of graphics capabilities in a device.

• - to encourage more effective utilization and management of graphics application programmers by ensuring that skills acquired on one job are transportable to other jobs, thereby reducing the cost of graphics programmer retraining.

• - to aid graphics application programmers in understanding and using graphics methods by specifying well-defined functions and names. This will avoid the confusion of incompatibility common with operating systems and programming languages.

9.1 The FIPS for PHIGS is intended for use in computer graphics applications that are either developed or acquired for government use. It is specifically designed to meet the performance requirements of such demanding applications as Computer Aided Design/Computer Aided Engineering/Computer Aided Manufacturing, command and control, molecular modelling, simulation and process control. It emphasizes the support of applications needing a highly dynamic, highly interactive operator interface and expecting rapid screen update of complex images to be performed by the display system. The PHIGS PLUS functionality is designed to support graphics applications requiring lighting and shading, curved lines, curved and facetted surfaces, and non-indexed color specification.

9.2 The use of this standard is compulsory and binding when one or more of the following situations exist:

• - The graphics application is very highly interactive, or contains hierarchically structured graphics data, or requires rapid modification of 2D or 3D graphics data and the relationships among the data.

• - It is anticipated that the life of the graphics program will be longer than the life of the presently utilized graphics equipment.

• - The graphics application or program is under constant review for updating of the specifications, and changes may result frequently.

• - The graphics application is being designed and programmed centrally for a decentralized system that employs computers of different makes and models and different graphics devices.

• - The graphics program will or might be run on equipment other than that for which the program is initially written.

• - The graphics program is to be understood and maintained by programmers other than the original ones.

• - The graphics program is or is likely to be used by organizations outside the Federal government (i.e., State and local governments, and others).

10. Specifications. American National Standard Programmer's Hierarchical Interactive Graphics System, ANSI/ISO 9592.1-3:1989 and ANSI/ISO 9592.1a,2a,3a,4:1992, define the scope of the specifications, the syntax and semantics of the PHIGS elements and requirements for conforming implementations. All of these specifications apply to Federal Government implementations of this standard.

ANSI/ISO 9592.1-3:1989 and ANSI/ISO 9592.1a,2a,3a,4:1992 define a language independent nucleus of a graphics system for integration into a programming language. Thus, it is embedded in a language layer obeying the particular conventions of the language. FIPS 153-1 is therefore divided into two parts. Part 1 represents the functional aspects of PHIGS. Part 1 consists of the following:

(1) Functional description (ANSI/ISO 9592.1:1989) and (ANSI/ISO 9592.1a:1992, Amendment 1)

The functional description of PHIGS provides a set of functions for the definition, display and modification of 2D or 3D graphical data. It also provides for the definition, display and manipulation of geometrically related objects, along with the modification of graphics data and the relationships between that graphical data.

(2) Archive file format (ANSI/ISO 9592.2:1989) and (ANSI/ISO 9592.2a:1992, Amendment 1)

The archive file provides a file format suitable for the storage and retrieval of PHIGS structures and structure network definitions. It allows structure definitions to be stored in an organized way on a graphical software system. It also facilitates transfer of structure definitions between different graphical software systems.

(3) Clear-text encoding (ANSI/ISO 9592.3:1989) and (ANSI/ISO 9592.3a:1992, Amendment 1)

The clear-text encoding provides a representation of the archive file syntax that is easy to type, edit and read. The file is human-readable (allows editing), human friendly (easy and natural to read) and machine readable (parsable by software).

(4) Plus Lumiere and Surfaces, PHIGS PLUS (ANSI/ISO 9592.4:1992)

The Programmer's Hierarchical Interactive Graphics System (PHIGS) Plus Lumiere and Surfaces (PHIGS PLUS) extends the basic PHIGS functionality by adding facilities for the specification of curved lines, curved and facetted surfaces, lighting and other effects such as depth modulation.

• - The FORTRAN Language binding for PHIGS (ANSI/ISO 9593.1:1992), and for PHIGS PLUS (ANSI/ISO 9593.1:1991/AM1);

• - The ADA Language binding for PHIGS (ANSI/ISO 9593.3:1990), and for PHIGS PLUS (ANSI/ISO 9593.3:1991/AM1);

• - The C Language binding for PHIGS (ANSI/ISO 9593.4:1991), and for PHIGS PLUS (ANSI/ISO 9593.4:1991/AM1).

11.1 Effective Date. This revised standard is effective August 1, 1995. Requirements for the use of basic PHIGS functionality (defined in ANSI/ISO 9592.1-3:1989 and ANSI/ISO 9593.1:1992, 9593.3:1990, 9593.4:1991) are unchanged and continue in effect. Validation of PHIGS implementations is required after the effective date in accordance with Section 11.4.

11.2 Acquisition of Implementations. Conformance to FIPS for PHIGS is required whether PHIGS toolbox packages are developed internally, acquired as part of an ADP system procurement, acquired by separate procurement, used under an ADP leasing arrangement, or specified for use in contracts for programming services. Recommended terminology for procurement of FIPS for PHIGS is contained in the U.S. General Services Administration publication Federal ADP & Telecommunications Standards Index, Chapter 4 Part 1.

11.3 Interpretation of this FIPS. NIST provides for the resolution of questions regarding FIPS for PHIGS specifications and requirements, and issues official interpretations as needed. Procedures for interpretations are specified in FIPS PUB 29-3. All questions about the interpretation of FIPS for PHIGS should be addressed to:

Director
Computer Systems Laboratory (CSL)
ATTN: PHIGS Interpretation
National Institute of Standards and Technology
Gaithersburg, MD 20899
Telephone: (301) 975-3265

11.4 Validation of PHIGS Implementations. Implementations of FIPS for PHIGS using either FORTRAN or C bindings shall be validated in accordance with NIST Computer Systems Laboratory (CSL) validation procedures for FIPS for PHIGS. Recommended procurement terminology for validation of FIPS for PHIGS is contained in the U.S. General Services Administration publication Federal ADP & Telecommunications Standards Index, Chapter 4 Part 2. This GSA publication provides terminology for three validation options: Delayed Validation, Prior Validation Testing, and Prior Validation. The agency shall select the appropriate validation option. The agency is advised to refer to the NIST publication Validated Products List for information about the validation status of PHIGS products. This information may be used to specify validation time frames that are not unduly restrictive of competition.

The agency shall specify the criteria used to determine whether a Validation Summary Report (VSR) or Certificate is applicable to the hardware/software environment of the PHIGS implementation offered. The criteria for applicability of a VSR or Certificate should be appropriate to the size and timing of the procurement. A large procurement may require that the offered version/release of the PHIGS implementation shall be validated in a specified hardware/software environment and that the validation shall be conducted with specified hardware/software features or parameter settings; e.g., the same parameter settings to be used in a performance benchmark. An agency with a single-license procurement may review the Validated Products List to determine the applicability of existing VSRs or Certificates to the agency's hardware/software environment.

PHIGS implementations using either FORTRAN or C bindings shall be validated using the NIST PHIGS Test Suite, a suite of automated validation tests for PHIGS implementations. The NIST PHIGS Test Suite was first released in July 1990 to help users and vendors determine compliance with FIPS for PHIGS. The most recent version of the test suite will be used for validating conformance of PHIGS implementations after the effective date of FIPS PUB 153-1. The results of validation testing by the PHIGS Testing Service are published on a quarterly basis in the Validated Products List, available from the National Technical Information Service (NTIS). See related documents section.

Each release of the test suite has provided additional language bindings and test cases to increase the test suite's coverage of PHIGS functionality. Version 2.1 of the NIST PHIGS Test Suite, released in April 1994, provides testing for PHIGS implementations using either the FORTRAN or C language binding. Version 2.1 does not include tests for the functionality of PHIGS PLUS added by this revision of FIPS for PHIGS.

Current information about the NIST PHIGS Validation Service and validation procedures for FIPS for PHIGS is available from:

National Institute of Standards and Technology
Computer Systems Laboratory
Graphics Software Group
Building 225, Room A266
Gaithersburg, MD 20899
(301) 975-3265

12. Waivers. Under certain exceptional circumstances, the heads of Federal departments and agencies may approve waivers to Federal Information Processing Standards (FIPS). The head of such agency may redelegate such authority only to a senior official designated pursuant to section 3506(b) of Title 44, United States Code.

Waivers shall be granted only when:

a. Compliance with a standard would adversely affect the accomplishment of the mission of an operator of a Federal computer system, or

b. Cause a major adverse financial impact on the operator which is not offset by Governmentwide savings.

When the determination on a waiver applies to the procurement of equipment and/or services, a notice of the waiver determination must be published in the Commerce Business Daily as a part of the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that notice is published, by amendment to such notice.

A copy of the waiver, any supporting documents, the document approving the waiver and any supporting and accompanying documents, with such deletions as the agency is authorized and decides to make under 5 U.S.C. Sec. 552(b), shall be part of the procurement documentation and retained by the agency.

13. Where to Obtain Copies. Copies of this publication are for sale by the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. (Sale of the included specifications document is by arrangement with the American National Standards Institute.) When ordering, refer to Federal Information Processing Standards Publication 153-1 (FIPSPUB153-1) and title. Payment may be made by check, money order, or deposit account.

The Family of Graphics Standards

The following computer graphics standards are now available to address the needs of government applications in creating, modifying, manipulating, and exchanging computer-generated pictures:

• FIPS PUB 120-1, the Graphical Kernel System (GKS), which adopts ANSI X3.124-1985;

• FIPS PUB 153-1, the Programmer's Hierarchical Interactive Graphics System (PHIGS), which adopts ANSI/ISO 9592-1989;

• FIPS PUB 128-1, the Computer Graphics Metafile (CGM), which adopts ANSI/ISO 8632-1992 and

• FIPS PUB 177, the Initial Graphics Exchange Specification (IGES), which adopts ASME/ANSI Y14.26M-1989.

These standards fall into two categories: Application Programmer's Interface (API) standards, and Interoperability standards. The goal of API standards is to enhance the portability of graphics programs (and programmers) between installations and environments. The goal of Interoperability standards is to enable graphics data to be exchanged successfully between graphics systems and devices.

Figure 1 is a very simple reference model of a computer graphics operating environment. The model emphasizes that a graphics application program interacts with physical devices and human operators via a computer graphics environment. Figure 1 also shows that the application may receive information from an external database.

The output of the graphics program, as shown in Figure 1, is directed to a virtual graphics device (i.e., Virtual Device Interface or VDI) rather than directly to a physical device. A Device Driver provides an interface, implemented in either hardware or software, for translating virtual device commands to commands understood by a particular physical device. By substituting one device driver for another, an application can run on a different physical device. This device independence is a central concept of this graphics reference model.

In Figure 1, the API standards reside in the box labelled the Device Independent Graphics Package. Interoperability standards are related to the boxes in Figure 1 labelled Metafile, Database and Virtual Device Interface. Figure 2 depicts the various graphics standards associated with the general model shown in Figure 1. These are discussed below.

Application Programmer's Interface (API) Standards

Standards at the API promote program and programmer portability. A standard at this level specifies a set of operations on a variety of graphics objects. An API standard provides for the portability of applications across a wide range of computer hardware, operating systems, programming languages, and graphics devices. A program written to an API standard at one facility in one environment should be easily transferable to another facility in a different environment. Facility dependencies should be the major area requiring modification.

The specific functions supported by a particular API standard provide certain capabilities. The application programmer, by identifying the capabilities needed, determines the API better suited for the application. As shown in Figure 2, there are currently two graphics API standards, GKS and PHIGS.

GKS provides a functional description of a two-dimensional (2D) graphics interface. It provides the basic graphics support required by a wide variety of applications requiring the production of computer-generated pictures. A procedural language binding of a functional standard specifies the exact name for each operation, its parameter sequence, and the data types for the parameters. FORTRAN, Pascal, Ada and C language bindings are parts of GKS.

GKS is suitable for use in graphics programming applications that employ a broad spectrum of graphics, from simple passive graphics output (where pictures are produced solely by output functions without interaction with an operator) to interactive applications; and which control a whole range of graphics devices, including but not limited to vector and raster devices, microfilm recorders, storage tube displays, refresh displays, and color displays.

PHIGS provides for the definition, display, modification, and manipulation of 2D and 3D graphical data. It provides functionality to support storage of graphics and application data in a hierarchical form. Information may be inserted, changed, and deleted from the hierarchical data storage with the functions provided by PHIGS. Language binding specifications for PHIGS include FORTRAN, C and Ada.

PHIGS is specifically designed to meet the performance requirements of such demanding applications as Computer Aided Design/Computer Aided Engineering/Computer Aided Manufacturing, command and control, molecular modelling, simulation and process control.

Capabilities in PHIGS but not in GKS include: the centralized hierarchical data storage; the dynamic and responsive nature of interactions; the addition of a modeling capability; and support for color models other than Red-Green-Blue (RGB).

Interoperability Standards

Graphics Interoperability standards allow graphical data to be interchanged between graphics devices. As shown in Figure 2, there are three graphics interoperability standards, CGM, (future) CGI, and IGES.

CGM is used for the storage and transfer of picture description information. It enables pictures to be recorded for long term storage, and to be exchanged between graphics devices, systems, and installations. As indicated in Figure 2, the storage mechanism for CGM is in the form of a neutral file format called a metafile. The software which creates the metafile is known as a CGM Generator. The software which reads and displays a CGM metafile is known as an Interpreter.

CGM specifies a semantic interface that describes 2D graphical entities using primitives (like polyline, text, and ellipse) and attributes (like color, line width, interior style, and fonts). CGM is compatible with the specification of 2D elements in GKS. A data encoding specifies the exact sequence of bits used to represent each operation and its parameters. CGM contains three types of data stream encodings (binary, character, and clear text) to provide the implementor choices depending on the particular application.

IGES provides a method for representing and storing geometric, topological, and non- geometric product definition data that is independent of any one system. Where CGM transfers graphical pictures, IGES transfers a graphical database which can be processed to represent a picture. Thus IGES represents more than just purely graphical data. As Figure 2 indicates, the storage mechanism for IGES is in the form of a neutral file format that must be translated by a Preprocessor and Postprocessor for conversion between systems. IGES permits the compatible exchange of product definition data used by various computer aided design/computer aided manufacturing (CAD/CAM) systems.

The future CGI standard is designed to specify the exchange of information at the Virtual Device Interface. It will provide an interface between the device independent and device dependent parts of a graphics system. Since CGI contains information at a virtual level, it can be used to create a CGM. A CGM can also be output on a CGI device in a straightforward manner.