rfc553.txt

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

Network Working Group                                            C. Irby
Request for Comments: 553                                      K. Victor
NIC: 17810                                                       SRI-ARC
                                                            14 July 1973


               Draft design for a text/graphics protocol

DRAFT DESIGN FOR A TEXT/GRAPHICS PROTOCOL

   This proposal should be seen as a synthesis of existing ideas rather
   than an attempt to put forth new ones.  It is based on work by the
   NGG, Elaine Thomas, Peter Deutsch, Charles Irby, Ken Victor, Bill
   Duvall, Bob Sproull, and others at ARC, PARC, and BBN.

   We are concerned about the lack of text-handling capabilities of the
   protocol suggested in RFC 493.  Also, we feel that the protocol will
   have a significant influence on the interface provided to writers of
   future graphics application programs, and consequently that such
   things as "beam twiddling" should not be part of the protocol.

      Things of this nature address the problem at too low a level for a
      facility which is intended to service the needs of a wide range of
      graphics devices.

      We feel that, although the breakdown into "levels" as proposed in
      RFC 493 may be expedient for initial experimentation, it is
      inappropriate for a Network Standard Protocol.  Instead, we
      propose that the protocol allow for two levels, segmented and
      structured.  This allows the writers of graphics application
      programs to deal with a very simple display facility (segments
      consisting of lines, dots, or character strings) or with a
      powerful structure of display subroutines.

   We propose an experimental implementation of such a scheme on the
   ARC, BBN, and PARC systems to test these ideas using several
   application programs (including NLS) and at least an IMLAC, ARDS, and
   an E&S LDS.

Environment

   We are trying to design a protocol used to communicate with a
   "virtual display" to operate at the other end of a wire (ARPANET
   connection) from a "host" which is running some kind of display
   application program.






Irby, et. al.                                                   [Page 1]

RFC 553        Draft design for a text/graphics protocol    14 July 1973


      We will adopt the terminology that the human user, sitting at the
      display, is the "user" and the application program is the
      "server".

   We wish to stress the fact that within a single application, a single
   terminal should be useable both as an "interactive graphics" terminal
   AND as an "interactive control" terminal.  Thus, the graphics
   protocol must allow for teletype-like operations.

   The need for two sets of connections for running graphics programs
   over the Net (according to our understanding) is centered about the
   issue of handling (being able to recover gracefully from) berserk
   programs (and perhaps achieving greater bandwidth through the net).

   We recognize this problem but also think one should be able to run
   graphics programs using only one set of telnet connections.  Also, it
   seems obvious that even though one is running a graphics program, one
   must expect to be able to handle "unescorted" characters (not
   embedded in a command or response message) being sent to his
   terminal.

   Consequently, we are proposing that the graphics protocol be
   implemented within telnet using 8-bit BEGIN-GRAPHICS-COMMAND and
   END-GRAPHICS-COMMAND characters or the 8-bit transparent mode of the
   new telnet.  This means that one will be able to run graphics
   programs with one, two, or more sets of telnet connections.

   We also strongly propose that any site which is interested in
   supporting display terminals for use in network graphics would be
   prudent to implement local control over the display (such as IGNORE-
   GRAPHICS-COMMANDS, RESET-TO-TTY-MODE commands from the user to the
   using host).  Failure to take such precautions may very well lead to
   burned out tubes!

Basic concepts

   The model

      The model we are adopting consists of an application program
      manipulating a (remote) display file.  This file may be
      "segmented" or "structured", in which case it may be manipulated
      independently from the display itself.

         For structured display files an "update display" command causes
         the display file to get mapped onto the display in whatever
         fashion is appropriate for the display.





Irby, et. al.                                                   [Page 2]

RFC 553        Draft design for a text/graphics protocol    14 July 1973


      Part of this protocol deals with commands issued to the (remote)
      display file editor.  This editor creates and changes the display
      file at the user host.

   Structured Display Files

      A structured display file consists of named subpictures, each
      containing any number of named units.  There are two types of
      units, primitive units and call units.  The effect of a unit is
      independent of its name or creation within the subpicture.

         Primitive units contain drawing instructions and associated
         coordinates that may generate visible information on the
         display screen.  Drawing instructions and coordinates can occur
         only in primitive units.

         Call units give the display structure a subroutine capability.
         A call unit invokes the display of another subpicture.  In
         other words, a call unit allows one subpicture to contain
         instances of other subpictures.  As well as providing for
         subroutine-style control transfer, call units can be used to
         establish display parameters and maintain parameter
         transparency.  For example, a call unit can be used to call a
         subpicture with a translation and relative intensity setting.
         On return from the called subpicture, these parameters are
         restored to their original values.

         A subpicture is an ordered list of units which can be any
         mixture of primitive and call units.  Each subpicture begins
         with a header and terminates with the subpicture end unit.  The
         subpicture end unit is a single unique unit in a display
         structure linked to the end of each subpicture.

         In order to understand how control passes through a structure,
         one can think of the display elements as follows: subpictures
         are subroutines and units are linked blocks of in-line code.
         When all of the units contained in a subpicture have been
         executed, the subpicture end unit returns control to wherever
         the subpicture was called from.  A primitive unit contains
         display code and transfer to the next unit.  A call unit
         contains a subroutine call to a subpicture and a transfer to
         the next unit in line.









