home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc125.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  8.2 KB  |  219 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                          NETWORK WORKING GROUP
  8.  
  9.                         REQUEST FOR COMMENT: 125
  10.  
  11.                                 NIC 5841
  12.  
  13.  
  14.  
  15.  
  16.                              APRIL 18, 1971
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.                              JOHN McCONNELL
  30.  
  31.                           AMES RESEARCH CENTER
  32.                        MOFFETT FIELD, CALIFORNIA
  33.  
  34.  
  35.  
  36.  
  37.  
  38. Response to RFC #86, Proposal for Network Standard Format for a graphics
  39. data stream.
  40.  
  41.  
  42.  
  43. Category         D.6
  44. RFCs obsoleted   None
  45. RFCs updated     86
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. The basic approach of transmitting an intermediate, device independent
  61. language which is translated into specific device codes at the
  62. receiving host is sound. It appears to be the only approach that will
  63. allow thought to be centered on picture descriptions. Ames Research
  64. Center has adopted this approach in tying its graphic facilities, of
  65. various types, and on various computers together. At present, we are
  66. in the design phase and expect our package to be running in about six
  67. months. The main objections to the structure as it now exists, is that
  68. it takes no cognizance of the many features available on graphics
  69. devices. Since these features will always be changing with new
  70. devices, a set of option or mode primitives should be defined which
  71. are logically separate from the drawing primitives provided in RFC 86.
  72. The mode primitives will act upon the drawing primitives to modify
  73. their actions. The scope of a mode primitive extends until a new mode
  74. primitive resets an option. The use of mode primitives will allow the
  75. network standard stream interpreter to treat them as null operations
  76. if the features are missing at a particular host, or to perform more
  77. detailed interpretation of the following data stream to achieve
  78. results. The drawing primitives may also then keep a standard format
  79. which need not be changed to incorporate new features.
  80.  
  81. Overall modes which primitives could control would be intensity
  82. levels, or color selections for objects, in addition blinking of
  83. objects should be provided. For vectors, the additional facility for
  84. drawing dashed lines is necessary.
  85.  
  86. Character strings require another set of specification. The convention
  87. for the beam is usually that it is in the center of the rectangular
  88. area defining a character's boundaries. The beam position is usually
  89. undefined at the finish of drawing a character string. A strong
  90. exception is taken to the exclusion of form control characters from
  91. strings. If included in the character string, they could provide for
  92. shifting from upper to lower case, subscripting, superscripting, and
  93. underscoring, as well as tab and other "carriage" motion functions.
  94. The appropriate characters could be extracted at interpretation time
  95. to provide the necessary information to display more complex strings.
  96. To allow the facility for generating ALGOL-like delimiters, such as
  97. "then", a convention for canonical character string should be adopted.
  98. I believe the Multics conventions described in reference 1 will
  99. suffice.
  100.  
  101. Additional options for character strings should include a size
  102. specification and an orientation selection. As many devices, have
  103. hardware character generators that are fixed, some of these options
  104. may not be desirable to implement as subroutines.
  105.  
  106. Another area that should be looked at further is the additional
  107. symbols available which are not specified in ASCII. Some means of
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. defining them should be provided within the argument string itself,
  114. again Multics has allowed the specification of arbitrary characters by
  115. entering their octal equivalents. The convention should use a control
  116. character code followed by a l6-bit list name which specifies the
  117. sub-list defining the character. The other alternative is to allow
  118. 8-bit characters and allow the interpreter to choose a sub-list if the
  119. character is not realizable with a hardware generator.
  120.  
  121. The special form control characters to be used are:
  122.  
  123.     a. BS    - backspace
  124.     b. LF    - for new line
  125.     c. SO/Sl - shift case
  126.     d. DC2   - superscript following characters
  127.     e. DC4   - subscript following characters
  128.     f. DC3   - special non-ASCII character follows
  129.     g. Tab   - position to next tab. May be predefined or specified.
  130.  
  131. Another construct should be added to those proposed in RFC 86. This is
  132. the display list pointer (NGDLP). It will have as a value the next
  133. drawing primitive to be executed. The value is a displacement from the
  134. head of a list. With no mode setting primitives, this value is one to
  135. one with the drawing primitives transmitted in the NGDS. The NGDLP is
  136. needed for consistency for execution of the nested list structure.
  137. Whenever an execute list primitive is encountered, the current value
  138. of the NGDLP is saved along with the list name and current origin
  139. value. When execution of a list is finished, the last values saved are
  140. restored.
  141.  
  142. An include list primitive would allow the treatment of a sub-list to
  143. be equivalent to a macro instead of a subroutine. This would be
  144. necessary to avoid changes to all sub-pictures on the screen due to
  145. the manipulation of a sub-list. The include primitive should have as
  146. parameters such specifications as size, intensity, orientation,
  147. blinking, etc. After a sub-list has been included in another list, it
  148. is no longer distinguished as a separate entity.
  149.  
  150. To cut down on the volume of data being transferred, other commands to
  151. be parsed by the stream interpreter should be added. These would allow
  152. the manipulation of a list by the receiving host without a
  153. retransmission.  The types of manipulations would include rescaling
  154. the coordinates for shrinking or zooming, translation of the origin,
  155. or rotation. Other manipulations to provide for displaying or not
  156. displaying a list, or enabling of disabling light pen detections would
  157. be desirable.
  158.  
  159. The problem of interaction with the displayed picture has yet to be
  160. addressed, so this will be an attempt to elicit some more discussion
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166. in this area. The use of a keyboard or function keys poses no problem
  167. in that both can be handled as a standard message from the graphics
  168. terminal. The use of devices that interact with the picture or the
  169. screen such as light pens, mice, joysticks, or tablets presents a
  170. different and more complex problem. This problem is the standard one
  171. of making an association between the point selected and some
  172. meaningful entity such as a list or a primitive. This association
  173. should be made at the receiving host since the NGDS has been changed
  174. in unknown ways.
  175.  
  176. To allow the transmitting host to identify the object pointed at, the
  177. stack of suspended lists and the current value of the NGDLP will
  178. qualify the object to any level in a hierarchical structure. In
  179. addition, normalized x,y coordinates should be returned, as well as a
  180. character displacement if a string was pointed at. This structure will
  181. serve a light pen device very well since the light pen mechanism
  182. allows the determination of the currently executing primitive. Other
  183. devices interact with the picture in an asynchronous fashion and the
  184. association of an x,y pair to a structure is a more difficult problem.
  185. This may require that the host generating the graphic data stream be
  186. responsible for making that association. A further complication arises
  187. when it is desired to use a light pen in an area where no beam motion
  188. occurs, then some directive to periodically sweep the screen and
  189. "find" the pen must be provided. This might be a sub-list which is
  190. executed periodically for this function.
  191.  
  192.  
  193.        [ This RFC was put into machine readable form for entry ]
  194.         [ into the online RFC archives by Jerry Tenenbaum 4/97 ]
  195.  
  196. ---------------------------------------------------------------------------
  197. Reference: Osanna, J., Sahzer, J.
  198.            Remote Terminal Character Stream Processing of Multics
  199.            Proceedings SJCC, 1970, p. 671
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.                                                                 [Page 4]
  218.  
  219.