1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318
|
<pre>Network Working Group S. Crocker
Request for Comments #86 January 5, 1971
NIC 5631 UCLA
Proposal for a Network Standard Format
for a Data Stream to Control Graphics Display
A typical arrangement of facilities is to have a console attached to a
computer at the user's site, and to be using the computational facilities
of a remote site. Information entered by the user is transmitted to the
remote Host, and output from the remote Host is transmitted back to the
local user. In this proposal I am concerned with specifying the form of
the output stream for the case that the output portion of the console is a
typical refresh display with point, vector and character drawing capability.
Devices in this class include the DEC 338, DEC 340, IBM 2250, and IMLAC
PDS-1.
It must be understood that this proposal is illustrative only, and knowingly
avoids important issues. Its main purpose is to provide a basis for dis-
cussion and development.
In order to specify the semantices of the network standard graphics data
stream (NGDS), I will postulate
1. a network standard display list (NGDL)
2. a network standard stream interpreter (NGSI)
3. a network standard list interpreter (NGLI), also called the
display controller, and
4. a network standard screen (NGS)
<span class="grey"> [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey">The NGDS is accepted into the local Host and interpreted by the NGSI. The</span>
NGSI is a process which modifies the NGDL according to inputs in the NGDS.
The NGDL is the display list for the NGLI; the NGLI executes the NGDL and
controls the beam which writes on the NGS.
The NGS is square, has horizontal and vertical sides, and positions on it
are specified by an ordered pair of unsigned 16 bit fractions. The first
fraction specifies the horizontal distance from the left hand edge, and
the second specifies the vertical distance from the bottom edge. The
resolution of the screen is unspecified.
The lack of specification of the resolution of the NGS is intentional;
programs designers should not interpret this to mean that they may impose
a particular requirement on the using system. Thus the quality of the
displayed picture should degrade gradually with decreasing resolution.
The NGLI has primitives for moving the beam to a particular point, intensify-
ing a point, drawing a vector, or drawing a character. Characters are
assumed to be not more than .015 screen width wide, and not more than .025
screen height high. When the beam is moved to a screen position before
drawing characters, that position should be at the lower left hand corner
of the first character drawn. The beam position after drawing a character
is immediately to the right of the character, properly positioned for another
character. However, after drawing one or more characters, the exact horizontal
<span class="grey"> [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey">position of the beam is unspecified.</span>
The imprecise specification of character size is intended to take cognizance
of the existance of character drawing hardware which is capable of producing
only one or a few character sizes. The particular proportions of .015 wide
by .025 high provides for 67 characters to a line and 40 lines, and seems
well within the capability of most displays in the class considered. As in
the case of screen resolution, variations in character drawing hardware
should cause only minor degradation in the usefulness of the picture.
The character set intrepreted by the NGLI is ASCII, excepting all form
control characters, but including the space character. The tab, return
and line feed functions should be simulated by explicit positioning of the
beam.
The NGDL consists of a set of named and possibly null lists. The names
are 16 bit integers, and the name zero is the name of the chief list.
Each list is composed of zero of more display items. An item is any of
the following:
<span class="grey"> [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey">a) "Move beam to xxxx,yyyy, relative to current origin"</span>
b) "Display vector from current position to xxxx,yyyy, relative to
current origin"
c) "Display current point"
d) "Display the following n characters:
c c ...c "
1 2 n
e) "Execute list gggg with origin xxxx,yyyy relative to current origin"
The NGLI is constantly in a loop executing the chief list, the origin of
the chief list is always <0,0>. When the NGLI comes to the end of the
chief list, it returns to the top of it. When the NGLI encounters a
type e item, it suspends execution of the current list, set the new origin
to <xxxx,yyyy> + <the old origin>, and executes the list named gggg. When
finished with the list, the old origin is restored and execution of the
old list resumed. The NGLI is, therefore, a recursive interpreter, and
type e items are subroutine calls.
There remains only the matter of the NGDS and the NGSI. The NGDS is parsed
into commands by the NGSI and each command is executed as soon as it is
recognized. The commands in the NGDS are in prefix form, consisting of an
eight bit operation code followed by any arguments. Only two commands
are defined: Erase and Replace.
The Erase command consists of a single zero-valued opcode and no arguments.
The NGSI executes the Erase command by making all lists into null lists.
<span class="grey"> [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey">This erases the screen.</span>
The Replace command has an opcode of 1, followed by a 16-bit list name,
followed by an 8 bit subargument count, followed by the indicated number
of subarguments. The NGSI executes the Replcae command by deleteing all
items from the indicated list, and rebuilding the list from the subarguments.
There are five kinds of subarguments, corresponding to the five item types.
<span class="grey"> [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><subargument>::=<atype> | <btype> | <ctype> |</span>
<dtype> | <etype>
<atype>::= <a> <x> <y>
<btype>::= <b> <x> <y>
<ctype>::= <c>
<dtype>::= <d> <n> <c> ... <c>
n
<etype>::= <e> <g> <x> <y>
<a>, <b>, <c>, <d>, and <e> are 8 bit bytes valued at 0, 1 ... 4,
respectively and corresponging to the item types listed on page 4.
<x> and <y> are 16 bit numbers
<g> is a 16 bit list name
<n> is an 8 bit count
<c> is an ASCII character code
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Anand Kumria 6/97 ]
[Page 6]
</pre>
|