This text comes from The IETF website which is an interesting place.
Blockquote test. Backslash at the end of a line for line break.
This note states some of our initial reactions to NWG/RFC #86, whose purpose was to provide a basis for discussion and development of Network graphics.
This is a nested blockquote.
This note states some of our initial reactions to NWG/RFC #86, whose purpose was to provide a basis for discussion and development of Network graphics 1.
The method of operation described in Note 86 was to interpret data structures to produce graphic order codes for display. This method has proven satisfactory in the past and we favor this approach. The Note 86 proposal is directed toward a particular concept of operation (i.e., minimal graphics terminal connected to computational facilities at remote sites); our remarks embrace extended operations that include smart programs at each end of the connection as well as the minimal terminal.
The proposal in Note 86 should be broadened to include the description of more complex entities and it should be raised to a level of describing more general things. In this note, we first criticize the limitations imposed by the details of Note 86; then suggest some supplementary ingredients to extend its scope; and lastly, we suggest an alternate approach that reduces Network conversations (where possible) to symbol manipulation rather than gross detail.
Comments on the Detailed Restrictions of Note 86
The detailed constraints enumerated in Note 86 restrict many interesting features of the Rand display hardware that we consider necessary (from a human factors standpoint) to some current applications. They likewise restrict other nodes whose ARPA- sponsored research is dependent upon the use of sophisticated hardware. For example, the point, vector, and character capability of Note 86 excludes line type mode, intensity control, and many other attractive control operations; the maximum symbol sizes are too small for our large character size; the origin of all of our symbols is specified as the “centroid” of the symbol rather than the lower left corner of a virtual rectangle encompassing the symbol; under mode control for plotting purposes, the beam may not be advanced to the next character position; a 7-bit ASCII is insufficient; etc. 2 In short, the five list items of Note 86 are not expressive enough; for example, there is nothing to allow one to position and open a graphic compare “window”. The problem was not treated of supplying parameters identifying structure for match, etc. that are not actual display commands.
Perhaps some necessary information gathering (i.e., the display hardware descriptions and the characteristics of every node) is preliminary to the generation of a detailed specification. It is important that, without delay, a mechanism be defined for gathering and collating this information in such a way that it doesn’t deter progress on Network graphics development.
Some General Extensions to the Note 86 Proposal
DISPLAY LANGUAGE CAPABILITIES SHOULD ENCOMPASS THE UNION OF CURRENT AND ANTICIPATED NETWORK GRAPHICS HARDWARE. Our experience in exploring interactive graphics communication techniques for use by researchers and non-programmers indicates that this is not just a “motherhood”. The utility of such applications programs depends highly upon incorporating sophisticated graphics hardware. In absence of those features, some programs simply won’t be used.
THE DATA STRUCTURE SHOULD ALLOW LOGICAL AS WELL AS PICTORIAL REPRESENTATION OF THE USER’S PROBLEM. This close coupling of the meaning of a picture with the actual picture is desirable from a processing program’s point of view, especially if a user is to interact with the picture. We have found this an efficient way to operate with the GRAIL Project and its derivatives here at Rand. This technique is included in a recently proposed graphics language generated by Bob Anderson (Rand) and Ben Wegbreit (Harvard).
TRANSMIT DEFINITIONS OF GRAPHICS AND THEN INSTANCES OF THEIR USE. The attempt here is to raise the level of “conversation” between programs (where possible) and to reduce processing overhead. For example, if one wishes to draw lots of resistors, why not graphically define a resistor once and then transmit instances by giving the definition name accompanied by attributes? A typical form of an instance is shown below.
Item Name (position, size, intensity, scaling, labeling, rotation, etc.)
There are many examples of this approach such as the recent work by William Newman (Utah) and many earlier studies at MIT.
he detailed constraints enumerated in Note 86 restrict many interesting features of the Rand display hardware that we consider necessary (from a human factors standpoint) to some current applications. They likewise restrict other nodes whose ARPA- sponsored research is dependent upon the use of sophisticated hardware. For example, the point, vector, and character capability of Note 86 excludes line type mode, intensity control, and many other attractive control operations; the maximum symbol sizes are too small for our large character size; the origin of all of our symbols is specified as the “centroid” of the symbol rather than the lower left corner of a virtual rectangle encompassing the symbol; under mode control for plotting purposes, the beam may not be advanced to the next character position; a 7-bit ASCII is insufficient; etc. In short, the five list items of Note 86 are not expressive enough; for example, there is nothing to allow one to position and open a graphic compare “window”. The problem was not treated of supplying parameters identifying structure for match, etc. that are not actual display commands.
Perhaps some necessary information gathering (i.e., the display hardware descriptions and the characteristics of every node) is preliminary to the generation of a detailed specification. It is important that, without delay, a mechanism be defined for gathering and collating this information in such a way that it doesn’t deter progress on Network graphics development.
