Why GKS is Unsuitable ...

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 83

Abstract.¶

This article is aimed at anyone who writes business graphics software. It describes some of the failings of GKS for business applications and gives some hard earned advice on graphics design. It is not aimed at engineers or technical graphics designers whose problems of pictorial representation are slightly different from those working in the business community.

This article is based on research and development into business graphics generation and presentation. The problems encountered with GKS highlight an important design flaw in the use of GKS concepts for business graphics. The alternatives proposed are currently under development.

Introduction.¶

RESOLVE is a Corporate Control System written in APL. It runs on the IBM PC AT and many of its clones. One of the main features of the system is its ability to generate high quality graphics from a large multi-dimensional database. RESOLVE also needs to support a broad range of high quality graphics devices which, invariably, communicate by using different protocols.

This paper highlights some of the problems found in using GKS to produce business graphics on devices of differing architecture, and outlines proposals for an alternative approach to designing device drivers.

The Problem with GKS.¶

“The wonderful thing about Tiggers is,
Tiggers are wonderful things.”

Practically every sort of graphics device has its own graphics language. Some manufacturers are trying to standardise the way their devices talk and some have developed their own graphics languages, such as HPGL (Hewlett-Packard Graphics Language).

Unfortunately few graphics devices actually have exactly the same capabilities. Screens may be able to display 2, 4, 8, 16, 256 or any other number of colours simultaneously. Pen plotters certainly find it difficult to draw 256 colours from a palette of 4096, but they have far better resolution than screens. Screens can dynamically change colours being displayed but plotters find that impossible of course. Screens are usually raster scan devices whereas plotters are vector scanned. Aspect ratios are different for many devices, and so on.

GKS was developed as a standard method of describing graphics pictures. In theory one can write a graphics program to generate a GKS file and then use a device driver to read that GKS file and generate a graph, pie-chart or whatever, on any appropriate device. Of course, IBM has implemented their version of GKS on the IBM PC and called it VDI (Virtual Device Interface). VDI supports the PGS (Professional Graphics System), EGA (Enhanced Graphics Adapter) and the usual IBM colour/graphics adapter, all of which are graphics cards which slot into IBM PCs.

GKS for Business Graphics¶

GKS has one basic flaw. It is too simple. It enables you to define lines, polygons, piecharts, boxes and so forth but when you try to draw an oval on two different devices then the cracks start appearing. Ovals can appear upright on one device but sideways on another which has a different aspect ratio and perhaps no viewport facility. Similarly, some devices have fixed character sizes or, particularly in the case of screens, allow only multiples of the minimum character size. You can easily draw a box and easily write text to the device, but GKS doesn’t let you draw a box that fits neatly around your text.

Plotters on the other hand can allow truly variable character sizes and can even allow slanted and rotated text which is difficult if not impossible for some screens. In fact some plotters even allow proportional character spacing! Try putting a GKS specified box around them! Laser printers further confuse the issue by introducing new attributes, such as changing typefaces, whilst other graphics printers have yet another set.

I suspect GKS has been adopted as the lowest level of compatability which manufacturers are prepared to accept. It does not offer user-level compatability, but instead gives them a marketing claim to standardisation. This may help them shift boxes, but does not help us create effective graphics. Perhaps a higher level of GKS would solve a lot of these problems – icon definition perhaps. But this is yet a long way off.

Defining the problem.¶

Why does GKS not resolve the problems of displaying pictorial images? The problem is not with the hardware or the software or even within GKS. The problem arises because GKS does not match the concepts used when drawing graphs. We do not draw a mass of lines and shading which happen to make up a graph. We draw a graph which happens to comprise a mass of lines and shading. GKS solves the wrong problem! When we draw a graph presenting a picture of cash flow or stock holdings, we are trying to pictorially represent a problem in a standard form so that a user can interpret it. It is the picture which conveys the message and therefore it is the picture which is all important; not the colours and thicknesses of the lines drawn. It would be nice if the device draws the picture to the best of its ability though – the better the quality of the image then the clearer the message.

