Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream
RFC 125

Document Type RFC - Unknown (April 1971; No errata)
Updated by RFC 177
Updates RFC 86
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 125 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
NETWORK WORKING GROUP

                        REQUEST FOR COMMENT: 125

                                NIC 5841

                             APRIL 18, 1971

                             JOHN McCONNELL

                          AMES RESEARCH CENTER
                       MOFFETT FIELD, CALIFORNIA

Response to RFC #86, Proposal for Network Standard Format for a graphics
data stream.

Category         D.6
RFCs obsoleted   None
RFCs updated     86

                                                                [Page 1]
The basic approach of transmitting an intermediate, device independent
language which is translated into specific device codes at the
receiving host is sound. It appears to be the only approach that will
allow thought to be centered on picture descriptions. Ames Research
Center has adopted this approach in tying its graphic facilities, of
various types, and on various computers together. At present, we are
in the design phase and expect our package to be running in about six
months. The main objections to the structure as it now exists, is that
it takes no cognizance of the many features available on graphics
devices. Since these features will always be changing with new
devices, a set of option or mode primitives should be defined which
are logically separate from the drawing primitives provided in RFC 86.
The mode primitives will act upon the drawing primitives to modify
their actions. The scope of a mode primitive extends until a new mode
primitive resets an option. The use of mode primitives will allow the
network standard stream interpreter to treat them as null operations
if the features are missing at a particular host, or to perform more
detailed interpretation of the following data stream to achieve
results. The drawing primitives may also then keep a standard format
which need not be changed to incorporate new features.

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
suffice.

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

                                                                [Page 2]
defining them should be provided within the argument string itself,
again Multics has allowed the specification of arbitrary characters by
entering their octal equivalents. The convention should use a control
character code followed by a l6-bit list name which specifies the
sub-list defining the character. The other alternative is to allow
8-bit characters and allow the interpreter to choose a sub-list if the
character is not realizable with a hardware generator.

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
restored.

An include list primitive would allow the treatment of a sub-list to
Show full document text