QuickDraw GX was a replacement for Apple's QuickDraw graphics engine and Printing Manager, initially released in about January 1995. Version 1.1.1 was bundled with Macintosh System 7.5 later that year. Besides including a complete replacement for the traditional Macintosh printing architecture, it also introduced a repackaging of Type 1 fonts using the TrueType format. While the intentions behind these reorganizations were good—to make things easier to install and manage for users—there were too many existing applications and application developers that were used to doing things the old way. Thus, the installation of GX introduced a host of incompatibilities that only succeeded in annoying users. This, coupled with a lack of communication from Apple about the benefits of QuickDraw GX and why developers and users should adopt it, led to the technology being sidelined. Mac OS 8 dropped support for the GX printing architecture, though the GX graphics engine was kept alive a little bit longer in the form of the "GXGraphics" system extension. With the advent of OS X, GX was killed off altogether.

QuickDraw GX Graphics

Unlike QuickDraw, QuickDraw GX allowed for fractional coordinates. However, these were fixed-point values, rather than floating-point. This might have been because at the time GX was being developed (late 1980s to early 1990s), there was still a significant performance penalty in using floating-point arithmetic.

In addition to coordinates was the concept of the gxMapping. This was a 3-by-3 matrix which could express arbitrary linear transformations in two dimensions, including perspective distortions.

The GX graphics architecture was built around a number of types of objects. These were all opaque, though a full set of API calls was available for examining and manipulating them:

• a gxShape defined the basic geometry of a shape (for example, coordinates of control points for a curve, or the text content of a text object).
• a gxStyle defined elaborations of the basic shape geometry, such as line thickness, cap and join styles, fill pattern and text font.
• a gxInk specified how pixel values were to be computed when rendering the shape: besides specifying a basic colour for the shape, this also included an elaborate transfer mode structure that could define a wide variety of functions of the initial and final destination pixel value.
• a gxFont represented a font, either one installed for systemwide use, or one installed on-the-fly by the current application for its own use. API calls allowed the interrogation of the properties of a font, including the determination of what encodings (Unicode, language-specific etc.) it might support.
• a gxProfile was a representation of a ColourSync colour profile, used as part of the specification of a colour for drawing. GX integrated full support for colour matching at all stages of the drawing process, as well as support for non-RGB colour specifications (such as HSV, YUV and CIE XYZ).
• a gxTransform determined the relationship between the shape and the display device. Besides the clipping path and the gxMapping that transformed the shape before displaying on the output device, this object also specified hit-testing information that controlled responses to user clicks within the area of the shape.
• a gxViewDevice represented a block of pixel memory into which drawing would be rendered. This could be an actual on-screen display, or an offscreen block of memory. GX supported all the QuickDraw pixel layouts; this allowed both a GX view device and a QuickDraw GrafPort to point to the same pixels, thereby allowing applications to mix both sets of drawing calls.
• a gxViewPort was a logical destination for drawing. A gxTransform could specify a list of more than one of these; the shape would be drawn into all of them in a single GXDrawShape call.
• a gxViewGroup represented the connection between view devices and view ports. Each view port had a gxMapping specifying its relationship to the global coordinate system of the view group; and each view device had a gxMapping that specified its location and the size of its pixels with regard to view group coordinates. There was a single prdefined view group which contained all on-screen view devices (and whose view ports effectively corresponded to on-screen windows); applications were free to create their own view groups for off-screen view devices and view ports.
• a gxTag allowed the attachment of arbitrary application-defined information to most of the above object types. Each tag had an OSType type code, but there could be multiple tags of the same type attached to the same object.

QuickDraw GX Shape Types

GX shapes could be of various types:

• a straight line defined by its end points.
• a rectangle defined by its left, right, upper and lower bounds.
• a polygon defined by a sequence of vertex coordinates.
• a curve shape was a single quadratic Bézier curve defined by three control points.
• a path shape which was a sequence of quadratic Bézier curves. Each control point had an associated flag indicating whether it was "on-curve" or "off-curve". An on-curve point was a Bézier endpoint, while an off-curve point was a Bézier midpoint. If two successive off-curve points were encountered, then an implicit on-curve point was assumed to lie halfway between them. Two successive on-curve points defined a straight-line segment.
• a bitmap shape contained raster data in any of the supported pixel formats.
• a picture shape was a grouping of other shapes (possibly including recursive picture shapes), with the option of specifying additional transformations applying to the whole group.
• the various types of typographic shapes are described in the GX Typography section below.
• additional types which were perhaps not directly useful for drawing, but could be combined with other shapes in geometry calculations: the empty shape (drawing of which did nothing); the point shape consisting of a single point; and the full shape (of infinite extent).

QuickDraw GX Typography

The typography features of GX were integrated in the form of 3 types of gxShape:

• Text shapes were the simplest: these contained a single run of text rendered in a single font style.
• Glyph shapes were a way to use character shapes ("glyphs") as pure geometry, for instance as clipping paths.
• Layout shapes were the most elaborate. These could be divided into multiple runs with different font styles, even different language encodings and text directions. Thus, it was possible to embed a sequence of Arabic text, rendered right-to-left, within an outer sequence of left-to-right Roman text. Layout shapes unleashed the full power of contextual substitutions, kerning, variations and all the other capabilities of TrueType GX fonts. Their main restriction was that they were confined to a single line of text.

The GX API also provided hit-testing functions, so that for example if the user clicked on a layout shape in the middle of a ligature, or in the region between a change of text direction, GX itself would provide the smarts to determine which character position in the original text corresponded to the click.

TrueType GX

An important distinction in GX was drawn between a character and a glyph. A character was an abstract symbol from some alphabet or character set, such as the letter "f". Whereas a glyph was a specific graphic shape from a particular font, that might or might not represent a particular character. Thus, for example, the Hoefler Text font had glyphs to represent the letters "f" and "l". It also had another glyph to represent the ligature "fl", which could be automatically rendered (instead of the individual glyphs) wherever the two characters "f" and "l" occurred in sequence in the source text.

This distinction was important in that such contextual substitutions occurred at rendering time, without any changes to the source text. Thus they had no impact on editing or searching of the text.

Such substitutions could be controlled by enabling or disabling various features of a TrueType GX font. Fonts would commonly have features called "common ligatures" (such as the "fl" example), "rare ligatures", "archaic non-terminal s" (for automatically substituting the letter "s" with the archaic form that looked more like an "f", except at the ends of words), and even choices between entirely separate sets of glyph designs, such as more and less ornate forms.

The rules for performing these substitutions were implemented as state machines built into the font, and interpreted by the GX layout engine. Other state machines could implement automatic kerning, as well as optically-based adjustments to alignment and justification.

Another interesting feature was font variations, which were the GX equivalent of Adobe's "multiple master" fonts. Only, Adobe's idea was that you had to explicitly create an instance of the font (by specifying values for the variation axes) before you could use it. Whereas GX allowed you to specify the font directly for a layout style, and then dynamically vary the axis values and immediately observe the effect on the layout of the text.

QuickDraw GX Printing

References

This page uses Creative Commons Licensed content from Wikipedia (view authors).

External links

• QuickDraw GX at Apple Developer Connection (archived 2003-07-08)
• QuickDraw GX at Wikipedia