by Darius Kazemi, March 27 2019
A simple drawing format
RFC-86 is titled “Proposal for a Network Standard Format for a Data Stream to Control Graphics Display”. It's authored by Steve Crocker and dated January 5th, 1971. (We're in 1971 now, btw!)
The technical content
This document is one result of Crocker's comment at the November 1970 FJCC conference meeting where according to Meyer's notes, Crocker said:
What about graphics proposals? I will write my own paper as a proposal. It uses the DEC 340 as a model. Modes assumes scope system a memory. Both output-input are included in standards making. I want a competent protocol to be developed out of the working group.
In this RFC, Crocker is proposing a format for the data that is sent from a remote graphical computer system to a local user. It's for sending vector drawing data over the network.
He immediately defines five acronyms:
- network standard graphics data stream (NGDS)
- network standard display list (NGDL)
- network standard stream interpreter (NGSI)
- network standard list interpreter (NGLI)
- network standard screen (NGS)
The screen itself is assumed to be square. A point on the screen is an “order pair of unsigned 16 bit fractions”. These fractions represent a proportional distance from the left hand edge and from the bottom edge. No resolution is specified, so this is a normalized unit square of length 1.0 on each side, set up like a familiar Cartesian plane from math class with the origin at the lower left and (X,Y) pairs increasing as you go up and to the right. (This different from modern displays where the origin is usually at the top left and the Y value increases as you go down from the top.)
The NGLI (aka display controller) can move the drawing beam for the CRT to a new location, increase intensity of the beam, draw a vector, or draw a character. “Drawing a character” is defined as drawing a single ASCII character and then positioning the beam directly to the right of it.
The NGDL is the actual set of lists containing instructions for the NGLI. So a “program” would be a list of commands, and the possible commands are:
- Move beam to X,Y
- Draw a line from current beam position to X,Y
- Display a point at beam position
- Display the following n characters: [list of ASCII characters]
- Execute list G relative to position X,Y and make the new “origin” the new X,Y
That last one is really important because it means you could provide a list of commands that draw a picture, and then replicate that picture in another area of the screen without having to provide the same program twice! It's the same thing as doing a 2D translation of a canvas context.
The way the data is sent over the network is that lists of these commands, formatted as simple opcodes, are sent over the network. There is also an “erase” command that erases all lists.
Crocker lists out all the piece of the protocol and then starts from the most concrete part (the screen) working his way up to the more abstract arena of the data stream itself. This is in my opinion a smart way to get this kind of thing across to people. If you start with the tangible, you're front loading the “why this is important” bit, which keeps the reader “on your side” and interested.
The square screen makes sense because it simplifies a bunch of math.
Unsigned 16 bit fractions are interesting to me. The IEEE 754 standard for floating point arithmetic was published in 1985, so we are operating a decade and half before this standard that most people take for granted.
I want to draw attention to the character rendering system, which assumes a left-to-right writing system. This system would not be very helpful for displaying a right-to-left or top-to-bottom language. ASCII doesn't support those languages anyway so it's a moot point.
This proposal seems simple and useful for all kinds of drawing. I would approve heartily were I reading this RFC in 1971.