diff options
Diffstat (limited to 'doc/rfc/rfc292.txt')
| -rw-r--r-- | doc/rfc/rfc292.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc292.txt b/doc/rfc/rfc292.txt new file mode 100644 index 0000000..8b04f69 --- /dev/null +++ b/doc/rfc/rfc292.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group 12 January 1972 +Request for Comment: 292 Jim Michener, MAC +NIC 8302 Ira Cotton, MITRE +References: 282, 285 Karl Kelley, U. of Ill. +Updates: None Dave Liddle, Owens Ill. +Obsoletes: None Ed Meyer, MAC + + + GRAPHICS PROTOCOL - LEVEL 0 ONLY + +INTRODUCTION + + This document reflects opinions expressed and decisions reached at + the second meeting of the Network Graphics Group, held at the + Stanford Artificial Intelligence Laboratory in late November 1971. + It describes part of a proposed Network Standard Graphics Protocol + for transmitting graphics data within the ARPA network. The + particular aspects of the protocol covered in this document relate to + the form and content of graphics information sent from a source of + graphical information (an application program, say, in the "Serving + Host") to a display package for output to a graphics console (at the + "Using Host"). This will take the form of a sequence of 8-bit bytes, + and will be called the graphics output byte stream. In particular, + only the simplest forms of graphics data will be covered in this, the + first version of this document. The next version, already in + preparation, will be much more complete. In any case this is not + intended to describe a finished protocol; rather it should serve as a + basis for graphics experimentation on the network. + + This document does not include form or content of graphics input + (data sent from the Using Host to the Serving Host) nor does it cover + how the connection is established between the hosts. A proposal for + the former will be generated eventually by this committee; the latter + is the job of the Connection Committee (of the Network Graphics + Group). + + This RFC describes the commands which are available in the protocol + in terms of the effect they would have at the receiving (Using Host) + end. Clearly, some subroutine package is desirable at the Serving + Host for use by applications package in transmitting graphics data, + but on this topic this RFC does not intend to comment. + + It may be observed by the reader that no facility is specified in + this protocol allowing the Using Host to report logical errors in the + graphics output byte stream to the Serving Host. Such a facility + would have to be intergrated with the graphics _input_ byte stream, + since it involves most of the problems related to synchrony of + independent hosts. + + + +Michener [Page 1] + +RFC 292 Graphics Protocol Level 0 January 1972 + + +BACKGROUND + + The reader should probably peruse RFC 282: "Graphics Meeting Report" + by Mike Padlipsky to obtain some of the framework surrounding this + discussion of network graphics. Also it might be valuable to make + note of the model described in RFC 285: "Network Graphics" by Donald + Huff. + +LEVEL AND GROUND RULES PERTAINING THERETO + + Functions within the graphics protocol will be classified into a + number of levels depending partly on how difficult it is to implement + those functions. It is intended that any host which claims to + implement the functions of level N must implement all lower levels as + well. Thus, it is envisioned that sites will implement levels + incremently. Implementations will be improved as a continuing + process to include more and more functions, and it is intended that + each implementation will be able to identify its own level to a + graphics protocol at a remote site which is requesting a graphics + interchange. A side result is that each site will be able to + determine its own priorities in committing programmers to the + graphics protocol as opposed to other efforts. + + It is also our intention that implementation of level N will require + no knowledge of level N+1. Thus a site can implement a level in the + (reasonably) firm knowledge that no changes at higher levels will + alter the level implemented. At some time it may be decided by the + Network Graphics Group to redefine a level which has previously been + firmed up. It is not our intention that this shall happen but one + must recognize that the proposed Graphics Protocol is experimental + and may have to be changed. + + One further ground rule: a stream of commands and data which is + valid at a given level, K, shall produce "identical" results on any + interpreter of level K or higher. By this we mean that as defined + operations, similar pictures should result. Aspects of the protocol + which are not strictly defined (at this time) include character size, + character position relative to the beam, how control characters in + text output affect the terminal and what happens when the beam is + moved or a line drawn outside of the logical screen boundary. This + rule forces upwards compatibility, so that an application written + using features of low numbered level will still work at sites which + have moved on to implement higher levels. Additionally, any aspects + of this protocol which are explicitly "left unspecified" in the + detailed operations descriptions below _shall_ be explicitly + specified in any public description of an actual implementation. + + We now describe the framework which will be common to all levels. + + + +Michener [Page 2] + +RFC 292 Graphics Protocol Level 0 January 1972 + + +BASIC DATA FORMS + + Information in the Network Standard Graphics Protocol will be + expressed as a sequence of 8-bit bytes. A command will consist of a + command byte followed by zero or more arguments. The same command + byte will always take the same number of arguments in the same form. + The length of each argument may be fixed or variable depending on the + argument. + + A simple type of argument is a "value," which is an 8-bit integer. + Another type of argument is a "string" which is a count followed by + (count)number of 8-bit bytes. If the count is between 0 and 127, it + is sent in a single byte. If the count is between 128 and 2**15-1 + (** means exponentiation), it is sent in two bytes with the high + order bit of the first byte set to one. The first byte contains the + seven high order bits of the number, and the second byte contains the + eight low order bits. A string is the only type of argument of a + command which can vary in length. + + Coordinate data engendered considerable discussion at the second + Network Graphics Group meeting. It was decided that a two- + dimensional Logical Coordinate System was required, and each + interpreter for the graphic command byte stream would be responsible + for mapping this coordinate system to physical device coordinates. + It was decided that data in the logical coordinate system would be in + twos-complement notation, that it would be fractional, that each edge + of the screen would have unit length, and that the origin would + correspond to the center of the screen on the output device. The + vertical (horizontal) edges of the screen of the output device + correspond to the lines X (Y) = -1/2 or X=+1/2-e where e is a small + positive number determined by the precision of the fractional data. + Particularly the points (-1/2,-1/2) (-1/2,1/2-e), (1/2-e, -1/2) and + (1/2-e, 1/2-e) shall be visible points at the corners of the logical + screen. (In the case of a non-square display surface, the + implementer may make his own decision, but it is recommended that the + largest possible _square_ area be utilized.) Thus we shall say that + the Logical Coordinate System contains points whose coordinates range + from -1/2 to a little less than +1/2. + + Commands which take coordinate data will be available in various + modes. In absolute mode, a position is specified by giving its + coordinates in the Logical Coordinate System. In relative mode, the + _difference_ between the coordinates of the position and the + coordinates of the current position must be specified. Thus a + + + + + + + +Michener [Page 3] + +RFC 292 Graphics Protocol Level 0 January 1972 + + + coordinate datum which is an argument for an absolute mode operation + should be in the range -1/2 to +1/2-e, while one for a relative mode + operation should be in the range -1+e to +1-e. + + Interest was expressed at the second Graphics Group Meeting in + eventually allowing a very large coordinate space (many bits of + precision in each fractional coordinate). This is to be done by + permitting the length, in 8-bit bytes, of each coordinate datum to be + set (as a mode). It was decided at the meeting that two bytes per + coordinate would suffice for now. Thus "e" in the above discussion + is 2**(15) (one in the least significant bit of a 15-bit plus sign + fractional coordinate). + + Text data will be transmitted as an argument of various commands for + display on the output device. Network ASCII will be used to + represent characters. At the lowest-levels of the protocol only one + character size will be available -- whatever is "normal" on the + display device. If the device had no "normal" size, 72 characters + per line would be desirable. Later, variable character size may be + introduced. + + Also, at the lowest levels, control characters will be passed along + to the device for it to do the best it can. However, the consensus + of the graphics meeting was that at some reasonably low (but non- + zero) level carriage return, line feed, and backspace should be + interpreted to do the right thing. + +COMMAND CODES + + Each command in the graphics protocol will be assigned a non-negative + value which will represent this command in the byte stream. The + algorithm whereby values and commands are associated is, it turns + out, a very touchy subject. There are five or ten different criteria + for a "best" algorithm, each criterion different in emphasis. This + Gordian knot will be cut, in this proposal, by ordering the commands + approximately according to level, and then just numbering them. In + addition, if several closely related commands occur at the same + level, some attempt will be made to encode variations of meanings in + terms of bit configurations. Even if some later consideration causes + a change in ordering to be proposed, it is this committee's feeling + that the numbering should not be altered. However, until this matter + is firmly settled, it is strongly advised that any implementation + take into account the possibility of reassignment of command codes. + + + + + + + + +Michener [Page 4] + +RFC 292 Graphics Protocol Level 0 January 1972 + + +PARTICULAR PROPOSAL FOR LEVEL 0 PROTOCOL + + It is proposed that level 0 be kept very simple. This is so that + implementation can be quickly accomplished and experimentation with + the protocol begun. Another reason is that the least powerful hosts + and even programmable terminals should be able to implement it. In + accordance with this, the "rule" was made that a command be + implemented only if the output is a function solely of the current + command and the "beam position" current at the start of the command. + In other words the interpreter for level 0 need have no internal + storage for "modes" or pushdown stacks. With this restriction it is + hoped that a very simple implementation will be possible for level 0. + In particular, perhaps one could eventually build a hardware + translator from level 0 code to one's own particular terminal's code. + + Note that in the opcode assignment for level 0, bits 4, 2, and 1 have + special meaning for the move, line and dot commands. In particular, + the 1 bit encodes absolute versus relative data mode, the 4 bit + encodes whether any visible output occurs, and the 2 bit determines + whether the visible output is a line or a dot. + +LEVEL 0: COMMAND SUMMARY + + The following is a list of commands (and their syntax)in level zero. + Detailed descriptions of these commands follow in the next section. + Commands dealing with protocol may be added by the Connection + Committee. (They currently request opcodes in the range 128 to 255.) + + (As described in Basic Data Forms, above, <x>, <y>, <x delta> and <y + delta> are two-byte coordinate values, <string> is a count followed + by (count) many bytes and <value> is an eight bit number.) + + Decimal Octal Binary Format + + 0 0 00000000 Null + 1 1 00000001 Erase screen and reset beam + 2 2 00000010 Move Absolute <x> <y> + 3 3 00000011 Move Relative <x> <y> + 4 4 00000100 Draw Absolute <x> <y> + 5 5 00000101 Draw Relative <x delta> <y delta> + 6 8 00000110 Dot Absolute <x> <y> + 7 7 00000111 Dot Relative <x delta> <y delta> + 8 10 00001000 Text <string> + 9 11 00001001 TextR <string> + 10 12 00001010 End of Picture + 11 13 00001011 Escape <value> <string> + + + + + +Michener [Page 5] + +RFC 292 Graphics Protocol Level 0 January 1972 + + +LEVEL 0: COMMAND DESCRIPTIONS + + 0 Null Statement ("null") + This statement has no arguments and no effect, either. + + 1 Erase screen and reset beam to origin ("Erase"). + This command indicates that a new picture is about to be drawn. + It should always be (eventually) paired with a following End of + Picture command. + + 2 Move beam invisibly to absolute position + ("Move Absolute") <x coordinate> <y coordinate>. + Nothing is drawn; the beam is positioned to the specified absolute + x,y position. + + 3 Move beam invisibly by relative amount + ("Move Relative") <x delta> <y delta>. + Nothing is drawn; the beam is shifted by the specified amount in x + and y. + + 4 Draw line to absolute position + ("Draw Absolute") <x coordinate> <y coordinate>. + A line is drawn from the current beam position to the specified + absolute x, y position. + + 5 Draw line to relative position + ("Draw Relative") <x delta> <y delta>. + A line is drawn from the current beam position to the position + delta x and delta y away. + + 6 Display a Dot at absolute position + ("Dot Absolute") <x coordinate> <y coordinate>. + The beam is moved invisibly to absolute position x, y and a dot is + displayed there. + + 7 Display a Dot at Relative position + ("Dot Relative") <x delta> <y delta>. + The beam is moved invisibly by the specified amount in x and y and + a dot is displayed there. + + 8 Display text ("Text") <string>. + At the current beam position, display some characters at the + normal size for the device being operated. <string> consists of a + <count> followed by count many characters. If there is no "normal + size," choose the size so that seventy-two characters are + displayed per line. The characters in the string are coded in + network ASCII: all codes between 0 and 127 (decimal) inclusive are + permitted. (At level zero, what happens to control characters is + + + +Michener [Page 6] + +RFC 292 Graphics Protocol Level 0 January 1972 + + + left unspecified.) Where the beam is, following execution of this + command, is left unspecified, except that another Display Text + command immediately following will append its text to the previous + string. (The use of the TEXT command is _discouraged_; use TextR + instead.) The position of the first character relative to the + initial beam position is left unspecified. + + 9 Display text and restore beam ("TextR") <string>. + At the current beam position, display a string of characters at + the normal size for the device being operated then reposition the + beam to where it was before the command. <string> consists of a + <count> followed by count many characters. If there is no "normal + size," choose the size so that seventy-two characters are + displayed per line. The characters in the string are coded in + network ASCII; all codes between 0 and 127 (decimal) inclusive are + permitted. (At level zero, what happens to control characters is + left unspecified.) The position of the first character relative + to the initial beam position is left unspecified. + + 10 End of Picture ("Endpic"). + This command denotes the end of a new picture. It must be paired + with a preceding Erase command. + + 11 Escape to device specifics ("Escdev") <value> <string>. + If "value" is the code assigned (by the Protocol Committee) to the + device being operated, then transmit the eight-bit bytes in + <string> (which starts with a <count> indicating the number of + bytes) to the device without examining them. Otherwise ignore + this command. If the device does not accept 8-bit information, + reformat the data in some device specific way; an example would be + throwing away the high order bit for a seven bit device, or + gathering 5 8-bit bytes into one 36-bit word, again discarding the + high order bits, perhaps. The action of the bytes in the string + should leave alone (or at least restore) any hardware beam + position registers in the device which the interpreter might + conceivably depend on. + + This command really should not be used; it was included at level 0 + so that specific applications can do mode setting and other device + specific manipulations. For example ARDS terminals may optionally + have several, independently addressable output scopes. The + selection mechanism changes state only when a particular sequence + of ASCII characters reaches the terminal. Thus ESCDEV would be + used to select which scopes(s) is/are to be affected by following + commands. (The current state is invisible to the graphics package + at the Using Host.) + + Further, suppose that another make of terminal has a similar + + + +Michener [Page 7] + +RFC 292 Graphics Protocol Level 0 January 1972 + + + option, which responds to a different code sequence. This + possibility is the motivation for conditionally ignoring the + ESCDEV command based on the "<value>" specified. Given that a + particular application will only be used to output to either an + ARDS or this second make (with the multiple scope option), then + the application could always send two ESCDEV commands, one + applicable only to ARDS terminals, and the other applicable only + to the second make. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Michener [Page 8] + +RFC 292 Graphics Protocol Level 0 January 1972 + + + APPENDIX 1: BNF FOR THE GRAPHICS PROTOCOL BYTE STREAM + + Key to below: + Non-terminals are represented in <>. + Terminals which are keywords standing for particular eight-bit values + are in capitals. + Terminals whose meaning should be clear to the reader are in lower + case. Note that "empty_string" means "zero bytes," and not "a + <string> whose <count> is zero". + + <graphics output byte stream> ::= empty_string + | <picture> <graphics output byte stream> + <picture> ::= <new picture stt> <sttgroup> <end stt> + <stt group> ::= empty_string | <stt> <stt group>. + <stt> ::= <control stt> | <display stt> + <control stt> ::= <escape to device stt> + | <null stt> + <display stt> ::= <move absolute stt> + | <move relative stt> + | <draw absolute stt> + | <draw relative stt> + | <dot absolute stt> + | <dot relative stt> + | <text and restore beam stt> + | <text stt> + + <new picture stt> ::= ERASE + <escape to device stt> ::=ESCDEV <device code> <string> + <null stt>::= NULL + <end stt>::= ENDPIC + <move absolute stt> ::= MOVEA <x coordinate> <y coordinate> + <move relative stt> ::= MOVER <x delta> <y delta> + <draw absolute stt> ::= DRAWA <x coordinate> <y coordinate> + <draw relative stt> ::= DRAWR <x delta> <y delta> + <dot absolute stt> ::= DOTA <x coordinate> <y coordinate> + <dot relative stt> ::= DOTR<x delta> <y delta> + <text and restore beam stt> ::= TEXTR <string> + <text stt> ::= TEXT <string> + <x coordinate> ::= <coordinate> + <y coordinate> ::= <coordinate> + <x delta> ::= <double coordinate> + <y delta> ::= <double coordinate> + <coordinate> ::= singed,_two's-complement,_fraction_in_range + -1/2_to_less_than_+1/2 + <double coordinate> ::= signed,_two's_complement,_fraction, + range_strictly_between_-1_and_+1 + + + + + +Michener [Page 9] + +RFC 292 Graphics Protocol Level 0 January 1972 + + + <count ::= 7-bit_non-negative_integer + | 15-bit_non-negative_integer_represented_in + "excess_2**15"_notation + <string> ::= <count> count_8-bit_bytes + <device code> ::= <value> + <value> ::= 8-bit_integer + + + + + + + + + + + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Kelly Tardif, Viagénie 10/99] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Michener [Page 10] + |