The material supplied by the other members of this subcommittee, supplemented by a few relevant papers from other sources, amounted to over 80 papers, or just over 10 kg. I decided not to include the contents of my bibliographies on shape representation and on contouring, as these were not central to the theme, and would have unbalanced the presentation. The list of material taken directly into account forms Appendix A. Full references were not always determinable from the papers themselves.
My first analysis of the literature was to categorize the papers. I chose as categories
Few papers fitted more than one category, or failed to fit at all. The categorization forms Appendix B.
These approached the topic from diverse directions. The survey of computer graphics by Shopiro(26) was the most complete at the fundamental level; that by Meads(8) most complete at the designing-a-package level. The idea that geometric items (particularly points) should be considered as single data items was suggested by Schlechtendahl and Schuster (l5) and by Balzer et al {22). The latter also raised the question of compatibility with Numerical Control, an aspect important for mechanical engineering applications, and possibly significant more generally.
The classification of levels of graphics was made in a number of papers. Other classifications seemed compatible with that of Schlectendahl and Schuster, who identify
Shopiro makes the point that definition of the thing to be drawn should be specified separately from the view to be made of it. This distinction is more easily drawn for the graphic presentation of geometrical objects than for the presentation of data. It could be argued, however, that the window/viewport mechanism has its window part in the object definition and the viewport in the view definition. The distinction between objects and data as far as appropriateness of facilities is concerned is an important one. It cannot be assumed that a package which is good for one is automatically good for the other.
The papers (82) (16) (17) (18) (which should be read in that order) form a sequence in which ideas are developed, the principal argument being that the most pressing need is for a standard at the level immediately above the device-dependent part of the system.
Input is dealt with by (26) (49) (57) as well as by many of the package descriptions. From the device independence point of view it is generally agreed that different physical pieces of equipment can be used to convey the same information from man to machine. The two main classes of input data, Pointers (or selection) and Positions (or value input) are identified, with extra frills which differ from author to author, but which are not very significant.
In general it does the authors of all these papers a grave injustice to summarize their points.
Hardware Aspects and Usages I regarded as forming the environment for which the software interfaces we are discussing should be designed. Few of the source papers fell into these two categories, and I felt that rather than draw conclusions from an unrepresentative sample, it would be better to concentrate on the other categories.
Similarly, the papers describing facilities in languages other than Fortran were either making points applicable equally to Fortran, or were concerned with the specific syntax or style of the particular language.
The bulk of this survey concentrates therefore on descriptions of actual software interfaces in the categories:-
I found these most stimulating, because a language contains the essence of the facilities offered, with the minimum of overhead. It seems to me that the requirements on a general picture description language are much clearer and much more pressing than on a package of subroutines.
The requirement of legibility influences mainly the lexical and syntactic structure. The requirement of doing something useful cheaper than doing it by hand implies either application oriented features, implicit or explicit calculation features, an outer syntax for repetition or all three, whereas a subroutine package can reasonably expect the facilities of Fortran to supply all these.
The languages examined are:-
Each language has its own syntax, which I have tried to ignore. More important, each has its own facilities, and I have tried to summarize these.
| DRAW | ARTIST | GPDL | G439 | PDL2 | MONSTER | |
|---|---|---|---|---|---|---|
| References | (5) | (10) | (59) | (60) | (71) | (72) |
| Dimensionality | 2D | 2D | 3D | 2D | 2D | 3D |
| Primitives | ||||||
| Polygons | * | * | * | * | * | * |
| Full circle | * | |||||
| Circular arc | * | |||||
| Smooth curve | * | |||||
| Special | * | |||||
| Solid body transformations | * | * | * | * | * | |
| Separate define and draw | * | 1 | 2 | * | * | |
| Grouping | * | 1 | ||||
| Repetition | * | |||||
| Computation | ||||||
| Implicit by access to transformed items | * | * | 3 | |||
| Other implicit | * | * | 3 | |||
| Explicit | * | |||||
Notes:
I have grouped together here two slightly different types of software interface. This is deliberate, and is partly because only one protocol designed specifically as such was described in my sources, partly because the difference is only slight. Essentially we are concerned with a format for transmission of graphical information from one process to another, separated either by space or by time, or just for convenience of development. The context is that computing power is available both when writing and when reading the stream. One would expect that the bulk of a format which was efficient for storage of pictures or subpictures would also be applicable to the efficient transmission of pictures from one site to another.
The systems examined are:-
The version of BIPS considered is the form used by Mott, Hay and Anderson both for plotter output and digitizer input and also for transmission of graphics to and from timesharing computer facilities.
It differs from the DoE original, by having a legible format. Everything except text is passed as digits.
Both CLDATA and NCPT are recognitions and formalisations of de-facto standards. Many post-processors exist to convert CLDATA to graphical form, and many tape-check programs have been written to plot tool trajectories from NCPT. Indeed, some large flatbed plotters use the NCPT format on their spooling medium.
I would have liked to include also the internal formats of the GMB system, of GINO-F and of the MULTICS graphics facilities, but did not have enough information available to be able to do so.
In the table which follows note that absence of a feature may, or may not be significant. For some features (e.g. transformations, clipping) absence merely means that that facility is viewed as an upstream activity. For others (e.g. naming, precise scaling) it critically affects the usefulness of the format for certain applications.
| NGP | L4 | IDATA | GRID | BIPS | CLDATA | NCPT | UGP | |
|---|---|---|---|---|---|---|---|---|
| References | (4) | (56) | (28) | (39) | (80) | (81) | (82) | (83) |
| Dimensionality | 2D | 3D | 3D | 3D | 2D | 3D | 3D | 2D |
| Legible | * | * | ||||||
| Provision for interaction | * | * | * | * | ||||
| Naming | * | * | 1 | * | * | |||
| Precise scale | * | 2 | * | * | * | * | ||
| Rel/Abs | Abs | Both | Rel | Rel | Abs | Both | Both | Abs |
| Primitives | ||||||||
| Straight line | * | * | * | * | * | * | * | * |
| Full circle | * | |||||||
| Arc | * | * | * | * | * | * | ||
| Smooth curve | * | 0 | 0 | |||||
| Text> | * | * | * | * | * | * | * | |
| Others | 3 | 4 | ||||||
| Transformations | ||||||||
| S.B.T. | * | * | ||||||
| Log scales | * | * | ||||||
| Clipping | * | * | ||||||
| Space savers | 5 | 6 | 5,7,9 | 8,9 | 7 | 9 | ||
Notes:
Because information theoretic measures are clearly relevant to transmission of information (although none of the sources explicitly made this point), I calculated the number of bits needed to represent a simple picture in each format. The picture consisted of a diamond containing a square and an asteroid-like shape made of four circular arcs.
The height and width of this figure I made 10 inches (250 mm) and I assumed it to be plotted on a device with a resolution of 0.001 inches (0.025 mm), and just over 10 inches square in plotting area. For formats without the arc primitive, I assumed the arcs to be represented by 46 vectors each, this being the figure which gives a chord height of 0.002 inches (0,05 mm), the limit of visibility. I hope that originator of new proposals will publish what they consider to be realistic test shapes, with the corresponding bit-counts for their systems.
In almost all cases I was making guesses as to details of the formats, some of which I will be mistaken in. In any case a single example is not a statistically significant sample. To minimise injustice the bit counts are tabulated separately for: housekeeping data, the diamond, the square and the arcs, so that reasons for the scores of particular systems may be examined.
| NGP | L4 | IDATA | GRID | BIPS | CLDATA | NCPT | UGP | |
|---|---|---|---|---|---|---|---|---|
| Housekeeping | 336 | - | 32 | 232 | 216 | 72 | 32 | 298 |
| Diamond | 200 | 400 | 200 | 360 | 540 | 1116 | 488 | 176 |
| Square | 200 | 400 | 136 | 360 | 540 | 1116 | 280 | 176 |
| Arcs | 7400 | 11856 | 328 | 832 | 1404 | 21132 | 968 | 432 |
| TOTAL | 8136 | 12656 | 696 | 1784 | 2700 | 23436 | 1768 | 1082 |
In a reasonable weighting scheme the influence of the housekeeping would be reduced and that of the diamond increased. The best/worst ratio is probably nearer 6:1 than the apparent 30:1 which the totals imply.
This is an aspect which we should be concerned with, particularly as I was surprised that two systems as apparently similar as IDATA and GRID should have proved so different in bit count. Before doing the calculations I was expecting them to score about equally.
It is possible to identify particularly costly features.
Legible formats. In my view this is a cost worth paying, particularly as the PTTs seem likely to be standardising on a six-bit character as the unit for transmission, which makes transmission of numbers as digits just over 50 percent efficient instead of just over 30 percent. After calculating all these figures I designed a modification/extension of NCPT suitable for shapes like that of my example. Assuming 6-bit characters instead of the 8 allowed in the above table for NCPT I achieved scores of 0, 58, 144, 174 and 294 in the separate categories, giving a total of only 612.
The text of this description is
XY5/X5Y/X10Y5/X5Y10/XY5E X2.5Y7.5/X7.5/Y2.5/X2.5/Y7.5E X2.5Y7.5/X7.5B4142/Y2.5B4142/X2.5B4142/Y7.5B4142S
Odd details.
The arcs of GRID are expensive relative to IDATA merely because the centre is taken as the current position.
Absolute coordinates are better by one bit than relative coordinates, except where a sequence of short vectors are used to represent some curve for which a primitive does not exist.
The pointer structure of L4 increases its costs BIPS uses 6 characters (36 bits) for its first field, where only 4 bits of information are carried.
All the formats considered except possibly NCPT use the Prefix Polish syntax, and even NCPT may be considered to be of this form if the field level rather than the record level is considered. It is therefore possible to think in terms of a superset. In my view any attempt to combine features into a superset would be a big mistake, and would result in an utter mess. Each of the systems is based on a particular philosophy, and the considerable differences between NGP and IDATA, for example, are the result of the extreme differences in their philosophies - NGP deliberately aims to have as much computation as possible done in the source of the data, IDATA deliberately aims to leave as much as possible to the recipient.
If we are to make any useful contribution to this area it must be by making arguments at the philosophical level. The technical decisions will follow from there.
I use this term rather than Subroutine Packages, because it applies more generally than to only Fortran systems. Algol 60 and PL/I can use very similar library mechanisms, and, although Algol 68 allows much better notation by the full exploitation of a prelude, a mere procedure package can be handled.
This proved the most difficult form of software interface to survey, partly because of the large number of systems examined, but more because of the variation of presentation of the descriptions, and because of the arbitrariness and subjectiveness of criteria for comparison. It became quite obvious that designers of procedure libraries have been using criteria relevant to languages and protocols, even when the applicability of these criteria to a library does not stand up to analysis. Many packages, for example, allow alternative calls with incremental, absolute or local coordinates - a very useful piece of implicit calculation for a language interface - but it is not clear that the additional complexity added by the extra calls is justified, when the addition or subtraction necessary to convert to a single form can be done as effectively outside the package as in.
Again, some packages (e.g. UGP (25)) offer Macros which, because they are apparently expanded before the intermediate file appear to offer no advantages over the writing of high level Fortran subroutines containing the low level calls.
Because the interface between the package and the rest of the application program is of no significance once linking is complete, it is not important to minimise the flow of information across the interface, as it would be in the case of a protocol.
What, then, can be used as criteria by which to classify and compare procedure libraries.
We can compare facilities, although in most cases the missing features can be added as an extra layer so easily that they cannot be regarded as fundamental deficiencies. Indeed, in GMB(20) the concept expressly includes the addition of user-oriented routines, and in PHILDIG (34) certain utilities are provided, which are not tightly bound to the rest of the package. Facility lists can best be regarded as indicators of the application-orientation of each system.
We can hint at the computer independence by considering the source language in which the systems are written. Note that a system being written in Fortran does not ensure its portability. GPGS and UGP, at least, use a machine dependent form of Fortran interface which allows optional arguments.
In many computing environments, procedures are compiled into a common form, and, provided certain linkage conventions are adopted, can be mixed freely with routines written in other languages. The category environment in the table below therefore notes only where a particular language is specified in the documentation.
The category source notes the source language of the package only where this is clearly stated. For the above reason the language of the source text usually influences only the portability of the library, not its applicability.
There are two measures of just how device independent a package is. The first is the obvious how many different devices has it been implemented for. This can vary so rapidly with time that it is hardly worth tabulating. The second is the point in the progress of a program from conception to completion of actual graphic output at which the binding of the potential output to a particular device is made.
The facilities available, tabulated in the categories: Primitives, Transformations, High-level Features, Segmentation, Naming and Input, serve mainly to identify the application orientation of the packages. These tables are included for completeness rather than for significance. Any blank entry should be regarded as indicating absence of evidence in the documents available, not absence of the feature.
The libraries examined are:-
There are a number of significant omissions from this list. Omnigraph, IBM GSP, GINO-3, Tektronix and Calcomp software in particular. There are also many other packages being used in real work to good effect. Those included do, however, span a broad range, and this document is not intended to be a shopping guide.
| Refs | Environment | Source | Binding | Dimensionality | |
|---|---|---|---|---|---|
| COLOR | (2) | W | 2D | ||
| GHOST | (9) | P | 3D | ||
| DIGS | (14) | PL/I | C | 3D | |
| PHILDIG | (19,34) | C | 2D+3D ut. | ||
| GMB | (20,21 | C | 3D | ||
| UGP | (23,25) | C/P | 2D | ||
| GRAFSY | (24) | 2D | |||
| GINO-F | (29,30,31) | Fortran | C+R/P | 3D | |
| GPGS | (32,36,37,46) | R | 3D | ||
| SPROGS | (33,66) | C+R | 2D+3D ut. | ||
| GPGS-F | (35) | R | 3D | ||
| AUTOPROD | (40) | Fortran | L | 3D | |
| MIDI | (41,44,45) | LP15 | - | 2D | |
| OXSYS/BOS/T | (42) | C+R | 2D | ||
| DC300 | (47) | W | 2D | ||
| AMESPLOT | (50) | L | 2D | ||
| KV | (53) | W | 2D | ||
| DISSPLA | (54) | L | 2D | ||
| GRAFPAC | (55) | Fortran | R | 2D | |
| HGPLOT | (61) | L | 2D | ||
| G3D | (62) | L | 3D | ||
| GROATS | (67) | Algol 60 | W | 2D | |
| POLYGRAPHICS | (68,69) | W | 2D+3D ut. | ||
| ANOTHER | (73) | L | 2D | ||
| DIGRA | (74) | - | 3D | ||
| LOGIGRAF | (75,76) | - | 2D | ||
| MULTICS | (83) | R/P | 3D |
| Straight Line | Circle | Arc | Curve | Text | Other | |
|---|---|---|---|---|---|---|
| COLOR | * | * | Filled Ars | |||
| GHOST | * | * | * | |||
| DIGS | ||||||
| PHILDIG | * | * | Tables | |||
| GMB | ||||||
| UGP | * | * | * | Tables | ||
| GRAFSY | * | * | * | * | * | Polygon |
| GINO-F | * | * | * | |||
| GPGS | * | * | * | Tables | ||
| SPROGS | * | * | Tables | |||
| GPGS-F | * | * | * | Tables | ||
| AUTOPROD | Objects | |||||
| MIDI | * | Tables and Axes | ||||
| OXSYS/BOS/T | * | * | * | Rectangles | ||
| DC300 | * | * | * | |||
| AMESPLOT | * | * | * | |||
| KV | * | * | * | * | ||
| DISSPLA | * | * | * | |||
| GRAFPAC | * | * | Tables | |||
| HGPLOT | * | * | * | * | Tables | |
| G3D | * | * | * | 3D Calcn Facilities | ||
| GROATS | * | * | Rectangles | |||
| POLYGRAPHICS | * | * | * | * | Tables | |
| ANOTHER | * | * | * | |||
| DIGRA | * | Objects | ||||
| LOGIGRAF | * | * | Tables | |||
| MULTICS | * | * |
| S.B.T. | Window | Clip | Log | Precision | Other | Coords | |
|---|---|---|---|---|---|---|---|
| COLOR | * | L | |||||
| GHOST | * | * | * | ||||
| DIGS | * | * | * | ||||
| PHILDIG | * | * | * | A+R | |||
| GMB | * | * | * | ||||
| UGP | * | * | * | A | |||
| GRAFSY | * | * | * | L | |||
| GINO-F | Persp | * | * | * | A+R | ||
| GPGS | Persp | * | * | A+R | |||
| SPROGS | * | * | * | A | |||
| GPGS-F | Persp | * | * | A+R | |||
| AUTOPROD | View | A | |||||
| MIDI | * | R | |||||
| OXSYS/BOS/T | * | * | A+R+L | ||||
| DC300 | * | A | |||||
| AMESPLOT | * | * | Polar, Maps | A | |||
| KV | * | * | * | ||||
| DISSPLA | * | * | Polar, Maps | A | |||
| GRAFPAC | * | * | * | 3 to 2D | A | ||
| HGPLOT | * | L | |||||
| G3D | * | * | L | ||||
| GROATS | * | * | * | A | |||
| POLYGRAPHICS | * | A | |||||
| ANOTHER | Linear | * | * | A+R | |||
| DIGRA | * | * | A | ||||
| LOGIGRAF | RtAngles | * | * | A+R | |||
| MULTICS | * | R |
| Axes | Graph | Isom. | Bars | Pies | Contouring | Other | |
|---|---|---|---|---|---|---|---|
| COLOR | * | * | * | * | * | * | |
| GHOST | * | * | * | * | |||
| DIGS | |||||||
| PHILDIG | |||||||
| GMB | |||||||
| UGP | * | * | |||||
| GRAFSY | |||||||
| GINO-F | * | * | |||||
| GPGS | |||||||
| SPROGS | * | * | * | * | Box | ||
| GPGS-F | |||||||
| AUTOPROD | |||||||
| MIDI | * | ||||||
| OXSYS/BOS/T | |||||||
| DC300 | |||||||
| AMESPLOT | * | * | * | * | |||
| KV | * | ||||||
| DISSPLA | * | * | * | * | * | ||
| GRAFPAC | * | * | |||||
| HGPLOT | * | * | |||||
| G3D | |||||||
| GROATS | * | * | * | Hatching | |||
| POLYGRAPHICS | * | ||||||
| ANOTHER | |||||||
| DIGRA | * | Intersections | |||||
| LOGIGRAF | |||||||
| MULTICS |
| Names | Modify | Delete | Extend | Input | |
|---|---|---|---|---|---|
| COLOR | |||||
| GHOST | |||||
| DIGS | T | Move | * | * | Virttual |
| PHILDIG | T | * | * | * | Virtual |
| GMB | * | * | |||
| UGP | 1 | * | yes | ||
| GRAFSY | Move | * | * | Device oriented | |
| GINO-F | 1 | Visibility | Tek-typ | ||
| GPGS | 2 | * | * | Device oriented | |
| SPROGS | |||||
| GPGS-F | 2 | * | * | Device oriented | |
| AUTOPROD | |||||
| MIDI | 2 | Move | * | * | * |
| OXSYS/BOS/T | Attr | ||||
| DC300 | |||||
| AMESPLOT | |||||
| KV | |||||
| DISSPLA | |||||
| GRAFPAC | |||||
| HGPLOT | |||||
| G3D | |||||
| GROATS | |||||
| POLYGRAPHICS | |||||
| ANOTHER | 3 | Attr | * | * | Device oriented |
| DIGRA | |||||
| LOGIGRAF | 3 | Attr | * | Device oriented | |
| MULTICS | T | Yes |
Several of the systems examined use the front end - back end structure, with a formal interface between the device independent high level facilities and the device dependent drivers. GHOST, GMB, UGP, GINO-F and MULTICS are all of expressly this structure. The MULTICS interface is of interest, being semi-legible, suitable for transmission as a piece of text rather than as a bit or byte stream.
Others are built as layers, with a number of successive additions. ANOTHER is built this way, and is clearly described in {73}.
A third possibility for the structure is the pipeline used in AMESPLOT. I was pleased to see the idea described in (50), having implemented the G439 language using a very similar concept. The commands pass down a pipe through a sequence of transformations, the idea of transformation being very general, including, for example, syntax analysis and interpolation of curves as well as rotations.
Of the three the layer structure appears best able to accommodate maverick hardware with isolated high level features. It is equivalent to a forked (confluent) pipeline.
Different devices can be bound with a number of mechanisms. Parallel routines are used by SPROGS. Device tables are used by GMB and by any systems using the Network Graphic Protocol or Multics. NGP receives its tables by enquiry within the protocol, the other two have them set up by external means. GINO-F uses an interactive mechanism against which I have already argued in (17), but which may not be much more inefficient than continual reference to the tables. Parallel routines are probably the most efficient, provided that the link editor can be persuaded to omit those not used.
The overriding impression gained from reading all these documents is the extent of consensus already existing, particularly if one considers only subroutine packages.
The concept of sequence, either of vertices in a polygon, or of calls which use current position to link each call to the next, is used universally in the packages, even though no sequence is inherent in the final picture, and not all the self-contained languages use it. This is a very significant point, because there already exist international standards for the specification of sequential geometric configurations. The ISO standards for the CLFILE and for machine tool control tape formats are completely relevant, and we should propose alternatives only with good, well argued reasons.
Modal variables are used widely, mainly because of the combinatorial explosion if different calls need to be made for every combination of linewidth, colour, line-style, geometric form, transformed or untransformed, relative or absolute coordinates etc. etc. and because of the large number of parameters if every aspect has to be specified in every call.
Modality also allows facilities such as naming to be implemented in a way which does not impose overheads on users who do not require the facility.
Two concepts not widely recognized are the block structure concept and the pipeline concept. The block structure makes mode changes at the start of a block, relative to whatever was outside, and the mode changes last until the end of the block. Some graphic hardware uses this concept for linear transformations, but it can be applied much more generally. The pipeline implementation concept imagines a number of processing actions arranged in a sequence. Each atom in the graphic stream passes through the actions in turn sometimes unchanged, sometimes acted upon by the processors, sometimes being transformed into one or more atoms of a different kind, sometimes providing a processor with information for the subsequent action of that processor.
These two concepts are not necessarily compatible. Where transformations are not commutative the block structure determines which of the two products are required by the sequence in which the transformations are applied; the pipeline structure imposes its own sequence on the combination (unless both transformations are applied at the same point along the pipeline).
Each of these may be applicable in specific circumstances. The combination of linear transformations is now generally recognized as being determined by the sequence in which translation and rotation are called up: the combination of circular interpolation and logarithmic scales is not obvious.
Detailed discussion of particular pairs of transformations would be a useful exercise, to determine whether a generally acceptable, consistent pipeline sequence exists.
Dynamic sequencing of the pipeline can be achieved in a package context by use of nested functions. This implies either that transformations involving storage (e.g. macro expansion, fillet radius insertion) are excluded, or that the functions take complete geometric descriptions (e.g. at least of profiles) for their arguments and values. The latter implies a separation of definition from transformation and actual display. This may well be desirable. It is also only possible within Fortran by means of tricks, such as using integer variables to implement pointers to the actual data items. This would make the package based on such concepts somewhat difficult to become familiar with.
The question of device binding time is also worthy of discussion, because there appear to be significant storage overheads involved in run-time binding in a subroutine package as compared with link-time binding or alternatively with run-time binding as an operating system function.
The naming issue should be discussed in some detail. In particular we should identify whether it is possible to build first single level naming, then hierarchic naming, as optional extras on to a system which runs without any overheads in its basic form for passive graphics. If so the whole question of single versus multilevel naming is bypassed. If not, then that question also needs consideration.
I am disappointed at the length of time it is taking for language processing ideas to be applied to graphic input. The next step from the idea of virtual devices, now widely accepted, to that of graphic lexemes is such a small one. With the known techniques of Syntax Description Languages, I wonder what the difficulty is.
NGP distinguishes between events and states for input. Events are clearly lexemes in the input stream, but states, which can be monitored continuously, at a regular rate, or at random, can also be fitted into a language processing view. This can be done either by:
As a result of writing this survey I am confirmed in my opinion that the most useful discussion we can have will be related to a format for storage and transmission of graphic data. We should aim to identify criteria by which we can compare proposals quantitatively (the bit-counts used in this paper are indicative of the possibility of a quantitative approach, though not themselves adequately thought out). We should also identify the implications which features of such formats might have for subroutine packages and ergonomic languages using them in both batch and interactive contexts.
Thanks are due to all those who supplied literature for this survey. In particular to BAC and ICL who made internal documents available; to Mott, Hay and Anderson and to NEL, who were of great assistance in supplying information about BIPS, CLDATA and NCPT; and to Kongsberg Ltd. who supported my presentation of this material.
(1) Color Jet Plotter. glossy brochure
(2) Color Jet Plotter. program introduction
(3) Graphics in the BASIC Language. Luehrman and Garland, CGQ Vol 8 No 3 pp 1 - 8, 1974
(4) A Network Graphics Protocol. Sproull and Thomas, CGQ Vol 8 NO 3 pp 27-51 1974
(5) DRAW. M. Smith, CGQ Vol 8 No 2 pp 1 - 11 1974
(6) MAPS - A Generalized Image Processor, Fischer, CGQ Vol 7 No 3 pp 29 / 37 1974
(7) Graphics in APL. Bork CGQ Vol 7 No 3 pp 29 - 37 1973
(8) Basic Graphics Support. Meads CGQ Vol 7 No 3 pp 38 - 53 1973
(9) GHOST. Walsh and Prior CGQ Vol 7 No 2 pp 13 - 15 1973
(10) ARTIST - Abstract Linda Shapiro CGQ Vol 7 No 2 pp 39 - 42 1973
(11) Plato IV CGQ Vol 6 No 2 pp 7-9 1972
(12) Computer Graphics Glossary 1970
(13) Raster Graphics for Spatial Applications Fischer and Nunley CGQ Vol 9 NO 2 pp 1-8 1975
(14) DIGS + Satellite Computer Graphics at UNC J.D. Foley 1975
(15) Some remarks on Standardization of Graphical Software Schlectendahl, E.G. and Schuster, R. undated
(16) Graphics Standards and Design Criteria for the Codegenerator Interface Sancha, T.L. 1975
(17) Responses to item 16 Sabin, M.A. 1975
(18) Some notes on Software Standardization Sancha, T.L. 1975
(19) PHILDIG B.Fink 1975
(20) GMB - a graphics software system E. Horbst undated
(21) An integrated graphics system which provides the use of various graphic terminals. Horbst, E, Geitz, G., and Gonauser, M. Interactive Systems pp 45 - 56
(22) Allgemeine Gesichtszeunte zur Normung von Grundfunktionen der Grafischen Datenverarbeitung Balzer et al. 1975
(23) UGP Encarnacao and Hunger undated
(24) GRAFSY Konkard and Engl undated
(25) UGP II Programmers reference manual
(26) Survey of Computer Graphics J.E. Shopiro Jan 1974
(27) Interaction with Visual information D.J. Grover CAD 74 Proceedings
(28) I-DATA Specification ICL 1969
(29) GINO-F Standard Graphics Software H.W. Bradley Aug 1973
(30) Technical description of GINO-F R.G. Newell Aug 1973
(31) GINO-F External Specification July 1974
(32) GPGS Preliminary design specifications Groot and Patberg July 1972
(33) SPROGS Manual R.E. Thomas Jan 1974
(34) Phildig subroutine call specification undated
(35) GPGS-F Users Guide Sept 1975
(36) GPGS Draft reference manual July 1974
(37) GPGS Users Guide part II July 1974
(38) Minutes of Graphics Standards planning committee 14 July 1974
(39) GRID W. Prior Aug 1973
(40) AUTOPROD / Introductory synopsis Col.F.A.N.Hitch Dec 1974
(41) Midi, Un systeme de programmation graphique pour mini ordinateur J.P.Crestin, J. Hugues and M. Maille Journees Graphiques 1973 Colloques AFCET-IRIA, Paris 1973
(42) OXSYS/BOS/T Applied Research of Cambridge 27 Nov 1975
(43) Comparison of GINO-F, MEDALS and 2-DG E. Hoskins part of a report by Applied Research of Cambridge
(44) Systeme Graphique MIDI. Dossier de realisation R.Houdas, J. Hugues ENSTA Groupe dlnformatique interactive Rapport Interne Oil 1973
(45) Systeme Graphique MIDI. Manuel de Utilization J. Hugues ENSTA GROUPE DInformatique interactive Nov 1973
(46) GPGS Users Tutorial L.C. Caruthers and A. van Dam Graphics Group University of Nigmegen 1975
(47) DC300 Fortran Driver Kongsberg Vaapenfabrikk Dec 1974
(48) Conversational Building and Display of Solid Objects V. Casanove - IBM, Pisa S. Trumpy - CNUCE, Pisa
(49) Languages for Graphic Attention Handling I.W. Cotton UNIVAC Pennsylvania unidentified journal pp 1049 - 1091
(50) AMESPLOT - A Higher Level Data Plotting System lan Hirschsohn CACM Vol 13 No 9 Sept 1970
(51) A program for spectral analysis using a graphic display system. Bertil Ekenberg Institutionen for informationsbehandling Lund, Sweden
(52) Interactive design of interpolated surfaces V. Casanova, E. Dettore, S. Trumpy CNUCE, Pisa
(53) Kongsberg Drifting Routines Kongsberg Vaapenfabrikk Feb 1974
(54) The DISSPLA Graphics Software Package Marya Repko Proc, CAD 76 March 1976
(55) GRAFPAC Graphic Output Subroutines for 'the GE 635 Computer F. James Rohlf Computer Contribution 36 State Geological Survey, Univ. of Kansas 1969
(56) APLG - An APL based system for interactive computer graphics W.K. Giloi and J. Encarnacao Proc. Nat. Comp. conf. 1974 pp 521 - 528
(57) Organisation des systemes d aides graphiques Repartition des fonctions entre le materiel et les logiciels R.A. Guedj Proceedings of CAD 75 Milan June 1975
(58) Interactive graphics on intelligent terminals in a timesharing environment W.K. Giloi, J. Encarnacao and S. Savitt Proceedings of CAD 75 Milan June 1975
(59) A graphical picture drawing language M.G. Notley Computer Bulletin March 1970
(60) Program G439 M.A. Sabin British Aircraft Corporation internal document May 1970
(61) Notes on the ICT Graph plotter K.W. Tate British Aircraft Corporation internal document undated.
(62) List of G3D Subroutines part of British Aircraft Corporation internal document 1976
(63) Methods for plotting a function of one variable M.J.D. Powell Course notes on Plotting A.E.R.E. Harwell ETC/L 1245 1973
(64) Methods for passing a smooth curve through a sequence of data points. M.J.D. Powell Course notes on Plotting A.E.R.E. Harwell ETC/L 1246 1973
(65) Methods for plotting contours of a of two variables. M.J.D. Powell Course notes on Plotting A.E.R.E. Harwell ETC/L 1249 1973
(66) SPROGS supplement R.E. Thomas Atlas Computer Laboratory Jan 1975
(67) GROATS Manual D.C. Toll and F.R.A. Hopgood Atlas Computer Laboratory June 173
(68) Polygraphics on the IBM 370/195 John W.E. Lewis Atlas Computer Laboratory June 1973
(69) The Polygraphics Software Package -of its features. Frank J. Sarno UAIDE 1968 pp 402 - 408
(70) Automating animation G.A. England, J.R. Gallop, F.R.A.Hopgood and R.E.Thomas Atlas Computer Laboratory ONLINE 72 Conf.Proc. pp 445 - 463 1972
(71) Pictorial description language Geoff Wyvill Interactive Systems pp 511 -
(72) Monster - A graphic language Per Jacobi Laboratory of Computer Science School of Architecture Copenhagen
(73) The design of another graphics subroutine package Peter Darvars, Peter Hosszu and Gergely Krammer MTA SzTAKI 1111 - Budapest, Kende uu. 1317 Hungary
(74) Anwender Information 18/71 Programmsystem DIGRA Institut fur Schiffbau - Rechenzentrum Rostock June 1971
(75) Logigraf summary Pistenon
(76) Logigraf - description Compagnie d Informatique economique et technique
(77) Device Independent Graphics Design Criteria for Network Protocols and Subroutine Packages report of meeting of B.C.S. C.A.D. Specialist Group Dec 16 1974
(78) Raster Scan Graphics in CAD W.M. Newman proc. IFIP WG5.2 working conference on CAD systems Austin Texas Feb 1976
(79) A software system for computer aided activities. Mamoru Hosaka, Takeshi Matsushita, Fumihiko Kimura and Naotake Kakishita. proc. IFIP WG5.2 working conference on CAD systems, Austin Texas Feb 1976
(80) British Integrated Program System for Highway Design Part II pp 7 - 62 and 7-63 Highways Engineering Computing Branch Department of the Environment St. Christopher House Southwark St. London
(81) Draft International Standard ISO/DIS 2539 Punched tape variable block format for contouring and contouring/positioning numerically controlled machines. British Standards Institute April 1972
(82) Draft International Standard ISO/DIS 3592 Numerical control of machines - NC processor output - Logical structure and major words. CLDATA Group of ISO TC97/SC9 Jan. 1976
(83) Multics General Graphics System pp 1-1 to 2-25 of unidentified, undated document.
| Paper | Gen. Cons. |
Hardware | Usage | Protocols | Language | Fortran | Othr |
|---|---|---|---|---|---|---|---|
| 1 | * | ||||||
| 2 | COLOR | ||||||
| 3 | Basic | ||||||
| 4 | NGP | ||||||
| 5 | DRAW | ||||||
| 6 | * | ||||||
| 7 | APL | ||||||
| 8 | * | ||||||
| 9 | GHOST | ||||||
| 10 | ARTIST | ||||||
| 11 | * | ||||||
| 12 | Glossary | ||||||
| 13 | MAPS | ||||||
| 14 | DIGS | ||||||
| 15 | * | ||||||
| 16 | * | ||||||
| 17 | * | ||||||
| 18 | * | ||||||
| 19 | PHILDIG | ||||||
| 20 | GMB | ||||||
| 21 | GMB | ||||||
| 22 | * | ||||||
| 23 | UGP | ||||||
| 24 | GRAFSY | ||||||
| 25 | UGP | ||||||
| 26 | * | ||||||
| 27 | * | ||||||
| 28 | IDATA | ||||||
| 29 | GINO-F | ||||||
| 30 | GINO-F | ||||||
| 31 | GINO-F | ||||||
| 32 | GPGS | ||||||
| 33 | SPROGS | ||||||
| 34 | PHILDIG | ||||||
| 35 | GPGS-F | ||||||
| 36 | GPGS | ||||||
| 37 | GPGS | ||||||
| 38 | Minutes | ||||||
| 39 | GRID | ||||||
| 40 | AUTOPROD | ||||||
| 41 | MIDI | ||||||
| 42 | OXSYS/BOS/T | ||||||
| 43 | * | ||||||
| 44 | MIDI | ||||||
| 45 | MIDI | ||||||
| 46 | GPGS | ||||||
| 47 | DC300 | ||||||
| 48 | * | ||||||
| 49 | * | ||||||
| 50 | AMESPLOT | ||||||
| 51 | * | ||||||
| 52 | * | ||||||
| 53 | KV | ||||||
| 54 | DISSPLA | ||||||
| 55 | GRAFPAC | ||||||
| 56 | L4 | APL-G | |||||
| 57 | * | * | |||||
| 58 | * | ||||||
| 59 | GPDL | ||||||
| 60 | G439 | ||||||
| 61 | HGPLOT | ||||||
| 62 | |||||||
| 63 | |||||||
| 64 | |||||||
| 65 | |||||||
| 66 | SPROGS | ||||||
| 67 | GROATS | ||||||
| 68 | POLYGRAPHICS | ||||||
| 69 | POLYGRAPHICS | ||||||
| 70 | |||||||
| 71 | PDL2 | ||||||
| 72 | MONSTER | ||||||
| 73 | ANOTHER | ||||||
| 74 | DIGRA | DIGRA | |||||
| 75 | LOGIGRAF | ||||||
| 76 | LOGIGRAF | ||||||
| 77 | * | ||||||
| 78 | * | ||||||
| 79 | * | APL | |||||
| 80 | BIPS | ||||||
| 81 | NCPT | ||||||
| 82 | CLDATA | ||||||
| 83 | MULTICS |
In his survey, M. Sabin makes divisions:
He should also include:
A quotation from Sabin's survey:
The overriding impression gained from reading all these documents is the extent of consensus already existing, particularly if one considers only subroutine packages.
From the approximately 10 different Fortran-subroutine packages that I have used I can't see very much of a consensus. Maybe M. Sabin has received only the best part of the existing packages. If that is true, his survey could perhaps serve as a document to read before implementing your own graphics package. Maybe that would prevent some people from writing new packages. One could ask : Why so many Fortran-subroutine packages for graphics? One answer could be : It is such a nice exercise to implement a graphics package. And when it is ready the implementor certainly expects people to use the package.
Malcom Sabin apologized for the size and lateness of his paper. Any such survey must be cursory, and he solicited corrections and additions from others. He pointed out that it was a very subjective survey, in many ways a position paper.
Malcolm summarized the topics in his paper, which divides actual systems into three types: languages, subroutine packages (which he calls "procedure libraries") and protocols. He added to the language-section by noting that text primitives were omitted by mistake, and by giving the following examples to distinguish explicit and implicit computation:
DRAWTO (X, Y) involves no explicit computation
DRAWTO (1+1+1, 2*2) involves explicit computation
If the object SQ1 defined as:
SQ1: .....
LB : .....
.....
.....
Then if we say TRANSFORM SQl into SQ2 and wish to refer to LB of SQ2, this will involve implicit computation. Another example is the computation of the endpoints of the line AB
Concerning the second type of system, protocols, Sabin asked how many implementations of the ARPA network graphics protocol had been completed, and expressed surprise at the answer of zero. He pointed out that there may be differences between the NGP and the communication between different parts of a graphics package, but the way we describe them is the same. Sabin feels strongly that protocols should be legible. His paper includes an example and a table of performance figures; Sabin also invented his own protocol that was legible and yet substantially better than those in the table.
Here Tom Sancha suggested that Sabin be more consistent about the use of the adjectives good and bad; Sabin said he would try, but probably fail.
Concerning subroutine packages, Sabin pointed out the difficulty of compiling the tables, since by adding one more function to a package we could fill any gap in the table. He asked if the binding time column was considered important. He explained the names column, where 1 and 2 mean one or two levels, T implies tree-structured.
Sabin finished by discussing the structure of packages. He distinguished three types:
Alan Shaw asked about feedback within the pipeline, which Sabin likened to recursion. Sancha said one could create output files and then feed them into the pipeline (this could create problems with Fortran). Van Dam pointed out a similar property of digital transformation hardware, which could generate transformed data for later use. Sabin indicated that he had no experience of these.
During the period for classification questions, Barbara Liskov suggested that Sabin should be careful to get his semantics right: it was bad to use implementation restrictions such as Fortran and its lack of recursion. Sancha followed this up. In Sanchas' words ; Sabin, in describing the pipeline, mixed up what he wished to do with how he wished to achieve it; for example, he wished to have some non commutative transformations (what) and he achieved them by passing data down a pipeline consisting of the application of a series of transformations (how).
Richard Guedj pointed out that layers are not tree structures. Level A could go direct to Layer C or through layer B to layer C.
Jim Foley pointed out that most two-level, front-end/back-end systems are layered at both ends; there is a single interface between, usually defined in terms of a pseudo picture code for some virtual display. The back end is often called a device driver.
On the looping question, van Dam reiterated that you may want to feed data back, and Sabin agreed that this is important if one wishes to perform special computation on them. Examples of these special computations would be useful.
Guedj asked what Sabin would not include in his transformations : Sabin replied: Topological transforms i.e. transformations that preserve the picture's topology but not its geometry.
Shaw disagreed with his four language categories, saying one could use the last (new graphics languages) to write any of the others. During his talk, Kjelldahl commented on Sabin's statement that a consensus existed: he wondered what this consensus was? Sabin said there were many things one took for granted, such as Current beam position, and these formed an unwritten consensus. When Kjelldahl pointed out that packages might differ in ease of use, Sabin countered that every system designer claims that his system is easy to use.