The purpose of a device driver should be to accept only the information it needs to display a specific picture. Then it should generate that picture using the most appropriate techniques available for the device for which it was written. A new data stream with an additional set of data may cause a screen driver with 256 colours to shade a histogram in a new special colour whereas a plotter driver with no new colours may adopt a new shading pattern instead.

These sorts of decision on data presentation have to be made specifically by the device driver concerned and cannot succesfully be generalised. This approach also lets the driver optimise performance to the particular characteristics of the device it supports. A plotter driver may minimise the elapsed time taken to draw a graph by drawing each colour at a time – thus reducing the number of slow pen-changes mid-graph. Drawing overlaid bars on a chart is easy on a screen where each bar simply overwrites anything drawn earlier; it needs more careful planning on a plotter so as to ensure that the background bars are doctored to leave gaps for bars that will be drawn in front.

This does not mean that graphs should be different on each device. When you display a bar-chart on a screen and press the HARDCOPY button you should not watch the plotter draw a pie-chart. The graph formats should be designed so as to be recognisably the same graph on whatever device is chosen. It is up to the device driver, however, to understand that if the selected device can only display large characters, then extra space needs to be made for the titles, labels and headings before the core of the graph itself is drawn. The device driver may even make the decision to move headings and titles to another area on the display if it finds that it has not got enough room for them where they are normally drawn.

An alternative approach, apart from completely redefining GKS, would be to encode the IF statement within GKS files for the GKS device drivers to dynamically interpret. One might then program:

IF COLOUR 27 AVAILABLE THEN SET COLOUR TO 27 ELSE SET SHADING PATTERN TO COARSE DASHED MODE 3 AND LINE TYPE TO 11.

This would be interpreted by GKS device drivers which would take the correct action. Of course this can become very complex code if you want to determine global coordinates for a circle on a device with an horrendous aspect ratio. Then you decide to stick text in the middle of it and suddenly your GKS device driver becomes a command interpreter bigger than the application program which generated the graph in the first place.

Whist this approach might work in theory, I think conditional coding in GKS files is a dead end approach to true device independence.

Solving the problem.¶

The earlier discussion has shown that a device driver needs to know about an image as a whole before it can start creating that image on a particular device. In this case we have to code separately each combination of image and device.

The contents of the file created by the graphics software and given to the device driver are very different from the GKS standard. GKS requires the specification of each polyline, polygon or text output that will constitute the finished chart. Our new drivers take as input a selection from the styles of chart available, the values of the data-series to be graphed, the descriptions of those series and the standard styles to be used for each one. The driver has to carry out all the stages of processing to convert this information into a picture.

This means that the driver can no longer be a small and relatively simple program for drawing lines and polygons like the GKS-compatiable device drivers, but must be a large and fairly complex program which calculates optimum colour usage, character size, line thickness, text positioning, and so on.

In order to facilitate this we have to introduce a new concept which we have called Standard Styles. A Standard Style is the preferred combination of colour, line-type, marker-type and shading-pattern that should be used to represent a particular type of data. For instance, we may decide to represent budget data as standard 137, which is defined as green, using a dot-dash line pattern, with asterisks as markers and vertical, densely-packed shading for area-fill. This standard will apply across all charts generated by the system. Whenever we want to draw a specific chart on a specific device, the device driver has to match all the standards required by the data with the capabilities of the equipment; if the device cannot support enough colours for the chart, then compensating changes may have to be made to line-types, markers and fill-patterns to ensure that the data series are clearly distinguishable.

Even this is a simplification, as we have to handle issues such as the background colour. Standard Colour 0 is the same colour as the device background (white for normal paper, transparent for foils, black for screens, etc.); Standard Colour 1 is the opposite of 0 (black for white paper, white for screens). The other Standard Colours have two specifications (e.g. their RGB – Red Green Blue – and intensity); one is the ideal choice on a device with a black background, the other for a white background. It is up to a device driver to select from its palette the combination of colours which most closely match the requirements of the chart.

