CAN CSA Z243.182-89 (2004) – Graphical Kernel System (GKS) Text: A Technical Overview of Computer Graphics Text Handling

Understanding the Scope, Technical Requirements, and Implementation of the Canadian Standard for GKS Text Output

Scope and Field of Application

CAN CSA Z243.182-89 (2004) is the Canadian adoption of the international computer graphics standard ISO 7942-2:1987, which defines the graphical kernel system (GKS) text handling facilities. This standard specifies the functional interface for generating, transforming, and representing text in a device-independent graphics environment. It is part of the GKS family of standards (Z243.180 – Z243.185) that provides a unified framework for 2D graphics applications.

The standard applies to any system that implements GKS as defined by the base standard (CAN CSA Z243.180-89). Its primary focus is the text primitive — the most complex output primitive in GKS due to its dependence on character sets, fonts, and geometric transformations. The scope includes:

  • Specification of the text primitive and its associated attributes
  • Definition of text path, alignment, size, and spacing controls
  • Rules for text clipping and intersection with workstations
  • Interface requirements for language bindings (e.g., Fortran, C, Pascal)
  • Semantics of the text extent and character base vectors

Originally published in 1989 and reaffirmed without technical changes in 2004, this standard remains a reference for legacy GKS implementations and for understanding the evolution of text handling in computer graphics APIs such as OpenGL and Vulkans high-level counterparts.

Technical Requirements – Text Handling in GKS

CAN CSA Z243.182-89 establishes a precise model for text output within the GKS pipeline. The core element is the text primitive, which is defined by a single character string, a position in world coordinates, and a set of attributes that control appearance and layout. The standard distinguishes between geometric text (subject to affine transformations) and non-geometric text (primitives that ignore transformations), but focuses primarily on the geometric variant.

Fundamental Attributes

The following table summarises the principal text attributes specified by the standard:

AttributeTypeDescription
Text pathEnumerationDirection of text expansion: right, left, up, or down (relative to the character base vector)
Text alignmentHorizontal + VerticalPositioning of the string reference point relative to the text extent (e.g., centre, top, base)
Character heightReal (world coordinates)Nominal height of the character body (usually the cap height); defines base vector length
Character expansion factorRealRatio of width to height; adjusts proportional spacing
Character spacingRealAdditional inter-character space expressed as a fraction of the character height
Text font and precisionInteger + PrecisionFont index (implementation-specific) and a precision level (string, character, or stroke)

Geometric Transformations and Clipping

Each text string is treated as a single entity for transformation. The character base vector defines the local coordinate system relative to the text position. All text attributes, including height and expansion, are interpreted in this local space. Transformations are applied through the GKS normalization transformation pipeline, so text defined in world coordinates can be rotated, scaled, and translated uniformly.

Text clipping follows the GKS clip rectangle mechanism. The standard distinguishes between three precision levels that control how tightly the clipping rectangle is enforced:

  • String precision: clipping is applied to the entire text extent (the bounding box of the unabbreviated string).
  • Character precision: each character is individually clipped against the rectangle.
  • Stroke precision: the geometric outlines of characters are clipped, providing the most accurate result.
Developer Tip: When implementing GKS text, pay careful attention to the character base vectors. Rotating the base vector by means of the current transformation effectively rotates the entire text string. This is often a source of layout errors if the vector’s magnitude is accidentally altered, because it controls the character height as well as direction.

Text Extent Information

The standard mandates a inquire text extent function that returns the bounding rectangle in world coordinates. This allows applications to perform precise layout calculations (e.g., centering, word wrapping, line spacing). The extent takes into account all attribute settings and the concatenated transformation, but does not include the effect of clipping.

Common Pitfall: The text extent reported for string or character precision may differ from the actual visible area because of clipping at the workstation level. Application code that uses text extent for cursor positioning should always consider the workstation’s rendering capabilities.

Implementation Highlights and Language Bindings

CAN CSA Z243.182-89 is designed as a functional description, not a language binding. However, it specifies the abstract interfaces that each binding must expose. The standard was created alongside the Fortran binding (CAN CSA Z243.183-89) and later influenced bindings for C and Pascal. Key implementation aspects include:

  • Text representation: The standard does not prescribe a font format; it leaves the mapping from font index to actual glyphs to the workstation.
  • Precision levels: A workstation advertising “stroke precision” must be able to render characters as editable curves. Lower precision may permit simpler implementations (bitmap or pre-rasterised fonts).
  • Error handling: If the requested font index is not available, the workstation substitutes the default font and returns an error identifier value defined by the standard.
  • Non‑geometric text: For special cases, the standard allows a non‑geometric text primitive that is not subjected to transformation. This is rarely used in practice.

Compliance and Reaffirmation Notes

The 2004 reaffirmation by the Standards Council of Canada confirmed that no technical changes were deemed necessary for this standard at that time. It remains a valid Canadian National Standard, though it has been largely superseded by more modern graphics APIs and the Computer Graphics Metafile (CGM) standards.

Compliance with CAN CSA Z243.182-89 requires that an implementation:

  1. Supports all text primitives and attributes defined in the standard (with the minimal set being string-precision text).
  2. Provides the inquire functions for text extent and current attribute values.
  3. Adheres to the error-reporting conventions specified in the parent GKS standard.
  4. Documents any workstation-specific limitations (e.g., font availability, deviation from ideal character placement).
Compliance Benefit: Adopting this standard facilitates portability of graphics application code across different hardware platforms. Even today, many computer-aided design (CAD) systems that originated in the 1990s rely on GKS text conventions for feature labelling and dimensioning.
Note on Obsolescence: CAN CSA Z243.182-89 (2004) should not be used as a basis for new graphics system design. Contemporary graphics libraries (e.g., OpenGL, Direct2D, Skia) provide far more flexible text rendering. This standard is retained primarily for compatibility with legacy software and for educational value in understanding the evolution of graphics standards.

Frequently Asked Questions

Q: What is the relationship between CAN CSA Z243.182-89 and ISO 7942-2?
A: CAN CSA Z243.182-89 is an identical adoption under the Canadian national standards framework. ISO 7942-2:1987 defines the text functionality of the Graphical Kernel System, and the Canadian standard reproduces it without deviation. The 2004 reaffirmation confirmed technical equivalence.
Q: Does this standard address Unicode or multi-byte character sets?
A: No. The standard was developed in the 1980s and assumes a simple integer character code with a maximum character set size of 255. It does not specify encoding; that is left to the language binding. For modern CJK or Unicode text, additional conventions outside the scope of this standard are required.
Q: Are there any known errata or corrigenda to the 2004 reaffirmation?
A: The standard was reaffirmed without change, so any earlier errata remain applicable. Users should refer to the Canadian Standards Association’s current listings. No substantive errors have been reported since the 2004 reassessment.



© 2026 – This technical article is prepared for informational purposes and does not replace the official CSA standard document.

📥 Standard Documents Download

🔒
Please wait 10 seconds, the download links will appear after the ad loads

Leave a Reply

Your email address will not be published. Required fields are marked *