SUPDUP graphics extension
RFC 746

Document Type RFC - Unknown (March 1978; No errata)
Authors
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 746 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text