Everybody insists that there is a need for some standardization in computer graphics. Nobody agrees on either the level or content of a graphics standard. The wide diversity of users' interests and applications together with the large scale investment in existing software are the main reasons for the dichotomy. The variety of graphics devices, with very few features common to all of them, also makes standardization difficult.
An interesting analogy is the development of standards in programming languages. In spite of all its faults, FORTRAN is still the only widely accepted scientific, programming language. This standardization came about for a number of reasons. It was available, even in the early days, on a significant proportion of the computers used for scientific calculations. The input device, a card punch, had a measure of acceptance prior to the language definition. The output device, an available computer, had an order code which was not too dissimilar as far as arithmetic operations were concerned. An algebraic notation already existed which could be modified and used to express the arithmetic operations to be performed. The symbol + was well defined and standard names existed for functions like SIN, COS and TAN, More surprising is the acceptance of the symbol * for multiplication and ** for exponentiation - but then the limited character set made it difficult to consider other alternatives.
The definition of a graphics standard today has none of these advantages. Not even the basic primitive operations such as draw a line are well defined. As they are normally represented by routine calls, the possible names - even restricting them to six characters in length - are enormous in number. Furthermore, the only graphical notations tend to be in the area of geometry and are inappropriate here.
The first attempt at a graphics standard should not expect to achieve very much. Even an agreement on what is a line and what it should be called would be an achievement.
There are a number of levels at which standardization could take place. The main possibilities are at the code generation, language and application levels.
The code generator interface is analogous to the attempts to define a virtual machine code or UNCOL which was suggested a number of years ago. All compilers would generate the UNCOL pseudo code and there would be a single UNCOL assembler required for each computer. To produce M compilers for N computers requires M+N translators instead of M*N. Of course, the main problem is to choose an UNCOL that is suitable for all machines. Due to the diversity of machine order codes, no acceptable UNCOL was found. The same problem will arise in defining a graphics code generator interface. A virtual device must be defined which incorporates a significant number of the features of existing graphical devices. However, the differences in the capabilities of graphic devices in use today will almost certainly mean that a rigid code generator interface level will either force some devices to be very inefficiently programmed or will require large complex handlers for the simpler devices. It is likely that some expensive hardware may have to lie idle.
The language level is the one where some standardization should be possible both in the functions and formats to be made available. The ability to translate the standard for a particular device becomes easier the higher the level at which the interface is made. Too low a level will often mean that some facilities of a particular device cannot be used. At the language level interface, translation should be possible for a wide range of devices. This is also true at the applications level. However, the usefulness of the standard diminishes as the interface level gets higher. For example, a standard which only specified how to draw graphs would be of little use to many potential users.
This paper will concentrate on the problems associated with a language level interface defined to draw lines, output text and plot characters.
Any standard must be able to be defined in the languages in use today. Unfortunately, this will put constraints on the form that the standard takes. However, if it is to be accepted, there is no alternative. The problem can be illustrated by examples from existing languages. It is necessary to specify properties such as intensity and type to be associated with a particular line that is drawn. The approach in GPGS (2) and other languages (8) is to define a routine of the form:
CALL LINER(DX,DY,N,.....)
where N and the parameters following are optional and define the type of line and other properties associated with it. The alternative approach in GINO-F is to define a number of procedures which set up the current line drawing parameters:
CALL BROKEN(N)
CALL LINBY2(DX,DY)
It can be argued (7) that the GINO-F approach increases the number of routines required and increases the linkage overhead. However, the current FORTRAN standard does not allow a variable number of arguments in a subroutine call. Consequently, the GPGS solution is unacceptable. A standard defined with variable argument lists could not be used on at least one of the computer ranges supplied by a major manufacturer.
Another problem area is illustrated by this same output in DIMFILM (3):
CALL DASHDOT
CALL ONTOXY(X,Y)
The first routine called has a 7-letter name. Again, this is non-standard FORTRAN and is, therefore, unacceptable. Although a minor point, if a large number of similar routines are required, the ability to choose sensible mnemonics does become a problem. The proposed new FORTRAN standard still limits identifiers to a maximum of six characters. Any standard should be available on a wide range of computers. It is, therefore, important that the standard does not insist on facilities that are unavailable. For example, DISSPLA {6} requires integer quantities to be 32 bits in length. This immediately makes it impossible to mount on most small computers and some large ones without modification.
These are just a few examples. No doubt many others will arise. They must be given due consideration and will constrain the way in which a standard is defined.
Probably the most important requirement is to have the ability to draw a line - once this facility is available characters and points can be simulated. Let us consider the problem of defining how to draw a line between the two points (XP,YP) and (X,Y). The extension to three dimensions is relatively straightforward. The coordinates are defined in terms of some unit system which will be described later. The immediate reaction is to define a routine of the form:
CALL LINE(XP,YP,X,Y)
However, routines of this type appear in very few of the existing graphics packages. This is partly due to the type of graphics device in use when the package was defined and partly due to the kind of output required by the average user. Most of the pen plotters leave the pen at the end of the last line drawn and so it is only necessary to specify the next end point if the lines are joined together. Frequently, the user is simulating curves by a number of straight line segments and so this is an appropriate method of specification.
The more usual method of specification is to assume that the starting position of the line has already been defined - let us call this the current position and all that need be defined is the destination. This can either be defined absolutely by (X,Y) or relatively by (DX,DY) where:
DX = X-XP
DY = Y-YP
Most of the existing packages define an actual or conceptual current position. Problems usually arise when interaction occurs between line drawing and clipping. There is an obvious advantage if the current position need not be stored by the graphics package or device handler but could depend on the physical characteristics of the output device. For example, a pen plotter could define the position as the actual position of the pen at any point in time. However, if clipping is allowed this is no longer possible. A line that extends off the drawing area will be clipped so that the pen position will be at the edge of the drawing area while the current position is now (X,Y). {The next line drawn should not be connected to the previous one at the edge of the drawing area.) This is an important point as it releases the current position from having any equivalence to specific operations of the hardware.
Summarising, line-drawing commands will depend on a conceptual current position. Routines or functions provided will either change the current position, draw a line or do both. Unfortunately, this set of routines is not provided by any of the existing packages. For example, GINO-F provides a routine:
CALL LINT02(X,Y)
which draws a line from the current position (XP,YP) to (X,Y) and updates the current position to (X,Y). No routine is provided which draws the line but does not update the current position. Yet, there are places where such a routine is more appropriate - for example, a set of lines originating from a single point or a pair of axes. Also, hardware exists which has this capability.
By defining a current position, the implementation is likely to be more efficient. Less arguments are required per routine call and it maybe possible to optimise some hardware operations. Similarly, it is important to define routines in the standard if, as well as being natural to use, they also lead to an efficient implementation. The need for relative as well as absolute routines can be demonstrated in a variety of ways. Firstly, it is often natural to specify a line by a routine of the form:
CALL TODXY(DX,DY)
Also, relative drawing commands allow subroutines to be defined or pictures to be stored which define graphical information relative to some point which is defined outside the routine. Finally, the size of DX and DY is likely to be significantly smaller than X and Y which may lead to data compression if the information is to be passed using some communication media. Similar arguments can be used for providing special routines which define horizontal and vertical lines. Thus a box could be defined by:
CALL TODX(DX)
CALL TODY(DY)
CALL TODX(-DX)
CALL TODY(-DY)
There is a limit to the number of routines that should be provided. Too many and the implementor is unhappy and the user has difficulty remembering them. Too few and the standard may be inconvenient and inefficient both in the way it is implemented and in the way it is used.
Any standard should be capable of using most of the hardware features available on specific devices. There is always the danger that the standard will be at too low a level to allow this. It may be worth going back to consider our analogy with programming languages and compilers. Until recently, very few problems existed in compiling efficiently on most of the existing computers:
DO 10 I=1,100
A(I)=B(I)*C(I)
10 CONTINUE
However, the arrival of the machines capable of doing vector operations has changed things. No longer is the compilation task simple. The set of operations defined above can be implemented using one or two vector orders. The problem is that the FORTRAN language is at too low a level for the device. A language construct is required of the form:
A = B*C
where A, B and C are arrays.
This same problem will arise in graphics as the output devices become more complex. Already devices exist which can generate a complete set of lines by a single order. Some provision should be made in the standard for such devices. At the very least, routines should be provided for the production of graticules or sets of parallel lines. A more sensible approach might be the provision of a routine which outputs a pair of lines and a number of equally-spaced interpolated lines between the two specified.
So far, the facilities that have been discussed are essential in some form in a graphics standard. However, these facilities are inadequate for some graphics areas. In particular, it is necessary to consider the problems associated with drawing a line when we consider refreshed displays and computer animation. In both areas there is a requirement for pictures to be parameterised. The coordinates of the line may change depending on some parameter and it is inappropriate to define this before the graphic object is generated. Consider, rubber banding on a display or in-betweening in animation.
There is a need for the arguments to line-drawing routines to define the positions of variables which contain the required values rather than the variables themselves. Once more, the GPGS approach of having an optional argument which defines whether the main arguments are indirect references is unacceptable as it is non-standard FORTRAN. The approach in SPROGS has been to define special functions PRi which accomplish the indirection (5). However, this leads to the clumsy notation:
CALL TOXY(PR1(ANAME('XIND')),PR2(ANAME('YIND')))
which is only made acceptable by having a preprocessor which allows the user to write:
TOXY($XIND, $YIND)
The amount of software development required to achieve this is likely to be unacceptable in a standard to be made widely available. Separate routines could be defined which had indirect arguments but this would make the standard large. FORTRAN language experts will note that even the SPROGS approach is non-standard as functions are not allowed text arguments. However, all current implementations seem to allow this!
With the restriction that all names must be less than or equal to six characters, there may be problems in defining the set of mnemonics to use. Already the routine name must distinguish between:
Even defining a set of names is a non-trivial task.
Most graphical output needs some kind of annotation - even if it is only the user's name so that it can be returned! Here the problem of standardization is complicated by the possibility of text output being a primitive operation when hardware characters are available and a high-level one when the characters are generated as a set of lines. This is a complex problem which will only be touched on here.
The first problem is to specify a text string. Immediately, the problem arises of how to specify a variety of characters when only a limited character set is available. Again, if we consider standard FORTRAN, only 48 characters are available. For example, to generate the line of text:
This example
the GINO-F package requires:
CALL CHARS(16HT*LHIS EXAMPLE*.)
First, the length of the string must be defined and, in GINO-F, this is done by specifying an escape character (* in the example) which indicates that the next character is not part of the text but defines some control function. Thus, the full stop at the end of the string is used to denote the string terminator. An alternative approach is to have a second argument which defines the length of the string.
Many users require to access a large character set in a number of different fonts. It must be possible to change font - preferably in the middle of a text string - and it must be possible for a single character to represent a number of different characters so that the complete character set is made available. The method adopted in GINO-F is to use the special control characters L and U to shift between lower and upper case. Changes of alphabet have to be achieved by change of font. Probably the package most widely used for high quality text output is GROATS (4) which allows the user many fonts of 256 characters each. The characters in a particular font are accessed by allowing certain characters to act as generalised shift characters which cause the character being output to be displaced by a specified amount in the character set from the one indicated. For example, if upper and lower case A's have positions 64 apart in the character set and * is defined as a displacement of 64 then:
type ('*A')
would cause a lower case A to be output. The problem with this approach is that the character set must be defined with a particular ordering which may be inappropriate for some implementations and, therefore, inefficient. The ability to define control characters which indicate subscripting, superfixing, tabulation and underlining is also important. DIMFILM also allows control characters for intensity changing, italicising and change of font.
An alternative approach is to limit the character set to the number of characters that can be included in a text string but have the ability to change fonts. Thus upper and lower case alphabets would be in different fonts. If the font can be changed in the middle of a text string there is little difference between this approach and the controlled case changes of GINO-F.
One problem that has arisen when using GROATS is that for some alphabets there is no unique ordering which corresponds to the standard alphabet. For example, Greek letters are defined in different positions by some researchers. The answer may be for some mechanism to be provided for changing the positions of characters within a font. One possibility is to have a COMMON block which provides a conversion table from the character position to the character to be output. Manipulating the values in the COMMON block provides the required facilities. Finally, there are times when a particular character needs to be output depending on the numerical value of a variable. For example, it may be necessary to display the Ith letter of the alphabet or the Ith digit. Assuming that a rigid ordering of characters is not insisted upon, this facility can be provided by a routine or function which returns the character position of a particular character. For example:
J=CHARP(1HA)
CALL CHARN(J+I-1)
Where CHARP gives the character position of the particular character be output and CHARN outputs the character whose position is specified by the argument. In this case, the only restriction is that be alphabetic characters need to be consecutive.
Some method must be provided for defining the position at which the text is to be placed and what part of the string the position is to associated with. We already have the ability to define a current position for line drawing and this could also be used for text output. Alternatively, a separate text position could be defined. There are advantages and disadvantages for both methods.
The main problem that arises here is that, unlike line drawing, it may not be possible to define the current position once the text has been output. Devices do exist which generate variable spaced text where the end of the text is unknown to the software package even though it is possible to concatenate text to the end of the existing text. The GINO-F approach is to declare that the current position is unknown once the text has been output. SPROGS, on the other hand, leaves the current position at the starting position of the string.
Although this problem is primarily associated with variable spaced text, it also occurs when considering text where newline characters are allowed in the text string. This is particularly true if it is possible to redefine the character which causes a newline. Only if the software can completely simulate the hardware will this be possible and that restriction should not be imposed by a standard.
To which part of the text should the defined position be associated? The choices seem to be between defining the lower left corner of the first character and its centre. Unfortunately, hardware devices exist where it is either impossible to define the centre or the lower left hand corner accurately without having a large look-up table which may have to be updated dynamically. The choice is, therefore, likely to cause problems for some implementers whichever it is. The consensus seems to favour the lower left corner. A separate problem is the output of symbols to represent points on a graph. Character plotting in this case requires accurate alignment of the symbol's centre. Many packages treat this as a separate problem and provide a set of separate symbols for this purpose rather than complicating the text routines by having to deal with this situation.
Text will be displayed in a variety of sizes and it must be possible to specify the size. The choice is between defining special functions for establishing character size, aspect ratio and spacing on the one hand and using any facilities that exist for picture transformation on the other. Thus, a routine which expands all subsequent output by a certain amount could be used to increase the size of characters. However, this will mean that the initial size of the characters must be defined. The choice to some extent depends on how different unit systems are defined for the graphical output. If this is by changing the current transformation matrix, it is likely that this can be used for defining different character sizes. Alternatively, if coordinate systems are associated with regions, it is unlikely that a standard which insists on a separate region for each character string would be acceptable. In this case, it is likely that routines for defining character size would be required.
Any standard must provide facilities for the user to define the unit system in which he wishes to work. It is unrealistic and inappropriate for a standard to expect him to work in terms of raster positions or millimetres associated with a particular device.
Current systems seem to break into two main sets. The first allows the user to define one master coordinate system and allows him to perform transformations which, in effect, give him the ability to specify his graphical output in a number of different coordinate systems. The second defines the different coordinate systems explicitly by specifying particular regions of the display area and associating different coordinate systems with each. In both systems it is possible to define one unit system in terms of another and for the definition to be static or dynamic. Whether or not a subsequent change in the first unit system also changes the second is the important difference.
The major difference in the two approaches seems, to be in the way that windowing is handled. The transformation approach normally multiplies the relevant transformation matrices together so that, in effect, all unit systems are defined in terms of a basic coordinate system. If a window is defined, it is also transformed to the basic coordinates and applied at this level. This type of system achieves a degree of efficiency in return for a loss of flexibility. The region approach is to associate the window with a particular region. It is possible for a number of windows or shields to be active at the same time and at different levels.
The two approaches are fundamentally different and incompatible. Any standard must choose between them.
A particular problem exists when windowing is applied to textual information. Do the individual characters get clipped or does a complete character either appear or not? In many cases, if the characters are being generated by the hardware, it is not possible for the hardware to clip the character. If the characters are software-generated using the standard line-drawing commands, it may be difficult in a particular implementation not to have the individual characters clipped. In some applications - particularly computer animation - it is essential for individual character clipping to be allowed.
Any degree of standardization that can be achieved will be important. This paper has attempted to outline a few of the problems that will occur with even these most basic concepts. Nor is it possible to gloss over the problems and leave them unresolved. Anybody who has reprogrammed a package for a different computer or a different device will know the user outrage at each misplaced character or line. Any standard must be precise and must realize the full implications of the decisions that are made.
The main problem is that the facilities defined are all interconnected. Do the parameters defined for line drawing, such as intensity, also apply to text? Is clipping applied before the individual parts of a broken line are defined? Does picture rotation occur before or after clipping? The problems are endless.
I would like to acknowledge the many useful discussions I have had with my colleague, Eric Thomas, in the preparation of this paper.
1. GINO-F User Manual, Computer Aided Design Centre, Cambridge
2. GPGS Reference Manual RC-GFX-75002-0, Rekencentrum, Technische Hogeschool, Delft
3. DIMFILM Users Guide, University of London Computer Centre
4. GROATS Manual, Atlas Computer Laboratory, Chilton
5. SPROGS Manual, Atlas Computer Laboratory, Chilton
6. DISSPLA Beginners/Intermediate Manual, Integrated Software Systems Corporation, San Diego
7. Device Independent Graphics Software. Is it possible? by J R Davis, Computer Graphics, Vol 9, No 1, Spring 1975.
8. SHARE Specification for Standard Graphic Output Subroutines, Computer Graphics, Vol 7, No 1, Spring 1973
The preceding paper was not verbally presented, instead the author led a general discussion on the subject:
"What should not be covered during the workshop"
Let us start with a set of definitions.
Therefore as standardization of computer graphics is long overdue, I recommend:
Now, look at the following problems:
Consider the following comparison tables:
| Actual Device | Virtual Devices | Input Primitive |
|---|---|---|
| Tracker ball | Locator | Positioning |
| Keyboard | Text Input | Labelling |
| Tablet | Digitizer | Sketching |
| Light Pen | Picker | Identifying |
| Potentiometer | Input Number | Valuating |
| Pushbuttons | Input Logical | Switching |
Remove virtual devices from Input as unnecessary?
| Output Primitives | Virtual Devices | Actual Devices |
|---|---|---|
| Positioning | Current Position | Beam Position |
| Labelling | Text Output | Character Generator |
| Line Drawing | Vecto Output | Vector Generator |
| Naming | Namer | Limited Vector Generator |
| Point/Symbol Plotting | Symbol Output | Point Generator |
| Picture definition |
I would suggest that the following subjects should not be considered at all:
Constraints to be applied to any Graphics Standard: