Driven by a need for a graphics system that would provide a wider range of functions than is common and that would require less support effort when installed on about 50 mainframes, Rutherford Appleton Laboratory has implemented the Graphical Kernel System (GKS). The development project has used PERQ and VAX computers equally. This paper describes some of the design decisions and their effect on the resulting package. In particular, it describes the philosophy of the workstation interface and how this provides for devices and systems of greater complexity in the future. The way in which the facilities of the PERQ are matched to GKS concepts is outlined.
The Computer Graphics Section of Rutherford Appleton Laboratory (RAL) is responsible for the provision of basic computer graphics facilities to a large fraction of the academic community in Great Britain. About 50 mainframes (3 IBM, 9 VAX, 25 GEC 4000, 15 Prime) provide a general service to around 3500 research workers. In addition, about 130 PERQ single-user systems are installed. Between one-third and one-half of the community use some computer graphics facilities.
Although there has been a great rationalization of the graphics packages provided (at worst, in 1974 there were 15 packages in use), five packages are still in regular use, as shown in Fig. 1.
Access to the computers is mostly from on-line terminals distributed throughout the country, connected to their nearest computer. A wide range of terminals is used; approximate figures are
In addition, there are about 30 1-m drum plotters (Benson) and a number of desktop A3 plotters (Hewlett-Packard, Calcomp and Zeta). Finally, a central service is currently provided by RAL on an (off-line) III FR80 film recorder that produces film (black/ white and colour), hardcopy and microfiche. This is being replaced by laser printers and small on-line devices.
Six people are available to maintain and develop the graphics systems on these machines and for these devices. The presence of several packages considerably dilutes the support that these people can provide. In most cases the device handlers are written or extensively modified by RAL.
There has been constant pressure to enhance the packages, both to take advantage of facilities available on present-day devices and also to add functions to the packages to deal with new applications. The major requirement has been for access to the raster facilities of modern devices, for both colour work and image processing. Since all the packages were originally designed for either pen plotters or film recorders, such developments are often difficult to design in a way that fits comfortably with the original package.
The GKS document [1, 2] provides a description of functions for computer graphics; it is the first such document to undergo review by a formal standards body. It has achieved the status of an ISO Draft International Standard and is proceeding to the next formal stage within ISO. Some introductions to GKS have now become available [3, 4].
Unlike previous graphics packages, GKS is a functional description, and so there can be many implementations of it. The standard description ensures that programs may be transported between implementations. It is independent of any particular language and can therefore be implemented in any language. A program that has to be moved between implementations in different languages would naturally have to be rewritten, but there would be no need to change the program's structure as a result.
In 1981, RAL obtained the Darmstadt implementation of GKS 6.2 [5] for the VAX computers, which are used exclusively for analysis of astronomical data and therefore require image output facilities. By early 1982, it was decided that the effort toward standardization of GKS was likely to be successful and that RAL should provide GKS for its user community. It was also decided that RAL should itself implement GKS, since the support required for its large number of users would be too great a burden for any of those known to be implementing GKS at that time. In May 1982 an agreement was reached with International Computers Limited (ICL) that the development would be a joint venture; ICL was particularly interested in GKS's availability on the PERQ single-user system [6].
It was essential that the system provide graphics facilities for at least FORTRAN 77 and Pascal programs: these two languages are the official languages for the community supported by RAL. Because initially a FORTRAN interface is needed more widely and because it is common for Pascal systems to call routines written in FORTRAN but not the reverse, FORTRAN 77 was adopted as the implementation language, and the user interface was initially confined to FORTRAN 77 [7]. Strict adherence to the FORTRAN 77 standard was required, with two exceptions:
Both of these conventions were understood by a preprocessor, which, for all systems except VAX/VMS, would convert the INCLUDE statements to the local compiler's form of INCLUDE and would reduce GKS to the standard G.
The final aim was for a full implementation to level 2c, but the range of operating systems to be serviced made it impossible to consider level c input for the initial development. Level c input requires some form of multitasking, whether this be within the host or split between the host and the device. Although it might be possible to write a very large amount of the support code in FORTRAN 77 for one system, the entire structure would be different on the next operating system. Thus, all the difficult codes would not be transportable. It was decided that the initial development would be to output level 1, with hooks provided for support of workstation-independent segment storage (WISS), the only additional facility at output level 2.
Since the aim of the project was a transportable GKS system, there was no technical reason for developing the system on any particular computer. Although it would have been possible to develop GKS entirely on the PERQs, the networking software for these single-user systems was being developed in parallel with GKS; so a group of PERQs could not provide the same feel as a mainframe. For these reasons, the development has been accomplished on VAX (under VMS) and PERQ (initially under POS and subsequently under PNX) simultaneously. While the PERQ screen has been the major device tested on the PERQ, on the VAX the main device has been the Sigma 567X series. Once the system has been fully tested on PERQ and VAX, it will be distributed to these systems and work will proceed to engineer it for the other mainframes and to add workstation handlers for devices not yet catered for.
Fundamental to the GKS specification is the description of a workstation. Output passes to a workstation and may be stored there in segments. Input comes from an operator via a workstation. A workstation has a current state, which enables a program to modify the workstation's treatment of graphics data. Output may take on different appearances when displayed on different workstations; different views may be obtained; different buffering strategies may be employed. Implicitly, therefore, a workstation interface is defined by the GKS specification.
Correspondingly, inside an implementation of GKS (or any other device-independent graphics system), there is also an interface between what is commonly called a front-end, which implements the device-independent part and the back-ends, each of which implements software to drive a particular device. One of the first graphics systems to use this method was GINO [8].
In an implementation of GKS these two interfaces may coincide, or the interface in the implementation may be closer to the device.
In deciding how the implementation should be accomplished, there were conflicting requirements to be considered. The implementation had to be able to support intelligent devices (as well as dumb ones). One U.K. manufacturer already has a device on the market that includes the functionality of a GKS workstation, and other manufacturers now consider GKS when planning new devices. Future firmware extensions on the PERQ will be designed to improve performance on critical GKS functions. In addition, the system needed to be reasonably fast despite the flexibility.
The main design decision came from the requirement that the front-end be as thin as possible. In most cases the workstation driver would have to react to all requests passed to it from the user level.
This approach was one of about six that were considered. Others were rejected for the following reasons:
Since the interface in this implementation is close to that implicit in the GKS specification, we refer to it simply as the workstation interface. We believe this is justified, since any apparent loss of flexibility by departing from the obvious one is not significant.
The decision to have the workstation interface very close to the user-level interface was taken only when we were convinced that it was economical to write a large number of utility routines that could be used by workstation drivers for functions that particular devices could not perform directly. Unless this was true, the effort required to write each new workstation driver would have been too great. As it is, we believe that the effort involved in writing a new workstation driver is the minimum to be expected if the device is to be driven fully. The overall structure is shown in Fig. 2.
This figure shows (on the left) that a device may in some respects have the capabilities of a GKS workstation without its device driver requiring workstation utilities. On the right of the figure, a device requires substantial software support, but the author of the workstation driver may use a selection of the available workstation utilities (the blocks being consumed by the jaws). Some devices will lie toward one or the other of the two extremes.
Figure 2 contains a reference to the workstation call layer, which distributes calls to all active workstations, all open workstations or one specific workstation, as appropriate. The workstation call layer is shown in Fig. 3. Contained in this layer (and isolated to it) are calls to the workstation drivers specific to an installation.
Most entry points in the workstation drivers behave in the way one would expect from studying the GKS specification. In a few cases, however, it has been found that the most obvious interface is not necessarily the best, and we now explore some of these cases.
In the GKS specification, output primitives and attributes pass to the workstation in normalized device coordinates (NDC) and undergo a further series of operations there. The specified sequence (not including segment transformation) is
This sequence transforms twice and clips twice. In the RAL/ICL implementation, coordinates of output primitives and attributes pass to the workstation in world coordinates; the workstation, of course, has been previously informed of the current normalization transformation. The sequence is, therefore,
Coordinates are stored in segments in NDC coordinates and, when they emerge to be displayed, are transformed to DC coordinates in one operation (combining the segment transformation and workstation transformation). Naturally, for simple devices, these operations are performed by workstation utilities.
In some cases the coordinates must enter the workstation in NDC; for example, WISS functions and INTERPRET ITEM deliver coordinates in NDC. In such cases, the workstation driver is still sent a transformation. In general, there is always a current workstation-independent transformation. At different times there might be a current normalization transformation, an identity transformation (for INTERPRET ITEM) or a combination of one or two segment transformations (COPY SEGMENT TO WORKSTATION, INSERT SEGMENT). In any case the workstation does not need to know how the transformation was obtained, only its value.
For input of locator and stroke, the benefit in amalgamating the two transformations (in this case the reverse transformations) is not so apparent. The search for a suitable viewport to use is an obvious front-end activity, and so coordinates pass from the workstation in NDC coordinates.
In the GKS specification, every output primitive passing to a workstation carries with it all the output attribute data appropriate to that primitive; the attributes are said to be bound to that primitive. In practice, this can be correctly implemented by sending the workstation the values when they change and relying on the workstation to apply those values when the primitives are to be displayed. Attribute values, therefore, have to be stored in the workstation in some form. The attributes that possess coordinate information (for example, character height and pattern reference point) can be stored in the workstation in DC coordinates, since less processing results when primitives are sent. However, some care is needed. If a transformation changes, coordinates stored in DC must be recalculated. Some way of ensuring that the workstation has the correct information at the right time is needed.
Another problem to solve arises from possibly lengthy setting-up procedures in the workstation when an attribute changes. For example, a change in the font number may cause some loading of character definitions from external storage. This loading of character definitions may also occur when other aspects change, for example, the character height. In general, the setting of several attributes in succession may lead to some spurious occurrence of the setting up procedure. It has been observed that this situation can easily occur when the end user is using a package above GKS. If well written, the package would be very likely to stack and restore attributes so that any graphics produced directly by the user would not be affected by any after effects of calling the package. However, if the user were not to do any graphics directly, the attributes might be repeatedly stacked and restored without intervening graphics.
The RAL/ICL implementation solves these problems by delaying as long as possible the delivery of attribute values and coordinate transformation values to the workstation. The delay mechanism is applied independently to five groups of values: the workstation-independent transformation and attributes for each of the four primitives that have attributes (polyline, polymarker, text and fill area). Normally, a change in an attribute is delayed until a primitive that uses it is sent. For each of the five groups, an indicator specifies whether the values currently held by all active workstations are up to date. When a primitive is invoked by the user, the required sequence is
The delay and subsequent catching up is all managed by the front-end. Workstation drivers are simplified by this scheme as, whenever a set of attribute values is received, the transformation held by the workstation is correct. To ensure this, it is necessary to indicate that text and fill area attributes are out-of-date whenever the transformation is. For polyline and polymarker this is not necessary as those primitives do not have coordinate information associated with their attributes.
In the GKS 7.2 specification, attributes in an incoming metafile arc bound to primitives in that metafile. To deal with this, the indicator for each of the five groups of data shows not only that the attribute data on the workstation are up-to-date, but also that they are up-to-date for output primitives coming directly from a GKS function or, alternatively, that they are up-to-date for output primitives coming from a particular metafile (of which there may be more than one).
In the GKS specification, a segment is held by all the workstations that were active when it was created. An open workstation, therefore, does not necessarily possess all the segments, but, for any segment that it does hold, the contents are the same everywhere.
Implementing segments entirely in the front-end was quickly rejected, since that solution would rule out using segment facilities provided in some devices. The initial plan was to implement segments entirely in the workstation drivers (if not in the device), with support provided by workstation utilities. However, a problem occurs if more than one active workstation requires the utilities; either the segment is stored several times, or some contrived scheme is constructed to prevent this from happening.
The scheme finally adopted is that the front-end stores the segment in a central segment storage phantom workstation (CSS), if any workstation has requested assistance. This scheme is illustrated in Fig. 4.
On being asked to perform CREATE SEGMENT, a workstation may request assistance from CSS. If any workstations do so, CSS is added to the active workstation list, so that primitives and attributes in the segment automatically go to CSS [in addition to the requesting workstation(s)] without further testing by the front-end. Performance of the output primitive pipeline is therefore not degraded. CSS keeps a count of the workstations, on whose behalf it is storing a particular segment. Therefore a segment can be removed from CSS if the workstations that hold a segment are reduced (for example, by CLEAR WORK.STATION) to ones that are all fully capable.
Once a segment is in CSS, it has to be read back when required. This is especially needed by the regeneration activity (implicit or explicit). We realized that a segment could also be played back on other occasions. For example, on a simple raster device. DELETE SEGMENT can be partially implemented if the segment is played back to the workstation for the workstation to undraw it. Implicit regeneration is still marked as pending, because the picture is not perfect (other parts of the picture might now have holes in them).
The front-end plays back a segment at the request of workstation, delivering output and attributes to the workstation. At the end of the playback of a segment, the workstation driver has the opportunity to request the playback of another segment.
If the workstation were to both read and execute the segment contents from CSS directly, the structure of the driver would become more complex, as execution of output would then occur at more than one entry point in the driver. It is envisaged, however, that the workstation may also need to access CSS directly for some purposes, and CSS is designed with this in mind.
It is, or course, perfectly possible for a workstation to request help from CSS and also store the segment itself. A device that can store segments and perform some but not all the segment manipulations may well be implemented in this way.
CSS, which is an internal mechanism for supporting segment storage on some graphical workstations, should not be confused with WISS (workstation-independent segment storage), which is visible to the user. However, one might expect WISS to be implemented in terms of CSS. It is a curious fact that the simplest way of implementing WISS is to provide an incapable WISS driver that requests help from CSS! The three additional functions required at level 2 of GKS are then confined to the front-end.
In the GKS specification, for each segment there is a list of workstations holding that segment (we refer to it as the S-to-W list), and for each workstation there is a list of the segments being held there (the W-to-S list). There is a redundancy here, and, when constructing a physical representation of these lists, it seemed worthwhile investigating whether a significant amount of storage could be saved; for example, there may be a large number of small segments on more than one workstation.
The W-to-S list is retained in each workstation and is stored in priority order. An intelligent device keeps this list in any case. The S-to-W list is replaced by a count (for each segment) of workstations holding the segment. Functions for changing segment attributes (for example, segment visibility) are sent to all open segments, and all workstations not holding the segment simply ignore that function. This arrangement is shown in Fig. 5.
One of the reasons for implementing GKS at RAL, rather than obtaining it from an outside agent, was the range of computers and operating systems supported by RAL:
This variety prevented a multi-task structure from being considered. The differences between the various systems would have made such a solution difficult to transport across the systems.
Use of FORTRAN 77 (as opposed to FORTRAN 66) made some interfaces to the operating system much simpler; FORTRAN 77 provided adequate (although not elegant) facilities for handling character strings, for converting between character and binary representations, for handling some attributes of files and for using direct-access files. These were all areas where systems written in FORTRAN 66 tended to need modification.
It was realized that stack-and-heap storage facilities would still be required within the implementation, so sets of routines, written in FORTRAN 77, were written to provide INTEGER, REAL and CHARACTER stack-and-heap mechanisms. These are used extensively within the system, although fixed-length lists are used wherever possible.
However, several aspects of the system would inevitably still be system dependent. These include the actual names of files ( which are of different forms on different systems), the size of various buffers (which may be changed according to the size and organization of the memory available to the user) and the means by which GKS workstations are connected to the user's program.
In some areas, the GKS specification leaves decisions to the implementor. Some matters are implementation dependent; some are workstation dependent; others even depend on the input device.
The colour table has a maximum size on each workstation - let us call it m. However, in GKS the user can define entries higher than m because the colour table is allowed to be sparse. For example, if a colour table has a maximum of four entries, the user can set representations for entries l, 5, 1234 and 2 before the table fills up. This causes difficulties if the device has its own internal colour table, since an extra level of indirection is then required. For such devices, it is convenient to predefine all entries in the workstation colour tables from entry 0 to entry m-1. The user is therefore free to redefine any entry in this range, but any attempt to define an entry outside this range is trapped. This is allowed by the GKS specification, and we believe that no significant user requirement is unsatisfied.
Segment priority is, in general, not supported, unless the device can support it properly itself. When primitives are drawn, there is no attempt to check by software for overlap. Therefore, in a strict sense, segment priority is not supported, and inquiries of the workstation will receive that reply. Nevertheless, the implementation acknowledges priority when the user expects the picture to be up-to-date and, therefore, when regeneration takes place, segments are redrawn in priority order.
The display surface on many devices is obvious. However, there are some classes of device on which the display surface can be more flexible and adaptable to users' needs. Two such classes of device are relevant to the implementors.
The first is a raster device with multiple planes, such as the Sigma 7000 (ARGS). The hardware allows any group of planes to be written to and displayed selectively. On devices of this sort, a separate workstation can be associated with a specific group of planes. The number of planes in each group can be assigned as part of a configuration phase before the particular workstation types are used in the GKS session. Once the workstation types have been accessed by a GKS function, their characteristics cannot be changed until GKS is closed.
The second class of device is the bit-mapped display (for instance, the PERQ), which allows any rectangular area (on- or off-screen) to be manipulated by a RasterOp function. Multiple windows can be displayed in a way that has now become common with this kind of display. Which window obscures the other when two overlap is under the control of the user through the window manager in PNX (the PERQ operating system produced by ICL). Each window that is to be used for graphics is a display surface so far as GKS is concerned (not to be confused with the GKS window). Although the window manager on the PERQ allows the position of each window and the amount of it that is visible to be changed dynamically, the description of the display surface size in GKS is not altered. More information on the relationship between PERQ and GKS is given in Section 8.
In the area of graphical input, GKS allows an implementation much freedom to provide a good man-machine interface and to include facilities that are comfortably supported on the available hardware. Here we outline some of the choices that have been made. We describe, in particular, the implementation of menus and parameter identifiers (or PIDs).
On a device like the PERQ, because of its RasterOp facilities, menus can be easily displayed when required (popping up) and removed with no net disturbance to the picture. The end user selects a particular menu item by manipulating a puck over a tablet surface. Menus are therefore likely to be extensively used on the PERQ. The implementation has some features that make menus easier to use.
Several choice devices with menus (typically five on the PERQ) are set up on one workstation. It is expected that the application programmer will prime each device (using INITIALISE CHOICE) with a different menu list corresponding to the different contexts in the application. When a particular menu is required, the application program does not have to resend the menu text strings; it simply uses the appropriate logical input device.
Normally, the popping up of a menu is the prompt for that logical input device, and the menu disappears when the interaction with that device finishes, at which time the original contents of the area are restored. It is sometimes of value for the user to see the menu even when the device is not taking part in an interaction. To do this, the application program sets a choice device to be permanent by an entry in the input control data record (and can, of course, reverse the setting). Of course, since the popping up of the menu is no longer the prompt, it is essential to indicate to the user the availability of the device in some other way, and for this purpose the border of the echo area is thickened or the title of the menu (if any) is inverted. This procedure applies not only to choice devices represented by menus, but, in general, to any soft logical input device that relies on some graphical display for its prompt (for example, a valuator implemented by a sliding scale).
A physical device like a dial is normally visible all the time, even though it is only available for use while an interaction is taking place. A soft logical input device is, at the other extreme, like a dial that emerges from a drawer when an interaction begins and recedes when the interaction is over. By setting the logical input device to be permanent, the program can control more explicitly when (to use the same analogy) the dial appears and recedes.
Turning now to how the input data record is constructed, we note that the data record might contain several items of control data to be delivered to an input device. For example, as well as the values required in the GKS specification, a stroke may have controls to set time elapse or distance change before a new point in the stroke is generated; a choice menu may have controls for the arrangement of rows and columns in the menu and for a title; a valuator may have controls to set the number of scale subdivisions. The PACK DATA RECORD routine in the FORTRAN/GKS binding is cumbersome to use in this instance and is only a suggested method of constructing data records.
The implementation allows an input data record to be packed parameter by parameter. A typical packing routine (there is one for each data type) accepts a parameter identifier (PID) and a value. A user may, therefore, call an inquiry to obtain the default or current data record and alter selected parameters. There are, of course, routines for unpacking PIDs.
Initially the implementation allowed errors to be reported wherever they were detected, possibly down several levels of call. Whenever an error made continuation unacceptable, a status would have to be transmitted to the routine directly called by the user (the user level routine). This arrangement had several disadvantages:
To deal with these problems, a consistent error-handling scheme was set up:
Normally, just one error is reported, and the GKS function does not proceed further. However, an error in one workstation does not prevent other workstations in the active list from being entered. If multiple error conditions occur thereby, only the first is reported.
The PERQ is a single-user computer. It consists of a processor, a screen, a graphics tablet, a Winchester disk (24 megabytes) and communications interfaces. The processor can execute Pascal at about 1 million P-code instructions per second. The screen is non-interlaced, 60-Hz refresh and bit-mapped from the main memory of the PERQ.
The intrinsic output facilities of the PERQ are exceedingly simple:
LINE draws a line on the PERQ screen, 1 pixel wide, between two points specified as screen coordinates.
RasterOp performs a logical operation between (one or) two upright, rectangular areas, either or both of which may be on the screen.
RasterOp is very fast: it can modify the entire screen (768 kilobits, 96 kilobytes) in two screen cycles (1/30 second). It is not only used for raster image work but provides a very-high-speed, multiple-font, text output system. In this case the source of the character images is an off-screen font area.
The simplest way in which a program may use the PERQ screen in by opening a workstation with the connection identifier, which indicates the current window for output. This has the disadvantage that standard program output (e.g. output from FORTRAN routines) will go to the same window and may cause scrolling.
To use a different window, a utility returns a connection identified that corresponds to a specific window and that can be used in a call to OPEN WORKSTATION. Another utility returns the size of the window.
The mapping of GKS output functions to the PERQ is, at present, rather simple. One-pixel-wide POLYLINEs use LINE directly; wide and patterned lines use utility routines, which in turn call LINE for short segments. POLYMARKERs use bit-mapped characters at nominal size and stroke-drawn definitions at other sizes.
STROKE precision text uses a workstation utility that accesses a font database also used by other workstations. STRING precision text uses RasterOp and bit-mapped fonts. CHAR precision uses the attributes of the font from the font database to position each character, and then the individual characters are drawn from the bit-mapped fonts with RasterOp.
FILL AREA and CELL ARRAY are performed by utilities, the special case of 1-to-1 cell-to-raster mapping being noticed and taking a fast path through the utility. A number of GDPs, corresponding roughly to those proposed in the latest ANSI graphics metafile document [9], are provided. They are
The PERQ has as its native input resources a keyboard, tablet coordinates and buttons on the tablet's puck. All of these resources are accessible by GKS through the PNX window manager, which may allocate one or more of them to an application using GKS.
LOCATOR and STROKE input devices can only reasonably be implemented with the tablet, and so one of each of these devices is provided. The keyboard is used naturally to implement a single STRING device. Two CHOICE devices, one based on the keyboard and one on the puck buttons, are provided. In addition, five CHOICE devices simulated by means of pop-up menus are provided and similar mechanisms are used to provide VALUATOR devices.
CHOICE menus and VALUATOR devices make use of popping up as described in Section 6.4.
A number of future developments are being considered for the PERQ screen workstation.
One of the most obvious ways of improving the performance of a system like the PERQ is through the use of microcode to speed up essential operations. A number of these have been considered:
Although the PERQ is very fast when producing text in the same orientation and size as the font, it is a slow process to produce rotated or scaled text. Microcode assistance in this area would speed up text (other than at STRING precision).
For a number of applications, the main segment manipulation facility required is that of floating picture segments until their final position has been determined. This may be achieved at very high speed-the segment following the cursor in roughly real time - if the segment is available as a raster image. Since the workstation handler has full control over how segment transformations are effected, an enhanced handler for the PERQ could keep a bit-mapped version of each segment, in addition to the standard, fully transformable version. If a segment transformation that is merely a translation from the existing position is requested, the transformation could then be accomplished using the bit-mapped version; more complex transformations could still be handled using the current system.
The ideas described in this paper were developed over a period of time by members of the implementation team from both RAL and ICL, and in most cases individuals other than the authors made the major contributions. In addition, Dale Sutcliffe (RAL) assisted with the planning of this paper, and Phil Bennett (ICL) provided descriptions of the PERQ system interface and input subsystem; both are members of the implementation team.
l. ISO, Information processing-Graphical Kernel System (GKS)-Functional description, ISO/DIS 7942. international Organization for Standardization, Geneva (June 1983).
2. BSI, A set of functions for computer graphics programming, the Graphical Kernel System (GKS), BSI Standard 639. British Standards Institute, London (September 1983).
3. F. R. A. Hopgood, D. A. Duce, J. R. Gallop, and D. C. Sutcliffe, Introduction to the Graphical Kernel System (GKS). Academic Press, London and New York (1983).
4. G. Enderle, K. Kansy and G. Pfaff, Computer Graphics Programming: GKS - The Graphics Standard. Springer-Verlag, Heidelburg and New York (1984).
5. Graphical Kernel System, Version 6.2 (July 1980).
6. F. R. A. Hopgood and C. Prosser, Single user workstations. Computer Graphics Forum 2 (4), 219-223. North-Holland (1983).
7. ISO, FORTRAN interface of GKS 7.2, ISO TC97/SC5/WG2 N214. International Organization for Standardization, Geneva (1983).
8. P. A. Woodsford, The design and implementation of the GINO 3D graphics software package. Software Practice & Experience 1 (4), 335 (1971).
9. ANSI, Draft proposed American National Standard for the virtual device metafile, ANSI document X3H3 83-15 R 1. American National Standards Institute, New York (August 1983).
