Graphical Kernel System
The Graphical Kernel System (GKS) is an international standard for two-dimensional computer graphics programming, providing a language-independent set of functions to create, manipulate, and display vector-based graphical output across diverse hardware and software environments.[1] Defined in ISO 7942-1985, it was the first ISO standard for computer graphics, enabling portable applications through features like output primitives, input device handling, and coordinate transformations.[1][2] Development of GKS began in 1978 under the Deutsches Institut für Normung (DIN) and was refined by ISO Technical Committee 97, Subcommittee 5, Working Group 2 from 1980 to 1982, culminating in its approval as ANSI X3.124-1985 in June 1985 and publication as ISO 7942 in August 1985.[1] The standard provides a functional description, with separate language bindings such as for FORTRAN 77 defined in ISO 8651-1:1988.[1][3] Its core purpose is to standardize graphics methods for application programmers, ensure program portability, and guide device implementations, addressing the fragmentation in early computer graphics systems.[1] At its heart, GKS supports key functional capabilities organized around output, input, transformations, and management. Output primitives include polyline, polymarker, text, fill area, cell array, and generalized drawing primitives (GDP), each controllable via attributes like color index, linetype, and linewidth.[1] Input is handled through six logical device classes—locator, stroke, valuator, choice, pick, and string—with modes for request, sample, and event processing to support interactive applications.[1] Coordinate systems encompass world coordinates (WC) for modeling, normalized device coordinates (NDC) for abstraction, and device coordinates (DC) for rendering, with transformations like normalization (e.g., setting windows and viewports) and clipping to map between them.[1] GKS structures operations via state lists (GKS State List, Workstation State List, Segment State List) and operating states (e.g., GKS open, workstation active, segment open), allowing deferral modes like "as soon as possible" (ASAP) for efficient rendering.[1] Segmentation enables grouping of primitives into workstation-dependent (WDSS) or independent (WISS) storage for manipulation, visibility control, and highlighting.[1] Workstations are categorized as output-only, input-only, combined (OUTIN), metafile output/input (MO/MI), or WISS-capable, supporting multiple simultaneous connections and error handling through inquiry functions.[1] Metafile support facilitates long-term storage and exchange of graphical data.[1] To accommodate varying implementation needs, GKS defines 12 upward-compatible conformance levels (e.g., 0a for basic output, 2c for full functionality with input and segments), ensuring scalability from simple to advanced systems.[1] Since its release, GKS has profoundly influenced computer graphics standardization, serving as a foundational model for subsequent standards like PHIGS (for 3D) and GKS-3D (ISO 8805:1988). The original standard was revised and published as GKS-94 (ISO/IEC 7942-1:1994), which was later confirmed but remains largely historical.[4] It promoted interoperability in fields such as CAD, scientific visualization, and engineering.[5][2] Its emphasis on portability and modularity made it a major advancement in the 1980s, with implementations in systems like OpenVMS and widespread adoption in professional graphics software.[6]Introduction
Definition and Purpose
The Graphical Kernel System (GKS) is a two-dimensional computer graphics system based on vector graphics, introduced in 1977 as an initial proposal for standardized graphics programming.[7] It supports the creation of basic visualizations, such as line and bar charts, through a defined set of output primitives suitable for scientific and engineering applications.[4] A key aspect of GKS is its emphasis on cross-system portability, achieved via a universal coordinate system that abstracts graphics operations from specific hardware implementations.[1] This design ensures device independence, allowing programs written with GKS functions to operate across diverse output devices and programming languages without modification.[8] The primary purpose of GKS is to provide an application-level interface comprising basic functions for graphics production, including the output of primitives, input handling via logical devices, and workstation management.[1] By separating picture composition and user interaction from device-specific realization, GKS enables reusable, portable graphics code for a wide range of applications.[4]Historical Context
The field of computer graphics emerged prominently in the 1960s, building on early innovations from the 1950s such as MIT's Whirlwind display systems and vector plotters, but it was characterized by fragmented, proprietary implementations that hindered widespread adoption.[9] By the mid-1960s, only around 100 interactive display systems existed globally, each tied to specific hardware from manufacturers like IBM and Digital Equipment Corporation (DEC), which provided device-dependent graphics libraries for peripherals such as Calcomp plotters and Tektronix storage tubes.[9][10] These proprietary systems, often emulated across limited device sets, severely restricted program portability and programmer mobility, as applications developed for one platform could not easily transfer to another without significant rewriting.[10] As computer graphics applications proliferated in the 1970s, the limitations of these proprietary approaches became increasingly evident amid a surge in diverse workstations and use cases. Large organizations by 1975 managed up to 20 incompatible graphics systems to support needs in engineering, physics, and animation, exacerbating inefficiencies in software development and maintenance.[11] The growing demand for standardized interfaces stemmed from expanding applications in computer-aided design (CAD), scientific data visualization, and electronic publishing, where interoperability across hardware was essential for productivity in industries transitioning to digital workflows.[10] Efforts like the UK-developed GINO-F package in 1972 highlighted early attempts at device independence but underscored the broader need for universal standards to accommodate this hardware diversity.[11] International bodies played a pivotal role in addressing these challenges through coordinated efforts in the mid-1970s. The International Federation for Information Processing (IFIP) Working Group 5.2 initiated a standardization program in 1974, culminating in the influential Seillac I Workshop on Methodology in Computer Graphics held in France in May 1976, which brought together experts like William Newman and Jim Foley to debate foundational concepts for graphics interfaces.[9][10] Complementing this, the ACM SIGGRAPH Graphics Standards Planning Committee (GSPC), formed in 1974 following a conference on device-independent graphics, recognized the necessity for a kernel-level system to abstract hardware complexities and enable portable, application-level graphics programming.[12] These initiatives collectively identified the need for a standardized kernel graphics system, leading to the proposal of GKS in 1977 as a direct response to the era's fragmentation.[10]Development and Standardization
Origins in the 1970s
The origins of the Graphical Kernel System (GKS) trace back to the mid-1970s, when José Luis Encarnação, a professor at Technische Universität Darmstadt and chair of the German national standards committee DIN working group UA5.9 on computer graphics, began advocating for a unified kernel-based approach to graphics programming. Working closely with researchers at the Interactive Graphics Systems Group in Darmstadt, Encarnacao initiated discussions around 1974–1977 to address the need for a portable, device-independent core system for basic 2D graphics operations. This effort was motivated by the growing fragmentation in graphics software across Europe and North America, where disparate systems hindered interoperability in applications like CAD and scientific visualization.[9][13] In parallel, the International Federation for Information Processing (IFIP) Technical Committee 5 Working Group 5.2 on graphics standards played a pivotal role in coordinating early collaborative efforts. Following a 1974 IFIP WG5.2 meeting in Malmö, Sweden, where French researcher Richard Guedj was tasked with launching a standardization initiative, Encarnacao's DIN group contributed key conceptual foundations to the emerging GKS framework. By 1976, the Seillac Workshop in France—organized under IFIP auspices—brought together European and North American experts, including delegates from the U.S. Graphics Standards Planning Committee (GSPC), to refine ideas for a minimal "kernel" handling primitives like lines, curves, and text, while abstracting hardware dependencies. This working group formation fostered cross-continental input, with Encarnacao emphasizing a layered architecture to ensure portability.[9][14] Early prototypes and discussions centered on implementing this kernel concept, drawing significant influence from the GSPC's CORE system proposal released in 1977. Encarnacao's team at Darmstadt developed initial functional specifications that paralleled CORE's focus on a small set of device-independent functions for output primitives and transformations, testing them in prototype environments for vector-based plotting and interactive editing. These efforts, documented in working papers from DIN UA5.9 and IFIP workshops, highlighted the kernel's role in buffering applications from diverse output devices, paving the way for GKS's evolution into a formal standard. By late 1977, these prototypes demonstrated feasibility for basic operations, influencing subsequent ISO deliberations.[1]Standardization Milestones
The standardization process for the Graphical Kernel System (GKS) began with its acceptance as a draft proposal by the International Organization for Standardization (ISO) Technical Committee 97 Subcommittee 5 on 9 October 1981, marking version 6.8 (later refined to 7.0) as the basis for further development.[14] This draft proposal (DP) represented a consensus on core technical features after years of international collaboration. In 1983, GKS advanced to the Draft International Standard (DIS) stage, with ISO/DIS 7942 circulated for member body review and voting, incorporating refinements to ensure broad applicability in computer graphics programming. The standard was ratified internationally as ISO 7942 in August 1985, defining the functional description for 2D vector graphics output and input primitives.[15] Concurrently, it was adopted in the United States as American National Standards Institute (ANSI) X3.124 in 1985, aligning closely with the ISO specification to promote domestic and global interoperability.[1] Subsequent revisions enhanced GKS capabilities while maintaining backward compatibility. The 1994 edition (ISO/IEC 7942-1:1994), known as GKS-94, introduced support for metafile formats to enable storage and exchange of graphical elements, expanding its utility in data interchange scenarios.[4] Minor updates followed in 1998 with ISO/IEC 7942-4:1998, refining metafile encodings and picture part retrieval for improved precision in file-based operations. GKS functionality was later integrated into broader industrial standards, notably ISO 10303-46 (part of the STEP suite for product data representation), which incorporates GKS-compliant graphics elements to support visualization of 3D product models and ensures consistency in exchange formats.[16]Technical Architecture
Core Components and Model
The Graphical Kernel System (GKS) is structured around a three-layer model that separates application logic from device-specific operations, ensuring device independence and portability for 2D vector graphics programming. The top layer comprises the application program, which defines graphical content in world coordinates (WC) and interacts with GKS via language-dependent bindings to invoke functions for output primitives, attributes, and input handling. The middle layer, the GKS kernel, acts as the core processing unit, maintaining state lists for current settings, applying normalization transformations to map WC to normalized device coordinates (NDC) in the [0,1] × [0,1] range, and coordinating segment storage and workstation interactions. The bottom layer consists of workstation interfaces, which abstract physical hardware into logical devices and handle rendering and input sampling through the operating system.[1] A key element of the GKS model is its segment-based organization, which groups output primitives and attributes into reusable, named units for deferred rendering and manipulation, supporting up to 32,000 unique segment names per implementation. Segments are managed through functions such as CREATE SEGMENT (to initialize a segment), DELETE SEGMENT (to remove it), and operations for visibility toggling, editing, and hierarchical inclusion, allowing applications to build complex pictures incrementally without immediate device output. Workstation Independent Segment Storage (WISS) enables segment portability across different workstations by storing data in a device-agnostic format, while Workstation Dependent Segment Storage (WDSS) accommodates local device constraints, facilitating efficient updates like partial redraws and transformations on the entire segment structure.[1] The virtual device model underpins GKS's abstraction of hardware, defining logical input devices (e.g., for locator or stroke events), output capabilities for primitives, and composite workstations that integrate both with optional segment support. Workstations are classified by functionality—such as OUTPUT for rendering only, INPUT for event sampling, OUTIN for bidirectional operations, or variants like MO (metafile output with segments)—and opened via functions like OPEN WORKSTATION to establish connections. This model enforces device independence by processing all graphics in NDC space before final device coordinate mapping, allowing applications to operate uniformly across diverse hardware without modification.[1]Workstations and Device Independence
In the Graphical Kernel System (GKS), a workstation serves as a logical entity that bridges the application program with one or more physical output devices, such as displays or plotters, thereby enabling device independence. This abstraction allows applications to generate graphics without direct knowledge of the underlying hardware specifics, as the workstation handles the mapping of abstract graphical elements to device coordinates. The core layered model of GKS facilitates this by separating application logic from device-dependent operations, ensuring that output primitives and attributes are rendered consistently across diverse hardware through normalization transformations that convert world coordinates to normalized device coordinates (NDC) before final device-specific mapping.[1] GKS defines functionality through a hierarchical set of levels (0 through 2C), which represent subsets tailored to varying device capabilities, promoting portability by allowing implementations to support only the features compatible with available hardware. Lower levels provide basic output support, while higher levels incorporate advanced features like segmentation and color handling. The levels are structured along output dimensions (0, 1, 2) with qualifiers (A, B, C) indicating progressive enhancements, ensuring upward compatibility where higher levels include all capabilities of lower ones.| Level | Output Capabilities |
|---|---|
| 0 | Basic primitives (e.g., polyline, text, fill area); single normalization transformation; no segmentation. |
| 1 | Full output primitives; basic segmentation for hierarchical graphics storage and manipulation. |
| 2A | Workstation-independent segment storage (WISS) for portable segment handling across devices. |
| 2B | Enhanced segmentation with multiple open segments and priority management. |
| 2C | Complete functionality, including continuous-tone color support, multiple normalization transformations, and advanced bundle tables for attributes like line style and color. |
Key Features and Capabilities
Output Primitives and Attributes
The Graphical Kernel System (GKS) defines five core output primitives for generating two-dimensional vector-based graphics, enabling the creation of lines, markers, text, filled areas, and raster-like cell arrays on workstations. These primitives operate in workstation coordinates or normalized device coordinates and are rendered according to current attribute settings, allowing for device-independent output. Output primitives are stored within segments, which serve as units for manipulation and ensure that attributes apply consistently across the graphical picture.[1][17] The polyline primitive connects a sequence of two or more points with straight line segments, forming open or closed paths suitable for outlines and curves. Polymarker places predefined marker symbols, such as dots or crosses, at one or more specified points, useful for plotting data points or annotations. The text primitive renders a string of characters starting from a given position, supporting horizontal or vertical paths and alignment options for labels and legends. Fill area defines a closed polygon by three or more points and fills the interior, either hollow or with solid color, patterns, or hatching, ideal for representing shapes and regions. Finally, the cell array primitive displays a rectangular grid of colored cells defined by corner points and a color index matrix, providing a means for raster image approximation in a vector environment.[1][6][17] Attributes in GKS control the stylistic and visual properties of these primitives, including line style (solid, dashed, dotted, or dash-dotted), line width scale factor, and polyline color index for polylines; marker type (e.g., dot, plus, asterisk), marker size scale factor, and polymarker color index for polymarkers; text font and precision (string, character, or stroke), character expansion factor, spacing, height, up vector, path, alignment, and text color index for text; and interior style (hollow, solid, pattern, or hatch), style index for patterns or hatches, and fill area color index for fill areas. Cell arrays rely primarily on the provided color index array without additional styling attributes. These attributes are set modally via functions such asGSLN for line style or GSTXFP for text font and precision, and can be queried using inquiry functions like INQUIRE POLYLINE REPRESENTATION.[1][6][17]
To ensure consistent and efficient attribute management, GKS uses bundle tables specific to each primitive type—polyline bundle (up to 20 entries at levels 1 and 2), polymarker bundle (up to 20), text bundle (up to 20), and fill area bundle (up to 10)—which associate indices with workstation-dependent representations of attributes. An application selects a bundle index (e.g., via GSPLI for polyline index) before issuing a primitive, applying the bundled attributes to all subsequent uses until changed; updates to bundle representations (e.g., via SET POLYLINE REPRESENTATION) propagate to all segments referencing that index, with options for immediate or deferred evaluation. Aspect source flags (ASFs) further control whether attributes derive from individual settings or bundle tables, promoting portability across diverse output devices.[1][17]