Computer Graphics Metafile
The Computer Graphics Metafile (CGM) is a family of free and open international standards for the storage, transfer, and interchange of two-dimensional vector graphics, raster graphics, and text, providing a neutral, platform-independent representation of picture description information suitable for use across diverse applications, systems, and devices.[1] Defined by ISO/IEC 8632, it structures graphical data as an ordered set of elements grouped into metafiles, pictures, and optional application structures, enabling both sequential and random access while supporting features like directories for navigation without full interpretation.[2] CGM originated in the late 1970s from efforts by the SIGGRAPH Graphics Standards Planning Committee but was formally standardized as ANSI X3.122 in 1986, followed by ISO 8632 in 1987, with subsequent versions (1 through 3 by 1992) introducing enhancements like raster support (in Version 3); the current edition, Version 4 (ISO/IEC 8632-1:1999), added application structuring and metadata capabilities via extensible structures while maintaining backward compatibility.[1] The standard comprises four parts: Part 1 for functional specification, Part 2 for character encoding (describing logical elements and withdrawn in 2001 due to lack of implementation), Part 3 for binary encoding (compact and widely used), and Part 4 for clear-text encoding (human-readable but less efficient).[2] These encodings allow CGM files to represent primitives such as polylines, ellipses, text strings, and raster blocks, making it versatile for static image exchange without device-specific dependencies.[1] CGM has been widely adopted in technical and engineering fields, including aerospace documentation (e.g., ATA Spec 100), automotive standards (e.g., J2008), and interactive technical publications (e.g., S1000D and CALS), where its small file sizes and editability support efficient data sharing in CAD and publishing workflows.[1] A key profile, WebCGM (a profile of ISO/IEC 8632 and W3C Recommendation, with version 2.1 published in 2010), adapts CGM for web environments by restricting features for scalability, adding hyperlinking, layers, object visibility, and a Document Object Model (DOM) for scripting integration with HTML, enabling interactive graphics in browsers for technical illustrations and visualizations.[3] Despite its robustness as an open standard, CGM's usage has declined in general consumer software due to limited native support, though it remains vital in specialized industries for its interoperability and longevity.[1]Introduction
Definition and Purpose
The Computer Graphics Metafile (CGM) is an international standard defined by ISO/IEC 8632 for the storage, transfer, and interchange of two-dimensional (2D) vector graphics, raster content, and text.[2] It specifies a file format that enables the description of static pictures in a device-independent manner, allowing compatibility across diverse hardware architectures, software systems, and rendering devices.[1] Developed as a neutral representation, CGM supports both graphical primitives for vector-based elements and mechanisms for incorporating raster images, making it suitable for technical illustrations, engineering diagrams, and other vector-oriented applications.[4] The primary purpose of CGM is to facilitate portable graphics exchange without reliance on proprietary formats, particularly in technical and engineering environments where interoperability is essential.[5] By providing a standardized, application-independent structure, it enables the capture, storage, and rendering of graphical data across heterogeneous systems, reducing barriers to collaboration and data sharing.[6] This device independence is achieved through abstract coordinate systems, such as Virtual Device Coordinates (VDC), which decouple the picture description from specific output devices.[1] At its core, a CGM functions as a metafile, comprising an ordered sequence of graphics commands—including primitives (e.g., lines, polylines, text), attributes (e.g., colors, line styles), and control elements—that instruct an interpreter to reconstruct the intended image rather than embedding raw pixel data directly.[6] This command-based approach contrasts with raster formats by emphasizing scalable, resolution-independent descriptions, which are efficient for vector content while allowing raster integration for complex images.[4]Scope and Standards
The Computer Graphics Metafile (CGM) is scoped to two-dimensional (2D) graphics interchange, encompassing vector primitives such as lines, polylines, polygons, and ellipses; raster images via tile elements; text representation; and control elements for metafile structure and descriptor information.[1] It deliberately excludes three-dimensional (3D) modeling, animation sequences, and interactive features to maintain focus on static picture description for storage, transfer, and archival purposes across diverse systems.[1] The CGM standard is defined by ISO/IEC 8632, comprising four parts: Part 1 specifies the functional elements, architecture, profiles, and conformance requirements; Part 2 addresses character encoding (withdrawn in 2001); Part 3 details binary encoding for compact, efficient representation; and Part 4 outlines clear-text encoding for human-readable interchange.[1] In the United States, the 1992 version of this international standard was adopted as Federal Information Processing Standard (FIPS) PUB 128-2 in 1996, which mandated its use by federal agencies for graphical data exchange involving 2D vector, raster, and text elements until its withdrawal in 1998.[7][8] Conformance to CGM is established through profiles outlined in ISO/IEC 8632-1, ensuring reliable interchange by defining subsets of elements, parameters, and options.[1] The basic interchange level supports minimal portability with core 2D primitives and encodings, while application profiles tailor the standard to domain-specific needs—such as the Model Profile for general use or industry variants like CALS—for enhanced compatibility and validation of generators and interpreters.[7][1] CGM achieved international alignment through ANSI adoption of ISO/IEC 8632, facilitating cross-system use in sectors like aerospace and technical publishing.[7] Its binary encoding was registered as the MIME media type image/cgm on October 31, 1995, enabling standardized web and email transmission of CGM files with required parameters for version and profile identification.[9]History
Development and Standardization
The development of the Computer Graphics Metafile (CGM) traces its origins to the late 1970s, evolving from foundational graphics standards such as the Graphical Kernel System (GKS, later formalized as ISO 7942:1985) and the Initial Graphics Exchange Specification (IGES) for computer-aided design (CAD) data interchange.[10] These early efforts addressed the need for device-independent graphics representation amid growing fragmentation in graphics software and hardware. In the early 1980s, the initiative gained momentum through collaborative work by the American National Standards Institute (ANSI) X3H3 committee, which proposed the Virtual Device Metafile (VDM) in 1981 as a precursor, and the European Computer Manufacturers Association (ECMA), focusing on metafile concepts for storage and transfer of picture data.[10] Key milestones in CGM's standardization included the drafting of functional specifications around 1985, leading to the approval of ANSI X3.122-1986 in August 1986, which outlined the core elements in four parts: functional specifications, character encoding, binary encoding, and clear text encoding.[10] This was rapidly advanced internationally, culminating in the first ISO approval as ISO 8632:1987, a comprehensive standard for 2D vector graphics interchange.[11] The standard's creation was notably influenced by U.S. Department of Defense (DoD) requirements under the Continuous Acquisition and Life-Cycle Support (CALS) initiative, which sought reliable formats for technical illustrations in military documentation and logistics.[12] Standardization was led by the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) Joint Technical Committee 1/Subcommittee 24 (JTC1/SC24) for computer graphics, with significant contributions from the U.S. National Institute of Standards and Technology (NIST) and various national bodies, including ANSI and ECMA, to ensure broad consensus.[13][10] In the United States, NIST facilitated adoption as Federal Information Processing Standard (FIPS) PUB 128 in 1988 (with full implementation guidelines by 1990), mandating its use in federal systems to promote uniformity.[10] This process involved integrating character sets like ISO 2022 and coordinating with related standards for seamless interoperability. A primary challenge CGM addressed was vendor lock-in in proprietary graphics software, where incompatible formats hindered data exchange across systems from different manufacturers.[10] By promoting open, extensible standards with multiple encoding options (binary for compactness, clear text for readability), CGM fostered global interoperability, enabling portable graphics for archiving, transfer, and multi-vendor environments without reliance on specific hardware.[10] The inclusion of an ESCAPE mechanism further allowed limited device-dependent extensions while preserving core portability.[10]Versions and Profiles
The Computer Graphics Metafile (CGM) standard, defined by ISO/IEC 8632, has evolved through several versions to address growing needs in graphics interchange. The initial version, CGM:1987 (ISO/IEC 8632:1987), established the core framework for storing and transferring 2D vector graphics, including basic elements like lines, polylines, and text, across four parts covering functional specifications, character encoding, binary encoding, and clear-text encoding.[1] This version focused on device-independent picture description, enabling portability without raster support at the outset.[2] Subsequent revisions introduced enhancements based on implementation feedback and technological advancements. The 1992 revision (ISO/IEC 8632:1992) expanded functionality with over 30 new elements in Version 2 for closed figures and graphical segments, and more than 40 in Version 3 for raster support via compressed tiled images and symbol libraries, improving compatibility with mixed vector-raster content.[1] Amendments followed, including ISO/IEC 8632:1992/Amd.1:1994 for profile rules and conformance testing, and Amd.2:1995 for initial application structuring.[7] The current version, CGM:1999 (ISO/IEC 8632:1999), incorporated these amendments fully while adding features like the Font Properties element to enhance text rendering and font handling, along with refined application structuring for hierarchical graphics organization.[1][14] Binary encoding has remained stable across versions, ensuring backward compatibility for existing implementations.[7] These revisions were driven by practical feedback from early adopters, the demand for web-compatible graphics, and alignment with related ISO standards such as the Graphical Kernel System (GKS).[15] To promote interoperability in specialized domains, CGM introduced the concept of profiles—constrained subsets of the full standard that define mandatory and optional elements, ensuring conformance for particular applications like technical documentation.[7] Early profiles targeted defense and aviation sectors. The Continuous Acquisition and Life-cycle Support (CALS) profile, specified in MIL-D-28003A and first amended in 1991, restricted CGM to Version 1 with binary encoding for US military technical illustrations, emphasizing simplicity and raster exclusion.[1][7] Similarly, the ATA Spec 2000 profile, used in aviation technical data like iSpec 2200, adopted Version 3 with binary or clear-text encoding to support complex diagrams in aircraft maintenance.[1][7] Modern profiles, such as WebCGM, further adapt CGM for web environments.[3]Technical Overview
File Structure
The Computer Graphics Metafile (CGM) adopts a hierarchical file organization divided into a prologue, which serves as the metafile descriptor containing essential metadata, and a picture body that holds the graphical content, with the entire structure bounded by mandatory delimiter elements Begin Metafile and End Metafile.[1] This division ensures that the file's global parameters are established before the rendering-specific content, facilitating device-independent interchange as defined in ISO/IEC 8632-1:1999.[2] The prologue begins immediately after the Begin Metafile delimiter and includes key elements such as the Metafile Description, which specifies the CGM version, character encoding, and other identification details to inform interpreters of the file's capabilities and format.[16] It also encompasses the VDC (Virtual Device Coordinates) Extent element, which defines the coordinate system's bounding rectangle and precision, typically using real-number or integer representations to establish the spatial framework for all subsequent graphics.[1] Additionally, the Background Color element is specified here or in picture descriptors, setting the default canvas color in supported models like RGB or indexed colors to ensure consistent rendering initialization.[16] These prologue elements collectively configure the metafile's precision, units, and environmental parameters without delving into specific visuals. The picture body follows the prologue and comprises one or more independent pictures, each delimited by Begin Picture and End Picture elements, allowing complex documents to organize content into modular sections such as pages or diagrams.[1] Within each picture, elements are categorized into descriptor functions (e.g., per-picture VDC adjustments), control functions (e.g., viewport transformations), and graphics functions (e.g., primitives and attributes), processed in a strictly sequential manner during interpretation to build the output image.[16] This logical flow supports efficient parsing and rendering, where interpreters execute elements in order, applying state changes cumulatively, and the support for multiple pictures enables structured representations like multi-page technical illustrations while maintaining overall file cohesion.[1]Graphical Elements
The Computer Graphics Metafile (CGM) defines graphical elements as the fundamental components for describing 2D pictures, categorized into primitives for drawing shapes and text, attributes for styling those primitives, and controls for managing rendering context. These elements operate within a Virtual Device Coordinate (VDC) system, where coordinates are specified relative to a normalized device space.[1][2]Primitives
Graphical primitives in CGM include vector-based elements for scalable line art, raster elements for bitmap data, and text elements for character rendering. Vector primitives such as Polyline connect a sequence of points defined in VDC coordinates to form open paths, while Polygon closes the path by connecting the last point to the first for filled or outlined areas (both introduced in Version 1, 1987).[3][10] Other vector primitives encompass Line for simple segments, Rectangle for axis-aligned boxes, Circle for circular outlines or fills, and Ellipse for elliptical shapes, all specified by endpoints, centers, or bounding parameters in VDC space.[1][3] Raster primitives support incorporation of pixel-based imagery, with Cell Array (Version 1) allowing rectangular arrays of color-indexed cells mapped to VDC extents, and the Tile primitive (Version 3, 1992) enabling more general raster blocks including compressed formats and bitonal tiles for monochrome bitmaps to provide efficient storage of binary images.[3][10] Text primitives position strings at specified VDC coordinates, referencing a font index from the picture descriptor for rendering, and support alignment options like left-justified or centered placement.[3][10]Attributes
Attributes in CGM are state-based, meaning they establish rendering properties that apply to all subsequent primitives until overridden, enabling efficient description of complex scenes without per-element repetition. Line attributes include Style (e.g., solid, dashed, or dotted patterns), Width (specified in VDC units for device-independent scaling), and Color (selected from a color table or direct RGB values).[10][17] Fill attributes control interior rendering of closed shapes, with options for solid Color, even-odd or nonzero winding rules, hatching patterns via index, or tiled patterns, while Edge attributes manage outline visibility, style, width, and color independently (hatching and patterns enhanced in Version 2, 1991).[3][10] Text attributes specify Font index (from predefined or bundled lists), Color, Height (in VDC units), and Orientation (via up-vector angles for rotation), ensuring consistent typography across the picture.[3][10] These attributes collectively define visual appearance without altering the geometric data of primitives.Controls
Control elements manage the spatial and interpretive context for primitives and attributes, facilitating transformations and boundaries. Viewport specifies a rectangular region in VDC space to map the entire picture body, allowing selective display of content within a normalized area (core CGM supports affine mappings like scaling and translation via viewport and window specifications).[3] Clipping restricts rendering to a defined polygonal or rectangular boundary, preventing elements outside the clip region from being drawn.[3] In core CGM, transformations are limited to global picture-level mappings without general per-element affine operations. Profiles like WebCGM extend this through scripting interfaces that apply concatenated 3x3 affine matrices for operations including rotation and shearing in VDC space.[3] Escape elements provide a mechanism for vendor-specific extensions or application-defined functions, embedding non-standard data while maintaining core CGM compatibility.[1][2]Encoding Methods
The Computer Graphics Metafile (CGM) standard, defined in ISO/IEC 8632, specifies three distinct encoding methods for serializing metafile data: binary, clear text, and character encodings. These methods ensure compatibility while addressing different needs in storage, transmission, and processing, with all preserving the identical semantics of the functional elements outlined in Part 1 of the standard.[1][2] Binary encoding, detailed in ISO/IEC 8632-3, employs a compact representation optimized for efficient generation, storage, and software processing. It structures data as a sequence of elements, each comprising a class code (0-3 indicating parameter data types such as integers, reals, bit strings, or strings), an identifier (element code), and a length field, resembling an ASN.1-inspired tag-length-value format with fixed-length fields for minimal overhead.[18] This approach uses short-form (one octet for class/ID combinations under 32) and long-form encodings for extended identifiers, enabling rapid parsing in applications like rendering engines.[19] As the default encoding, it prioritizes performance but sacrifices human readability, necessitating specialized tools for inspection.[1] Clear text encoding, specified in ISO/IEC 8632-4 (withdrawn in 2001), provides a human-readable ASCII-based format using keywords and structured syntax for easy creation, editing, and debugging with standard text editors. Elements are represented by mnemonic keywords (e.g.,BEGMF for beginning a metafile), followed by parameters in a declarative style, with support for inline comments delimited by exclamation marks.[1] This method facilitates manual intervention and portability across text-processing environments but results in larger file sizes due to verbose textual representations.[1]
Character encoding, outlined in ISO/IEC 8632-2 (withdrawn in 2001), offers a compact 7-bit ASCII-compatible scheme for basic data interchange, utilizing ISO 646 portable characters and a subset-like structure derived from clear text principles but optimized for minimal size. It encodes elements via single- or double-byte opcodes within a regular syntax, adhering to ISO 2022 extension rules for control functions, which limits it to essential graphical primitives and excludes complex features for broader transport compatibility.[20] Though less readable than clear text, it balances compactness with character-based portability, though it demands more processing than binary for decoding.[1]
Selection among these encodings depends on use case: binary for high-performance software applications requiring efficiency in storage and rendering; clear text for scenarios involving human review or editing; and character for legacy or constrained interchange environments emphasizing 7-bit safety. All methods maintain semantic equivalence, allowing transparent conversion between them without loss of graphical intent.[3][1]