rfc746.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 885 行 · 第 1/3 页

NWG/RFC# 746                                         RMS 17-MAR-78 43976
The SUPDUP Graphics Extension



Network Working Group                                   Richard Stallman
Request for Comments 746                                          MIT-AI
NIC 43976                                                  17 March 1978

The SUPDUP Graphics Extension

   ... extends SUPDUP to permit the display of drawings on the screen of
   the terminal, as well as text.  We refer constantly to the
   documentation of the SUPDUP protocol, described by Crispin in RFC 734
   "SUPDUP Protocol".

   Since this extension has never been implemented, it presumably has
   some problems.  It is being published to ask for suggestions, and to
   encourage someone to try to bring it up.

The major accomplishments are these:

   *    It is easy to do simple things.

   *    Any program on the server host can at any time begin outputting
        pictures.  No special preparations are needed.

   *    No additional network connections are needed.  Graphics commands
        go through the normal text output connection.

   *    It has nothing really to do with the network.  It is suitable
        for use with locally connected intelligent display terminals in
        a terminal-independent manner, by programs which need not know
        whether they are being used locally or remotely.  It can be used
        as the universal means of expression of graphics output, for
        whatever destination.  Programs can be written to use it for
        non-network terminals, with little loss of convenience, and
        automatically be usable over the ARPA network.

   *    Loss of output (due, perhaps, to a "silence" command typed by
        the user) does not leave the user host confused.

   *    The terminal does not need to be able to remember the internal
        "semantic" structure of the picture being displayed, but just
        the lines and points, or even just bits in a bit matrix.

   *    The server host need not be able to invoke arbitrary
        terminal-dependent software to convert a standard language into
        one that a terminal can use.  Instead, a standard language is
        defined which all programmable terminals can interpret easily.
        Major differences between terminals are catered to by
        conventions for including enough redundant information in the
        output stream that all types of terminals will have the
        necessary information available when it is needed, even if they



                                  -1-

NWG/RFC# 746                                         RMS 17-MAR-78 43976
The SUPDUP Graphics Extension



        are not able to remember it in usable form from one command to
        another.

Those interested in network graphics should read about the Multics
Graphics System, whose fundamental purpose is the same, but whose
particular assumptions are very different (although it did inspire a few
of the features of this proposal).













































                                  -2-

NWG/RFC# 746                                         RMS 17-MAR-78 43976
The SUPDUP Graphics Extension



SUPDUP Initial Negotiation:

   One new optional variable, the SMARTS variable, is defined.  It
   should follow the other variables sent by the SUPDUP user process to
   the SUPDUP server process.  Bits and fields in the left half-word of
   this variable are given names starting with "%TQ".  Bits and fields
   in the right half are given names starting with "%TR".  Not all of
   the SMARTS variable has to do with the graphics protocol, but most of
   it does.  The %TQGRF bit should be 1 if the terminal supports
   graphics output at all.

Invoking the Graphics Protocol:

   Graphics mode is entered by a %TDGRF (octal 231) code in the output
   stream.  Following characters in the range 0 - 177 are interpreted
   according to the graphics protocol.  Any character 200 or larger (a
   %TD code) leaves graphics mode, and then has its normal
   interpretation.  Thus, if the server forgets that the terminal in
   graphics mode, the terminal will not long remain confused.

   Once in graphics mode, the output stream should contain a sequence of
   graphics protocol commands, each followed by its arguments.  A zero
   as a command is a no-op.  To leave graphics mode deliberately, it is
   best to use a %TDNOP.




























                                  -3-

NWG/RFC# 746                                         RMS 17-MAR-78 43976
The SUPDUP Graphics Extension



Co-ordinates:

   Graphics mode uses a cursor position which is remembered from one
   graphics command to the next while in graphics mode.  The graphics
   mode cursor is not the same one used by normal type-out:  Graphics
   protocol commands have no effect on the normal type-out cursor, and
   normal type-out has no effect on the graphics mode cursor.  In
   addition, the graphics cursor's position is measured in dots rather
   than in characters.  The relationship between the two units (dots,
   and characters) is recorded by the %TQHGT and %TQWID fields of the
   SMARTS variable of the terminal, which contain the height and width
   in dots of the box occupied by a character.  The size of the screen
   in either dimension is assumed to be the length of a character box
   times the number of characters in that direction on the screen.  If
   the screen is actually bigger than that, the excess is may or may not
   be part of the visible area; the program will not know that it
   exists, in any case.

   Each co-ordinate of the cursor position is a 14-bit signed number,
   where zero is at the center of the screen (if the screen dimension is
   an even number of dots, then the visible negative points extend one
   unit farther that the positive ones, in proper two's complement
   fashion).  Excessively large values of the co-ordinates will be off
   the screen, but are still meaningful.

   An alternate mode is defined, which some terminals may support, in
   which virtual co-ordinates are used.  The specified co-ordinates are
   still 14-bit signed numbers, but instead of being in units of
   physical dots on the terminal, it is assumed that +4000 octal is the
   top of the screen or the right edge, while -4000 octal is the bottom
   of the screen or the left edge.  The terminal is responsible for
   scaling these virtual co-ordinates into units of screen dots.  Not
   all terminals need have this capability; the %TQVIR bit in the SMARTS
   variable indicates that it exists.  To use virtual co-ordinates, the
   server should send a %GOVIR; to use physical co-ordinates again, it
   should send a %GOPHY.  These should be repeated at intervals, such as
   when graphics mode is entered, even though the terminal must attempt
   to remember the state of the switch anyway.  This repetition is so
   that a loss of some output will not cause unbounded confusion.

   The virtual co-ordinates are based on a square.  If the visible area
   on the terminal is not a square, then the standard virtual range
   should correspond to a square around the center of the screen, and
   the rest of the visible area should correspond to virtual
   co-ordinates just beyond the normally visible range.

   Graphics protocol commands take two types of cursor position
   arguments, absolute ones and relative ones.  Commands that take
   address arguments generally have two forms, one for each type of



                                  -4-

NWG/RFC# 746                                         RMS 17-MAR-78 43976
The SUPDUP Graphics Extension



   address.  A relative address consists of two offsets, delta-X and
   delta-Y, from the old cursor position.  Each offset is a 7-bit two's
   complement number occupying one character.  An absolute address
   consists of two co-ordinates, each 14 bits long, occupying two
   characters, each of which conveys 7 bits.  The X co-ordinate or
   offset precedes the Y.  Both types of address set the running cursor
   position which will be used by the next address, if it is relative.
   It is perfectly legitimate for parts of objects to go off the screen.
   What happens to them is not terribly important, as long as it is not
   disastrous, does not interfere with the reckoning of the cursor
   position, and does not cause later objects, drawn after the cursor
   moves back onto the screen, to be misdrawn.

   Whether a particular spot on the screen is specified with an absolute
   or a relative address is of no consequence.  The sequence in which
   they are drawn is of no consequence.  Each object is independent of
   all others, and exists at the place which was specified, in one way
   or other, by the command that created it.  Relative addresses are
   provided for the sake of data compression.  They are not an attempt
   to spare programs the need for the meagre intelligence required to
   convert between absolute and relative addresses; more intelligence
   than that will surely be required for other aspects of the graphics
   protocol.  Nor are relative addresses intended to cause several
   objects to relocate together if one is "moved" or erased.  Terminals
   are not expected to remember any relation between objects once they
   are drawn.  Most will not be able to.

   Although the cursor position on entry to graphics mode remains set
   from the last exit, it is wise to reinitialize it with a %GOMVA
   command before any long transfer, to limit the effects of lost
   output.





















                                  -5-