Irby, et. al.                                                   [Page 3]

RFC 553        Draft design for a text/graphics protocol    14 July 1973


   Segmented Display Files

      A segmented display file consists of named segments, each
      containing any number of primitive units.  The only operations
      available for segmented display file is to add new, delete old, or
      replace old segments (updating the actual display happens
      automatically).  The effect of a unit is independent of its name
      or creation order within the subpicture.

   Hosts

      Since a given terminal may be under partial control of several
      different hosts, all further discussion of names, coordinates,
      display files, etc. should be taken as relative to each individual
      host.

      That is, each host believes it has a display file, naming, and
      coordinate space and a set of state parameters entirely under its
      control; its only evidence of resource sharing is that the
      terminal may appear to be of different sizes at different times.

      (We feel that in principle it should be processes within hosts,
      rather than hosts, that enjoy these properties, but it does not
      seem feasible to construct a process identification scheme that
      all hosts will find acceptable.)

   Subpictures

      A subpicture has a name and zero or more units.

         Subpicture names are arbitrary, globally unique, fixed-length
         identifiers (subpicture names are chosen by the host).

         Each unit (displayable component) has a name, which is local to
         the subpicture.

      A unit may be a "primitive unit", such as a string or a vector, or
      a "call unit", which implies displaying a (possibly transformed)
      copy of another subpicture.

         The display data are organized into a re-entrant tree (acyclic
         graph) by the call units.

      A unit may be "visible" or "invisible".







Irby, et. al.                                                   [Page 4]

RFC 553        Draft design for a text/graphics protocol    14 July 1973


         A particular instance of a subpicture (the result of a call-
         unit) appears on the screen precisely if it and all subpictures
         on the logical path to it from the root of the tree are
         "visible".

   Primitive units

      Strings

         A string is a horizontal line of characters with its own mode
         and X,Y origin relative to the origin of the subpicture.

            Note: intensity is always relative.

         Font and mode (e.g. blinking) information logically accompanies
         each character.  This is accomplished by means of embedded mode
         and font specification characters and a "restore original
         string mode and font" character.

            Note: Mode modifiers are non-displayable characters and do
            not take up character positions on the screen.

         Determining the space occupied on the screen by a string
         requires knowledge of the font(s) being used; this is a
         separate question which is dealt with later.

   TTY units

      A tty unit is a rectangle that consists of a number of lines.
      Within this unit the display acts as if it were an alpha-numeric
      display, e.g.,

         characters which would write beyond the right hand margin of
         the rectangle cause an automatic line folding to take place

         ascii control characters CarriageReturn, LineFeed, FormFeed,
         and BackSpaceCharacter, (HorizontalTab and VerticalTab?), are
         interpreted appropriately

         other control characters are displayed in a terminal specific
         manner, e.g. ^F, <^F>, etc.

         display of the characters in the range 200-377 is left
         unspecified at this point (truncated to 7 bits?, alternate
         fonts?, alternate modes?)






Irby, et. al.                                                   [Page 5]

RFC 553        Draft design for a text/graphics protocol    14 July 1973


            It is hoped that we can agree on a standardization of some
            of the characters in this range to allow for such things as
            greek letters, common mathematical symbols, super-scripting,
            and sub-scripting.

         linefolding that would cause characters to be written below the
         rectangle (whether performed automatically or by a LineFeed
         character, etc.) cause the text within the unit to be scrolled
         upwards one line (storage tube may adopt a different scheme).

      Characters are displayed in a teletype unit in one of two ways:

         Characters sent to the terminal that are not part of any
         command (unescorted characters) are appended to appropriate
         tty-units (see below --- USE-TTY-UNITS, TTY)

         By use of the APPEND-STRING-TO-UNITS command for structured
         display files

      The first character sent to a tty-unit appears as the first
      character (at the left margin) of the top line.  This is necessary
      for a number of reasons, the most convincing of which is the
      behavior characteristics of storage tubes and most real alpha-
      numeric displays.

         Successive characters appear as successive characters within
         the top line until either an explicit (e.g., linefeed) or
         implicit (line overflow) line break occurs.

         When a line break occurs, the next character appears on the
         second from the top line of the unit.

         This continues until the bottom line of the tty-unit is
         reached.

            At this point, a line break causes the lines within the unit
            to scroll up one line.

               Note: Storage scopes may use a different technique for
               scrolling.

      Dots

         A dot unit consists of an initial X0,Y0 followed by a series of
         points X,Y which describe a series of dots.

         Each dot unit logically carries mode information such as
         blinking, relative intensity, etc.



Irby, et. al.                                                   [Page 6]

RFC 553        Draft design for a text/graphics protocol    14 July 1973


      Lines

         A line unit consists of an origin X0,Y0 followed by a series of
         points X,Y which describes a series of straight lines connected
         tail-to-head (i.e. a polygon).

         Each line unit logically carries mode information such as
         blinking, dotted vs. solid, invisible.

         Other kinds of lines, such as conic sections, may belong in the
         primitive set.

      Special points