All of this requires yet another design exercise. You must first define exactly what your graphs should look like. Business users like to use standard formats, ones with which they are already familiar, so it is often quite easy to get a specification from them of the sort of graph layout they prefer. Your own input would be to try to clarify the messages the graph conveys by, for instance, removing spurious information. A graph that takes more than 5 seconds to understand is next to useless. Different messages may require different graph formats but there are (mercifully) few significantly different graph formats.

One of the benefits of this standardisation is that it helps managers to interpret charts more quickly and accurately. You are forced to offer a limited range of chart formats; but this lets you design each one carefully in order to make its point effectively.

For example, red is probably best avoided in a financial context. A manager who sees a red line immediately associates it with bad news and this may bias his interpretation of the graph. Budgets are always be presented in their standard style; so are actual data and forecasts. This means that a user viewing a long term forecast chart will not have to reorient himself to a new colour scheme when he looks at an historical chart. Incidentally, even senior managers can be afflicted with colour blindness so it makes sense to draw lines using different line-types as well as different colours.

After the initial work of specifying your standard colours, line types and so on, and then specifying your standard graph formats, writing the device drivers should be relatively easy. The graphics will be of better quality than GKS-generated ones and will probably be generated faster. The users will appreciate the ability to get good quality graphs on any supported device but will probably not appreciate the amount of work you put into it.

Disadvantages of this approach.¶

I have outlined why we are developing an alternative approach to GKS. It is, like GKS, a compromise and so has some associated disadvantages. There are three major problems:

• the device drivers will require considerably more code than under GKS; they will also have to be written by ourselves, rather than supplied by the hardware manufacturer;
• the range of equipment supported by any system will be restricted; in practice this is less of a problem as most organisations have standardised on certain types of kit;
• the range of types of chart supported by any system will be restricted; this is almost always good practice in any case as it prevents users be bombarded with totally new chart formats every time they use the system; however it would plainly be unacceptable in some other application areas.

This approach will introduce a degree of resistance to frequent requests to support new devices or make major changes to graph formats. You will have to change all of the device drivers for that graph in order to keep them in line. It is worth designing some flexibility into the device drivers so that they can accept options such as ‘2 to a page’ or HEBREW character sets or whetever if the need arises. Fortunately the device drivers can be easily generalised with higher level languages such as APL.

Exploring other possibilities.¶

It is interesting to note that the intermediate files containing data for the device drivers actually contain the source data from the database. Eye-ball checking of the data for accuracy is possible. Line definitions and viewport specifications and palette settings are not present in that file since all of that low-level specification (that currently has to be specified outside GKS) is now generated in the device driver.

Later developments will probably include a Graph Definition Database (GDD) which all of the device drivers can interrogate when drawing their graphs to examine how the ‘ideal’ graph should look. The device drivers can then be generalised to accept many different forms of graphics pictures, all of which are maintained by the user on his GDD. As the data in the intermediate file is so close to the real source data then it should be possible to generalise the data extraction routines prior to graph generation.

Finally . . . I probably need to explain why I quoted from ‘Winnie The Pooh’ at the beginning. Just because GKS salesmen and engineers say it is a wonderful thing doesn’t mean that GKS necessarily is a wonderful thing for business graphics programmers. In my view it has its uses but not in proper pictorial representation. It is a crude attempt at getting completely different devices to draw similarly, and for that it is by far the simplest and perhaps only alternative in a world where we have such different machines with different characteristics. The approach we are developing for defining device drivers is far less flexible than GKS in the short term and is unlikely ever to support as wide a range of devices as GKS. However it will provide faster, better quality pictures for our users and in the future may lead to generalised graphics displays from generalised data extracts. That has to be the way forward.