These notes outline the functions that might be covered by a proposal produced by the workshop. They do not attempt to fully define a package/interface/etc., but are intended to set the scene for more detailed discussions. Although no representation has been defined, the functions apply equally well to a set of subroutines, a code-generator interface, a protocol or a stored picture format.
The structure of graphics systems is not covered by these notes but An approach to graphics system design Newell & Sproull, Proc. IEEE, April 1974, provides a suitable background.
As suggested in the paper setting out guidelines, these proposals only cover 2-D line drawing with software generated text for drawing annotation.
A table of devices and device parameters (speeds, channel numbers, paper size, buffer location, etc.) is to be supplied externally (e.g. on an input stream) and this call selects and initializes device N from that table.
This clears all display files, pictures, etc. to provide a clean sheet/screen for drawing on.
This closes down the device, releases the channel etc. in a clean way.
Sets the units which will be used to address the drawing areas. (XMIN, YMIN) is the bottom left-hand corner and {XMAX, YMAX) is put as near the top right-hand corner as it can be without changing the aspect ratio (default of (0, 0, 1, 1) if this function is not specified).
Specifies a rectangular area within which the drawing is to appear (default to device limits).
Sets the units which will be used to draw with. Similarly to Device Limits these coordinates are mapped as nearly onto the VIEWPORT as is possible without applying differential scaling (default to viewport limits).
Opens a new segment, and if an old one of the same number already exists deletes the old one.
Re-opens an old segment for further elements to be added to it.
Set status of segment N to highlight/refreshed/stored/off.
Ensure that all operations specified so far have been executed.
Move the drawing implement to the point (X, Y) without drawing. These coordinates are absolute and in terms of the window coordinates.
Draw a string of characters held in an array using the ISO code. This uses software characters only.
A table defining line styles (width, intensity, colour, dottedness, dashedness, etc.) will have been set up externally. This function selects the N'th style.
Selects the N'th font for characters - again these will be defined externally.
This sets the character size in terms of the units set by Device Limits.
This sets the angle between the baseline for characters and the horizontal (X) axis, to ANGLE radians.
If an error, fault or exception of any sort occurs, a fault condition is set. This may be examined and cleared.
Data indicating whether a fault exists and if so defining it is put into the array and the fault is cleared.
Generates a fault condition that will return the values in ARRAY when interrogated by Getfault. If an attempt is made to execute any graphical function while an uncleared fault condition exists then the function is ignored and a suitable monitor executed.
The following transition networks define the syntax for the functions defined above. The networks are read from left to right and top to bottom unless otherwise indicated by an arrow. Uppercase words denote the functions - with parameters omitted - and lower case letters denote nested transition networks. (The networks define an interpreter rather than a generator).
At a meeting of the organizing committee in Bellinglise, January 1976, it was decided to have an exhaustive look at computer graphics systems. A method of achieving this was thought to be by establishing a matrix spreading graphics systems functions on one side and graphics systems representations on the other side. This led to several quite different presentations. The discussion that started at the SEILLAC workshop from these presentations became very involved. Thus, it was clear that this scheme could not be carried on any further, due to a lack of understanding of the conceptual differences between representational division and functional division. At this point the workshop left the conventional track and, throwing the agenda aside, embarked on what has proved to be a very creative and fruitful course. A decision was made to create a list of what was considered to be the important divisions. The importance of these divisions were then revealed by each person indicating which division he would devote his time to during the workshop, Thus, sub-groups were established to study what was considered to be, at that time, the issues which would help us understand the essential concepts.
It was the intention of the committee that the content of the divisions - at the functional and the representational levels - would provoke action that could clarify many of the ambiguous concepts.
We have included only one of the presentations to give a flavour of the kinds of Matrices that were under discussion.
It was proposed that for a short period we could endorse a particular graphics package and help to distribute it.
Editor's note: It was decided that we should discuss the following points, contrary to Sancha1s paper:
The discussion then concentrated on the advantages of the bottom-up, functional approach proposed by van Dam versus the top-down approach favoured by Newell. It appeared for a while in each case that the end-goals were the same, but then the bubble burst and two quite different approaches appeared:
Approach A:- at the level of primitives, transformations, attributes, etc.
Approach B:- at the level of program structures for various system configurations - (use structures to deduce general needs of graphics packages).
The following (Chapter II) roughly edited documents are the results of the two approaches.
We have gathered as a third set, under Miscellaneous, the working documents which could not be directly related to approach A or B.
