NETWORK WORKING GROUP
REQUEST FOR COMMENT: 125
APRIL 18, 1971
AMES RESEARCH CENTER
MOFFETT FIELD, CALIFORNIA
Response to RFC #86, Proposal for Network Standard Format for a graphics
RFCs obsoleted None
RFCs updated 86
Overall modes which primitives could control would be intensity
levels, or color selections for objects, in addition blinking of
objects should be provided. For vectors, the additional facility for
drawing dashed lines is necessary.
Character strings require another set of specification. The convention
for the beam is usually that it is in the center of the rectangular
area defining a character's boundaries. The beam position is usually
undefined at the finish of drawing a character string. A strong
exception is taken to the exclusion of form control characters from
strings. If included in the character string, they could provide for
shifting from upper to lower case, subscripting, superscripting, and
underscoring, as well as tab and other "carriage" motion functions.
The appropriate characters could be extracted at interpretation time
to provide the necessary information to display more complex strings.
To allow the facility for generating ALGOL-like delimiters, such as
"then", a convention for canonical character string should be adopted.
I believe the Multics conventions described in reference 1 will
Additional options for character strings should include a size
specification and an orientation selection. As many devices, have
hardware character generators that are fixed, some of these options
may not be desirable to implement as subroutines.
Another area that should be looked at further is the additional
symbols available which are not specified in ASCII. Some means of
The special form control characters to be used are:
a. BS - backspace
b. LF - for new line
c. SO/Sl - shift case
d. DC2 - superscript following characters
e. DC4 - subscript following characters
f. DC3 - special non-ASCII character follows
g. Tab - position to next tab. May be predefined or specified.
Another construct should be added to those proposed in RFC 86. This is
the display list pointer (NGDLP). It will have as a value the next
drawing primitive to be executed. The value is a displacement from the
head of a list. With no mode setting primitives, this value is one to
one with the drawing primitives transmitted in the NGDS. The NGDLP is
needed for consistency for execution of the nested list structure.
Whenever an execute list primitive is encountered, the current value
of the NGDLP is saved along with the list name and current origin
value. When execution of a list is finished, the last values saved are
An include list primitive would allow the treatment of a sub-list to
be equivalent to a macro instead of a subroutine. This would be
necessary to avoid changes to all sub-pictures on the screen due to
the manipulation of a sub-list. The include primitive should have as
parameters such specifications as size, intensity, orientation,
blinking, etc. After a sub-list has been included in another list, it
is no longer distinguished as a separate entity.
To cut down on the volume of data being transferred, other commands to
be parsed by the stream interpreter should be added. These would allow
the manipulation of a list by the receiving host without a
retransmission. The types of manipulations would include rescaling
the coordinates for shrinking or zooming, translation of the origin,
or rotation. Other manipulations to provide for displaying or not
displaying a list, or enabling of disabling light pen detections would
The problem of interaction with the displayed picture has yet to be
addressed, so this will be an attempt to elicit some more discussion
To allow the transmitting host to identify the object pointed at, the
stack of suspended lists and the current value of the NGDLP will
qualify the object to any level in a hierarchical structure. In
addition, normalized x,y coordinates should be returned, as well as a
character displacement if a string was pointed at. This structure will
serve a light pen device very well since the light pen mechanism
allows the determination of the currently executing primitive. Other
devices interact with the picture in an asynchronous fashion and the
association of an x,y pair to a structure is a more difficult problem.
This may require that the host generating the graphic data stream be
responsible for making that association. A further complication arises
when it is desired to use a light pen in an area where no beam motion
occurs, then some directive to periodically sweep the screen and
"find" the pen must be provided. This might be a sub-list which is
executed periodically for this function.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Jerry Tenenbaum 4/97 ]
Reference: Osanna, J., Sahzer, J.
Remote Terminal Character Stream Processing of Multics
Proceedings SJCC, 1970, p. 671