15358 ~

Network Working Group Ap r l 1 26, 1973

Request For Comments #493 Jim Michener, MAC
IJI C Ii 15358 Ira Cotton, MITRE
, References: 282, 285 L· _ '~__ - _ _ ·v L::. U Karl Ke 11 e y, U• of I 11 •
! Updates: None Dave Li d d 1e, O\'Je n 5 I 11 •
Obsoletes: 292 MAY 1 '( i973 Ed Meyer, MAC

GRAPHICS PROTOCOL
Introduction
This document reflects opinions expressed and decisions reached
at the second meeting of the Network Graphics Group, held at the
Stanford Artificial Intelligence Laboratory in late Nov embe r
1971. It describes nart of a proposed Network Standard Graphics
Protocol for transmittin~ graphics data within the ARPA network.
The particular aspects of the protocol covered in this document
relate to the form and content of ~raphics information sent from
a source of graphical l n f o rrna t l on (an application program, say,
in the "Se rv l ng 1I0st") to a display package for output to a
graphics console (at the "Using Host ll ) . This will take the form
of a sequence of a-bit bytes, and will be called the graphics
output byte stream.
This document is intended to serve as a basis for discussion and
for experimentation over the network. This document does not
.. ­ include form or content of graphics input (data sent frOM the
Using 1I0st to the Serving Host) nor does it cover hO\'I the
connection is estab1 ished between the hosts. A proposal for the
former will be generated eventually by this committee; the latter
is the job of the Connection Committee (of the Network Graphics
Group).
This RFC describes the cornnan ds wh l c h are available in the
protocol in terms of the effect they wou l d have at the re ce l v l n rr
(Using Host) end. Clearly, sone subroutine packap:e is desirable
at the Serving Host for use by app l ications in transmittinp,
graphics data, but on this topic this RFC does not intend to
comrne n t ,

It may be observed by the reader that no facil ity is specified in

this po r t o co l, a l l ow l ng the Using Host to report logical errors in
the g rap h i c sou t put by t est rea m tot ~1 e Se r v i ng t los t . Suc h a
facil ity would have to be integrated with the ~raphics input byte
stream, since it involves most of the problems related to
synchrony of independent hosts.
Background
The reader should probably peruse RFC 282: "Graphics t'1eeting
Report" by l iike Padl l ps kv to obtain SOMe of the f r arnewo r k
surrounding this discussion of network ~raphics. Also it might
be valuable to make note of the model described in RFC 285:

-1­
, 't,

/ /

"Network Graphics" by Donald Huff.

L~vels and Ground Rules Pertaining Thereto

Functions within the ~raphics protocol will be classified into a

number of levels depending partly on how difficult it is to
implement those functions. It is intended that any host which
claims to implement the functions of level N must implement all
lower levels as we l l . Thus, it is envisioned that sites will
implement levels incre mently. · Implementations will be improved
as a continuing process to include more and more functions, and
it is intended that each implementation will be able to identify
its own level to a graphics protocol at a remote site which is
requesting a graphics interchange. A side result is that each
site will be able to determine its own priorities in committing
programmers to the graphics protocol as opposed to other efforts.
It is also our intention t hz t lrnol emen t e t l on of level N will
require no knowledge of level N+l. Thus a site can implement a
level in the (reasonably) firm know l e dg e that no changes at
higher + ev e-l w·i-ll alter the level implemented. At some time it
may be decided by the Network Graphics Group to redefine a level
which has previously been firned up. It is not our intention
that this shall happen but one must recognize that the proposed
Graphics Protocol is experimental ann may have to be changed.
One further ground rule: a stream of commands and data which is
val id at a given level, K, shall produce "identical" results on
any interpreter of level K or hi~her. By this we mean that as
long as the conmands and data take advantage only of strictly
defined operations, similar pictures should result. Aspects of
the protocol which are not strictly defined (at this time)
include character size, character position relative to the beam,
how control characters in text output affect the terminal and
' wha t happens when the beam is moved or aline drawn outside of
the logical screen boundary. This rule forces upwards
compatibil l t v, so that an app l ication wr l t t en using features of a
low numbered level will still work at sites which have moved on
to implel7lent higher levels. Additionally, any aspects of this
protocol vzh l c h are explicitly "left unspecified" in the detailed
operations de s c r l p t i on s below shall be e xp l icitly specified in
any publ ic description of an actual implementation.
\~e now describe the f r arnewo r k which will be common to all levels.
Basic Data Forms
Information in the Network Standard Graphics Protocol will be
expressed as a sequence of a-bit bytes. A command will consist
of a command byte f o l l owe d by zero or rio re a r aurie n t s , Tile s ane
command byte will always take the same number of arguments in the
sane form. The length of each argument may be fixed or variable

-2­
 " ,
,;

~j depending on the argument.

A simple type of argunent is a "value," which is an 8-bit
integer. Another type of argument is a "string" wh l ch is a count
followed by (count) number of 8-bit bytes. If the count is
be twe en " and 127, it is sent in a single byte. If the count is
between 128 and 2**15-1 (** means exponentiation), it is sent in
two bytes with the hieh order bit of the first byte set to one.
The first byte contains the seven high order bits of the number
and the second byte contains the eight low order bits. A string
is the only type of argunent of a co~mand which can vary in
length. For example, whenever a conmand has optional arguments,
they will be represented inside of a string.
Coordinate data engendered cosiderable discussion at the second
I~etwork Graphics Group meeting. It was decided that a
two-dimensional Lo~ical Coordinate Syste~ was required, and each
interpreter for the graphic conmand byte stream would be
responsible for mapping this coordinate system to physical device
cordinates. It was decided that data in the logical coordinate
system would be in twos-complement notation, that it would be
fractional, that each edge of the screen would have unit length,
and that the origin would correspond to the center of the screen
on the output device. The vertical (horizontal) edges of the
screen of the output device correspond to the 1 ines X (V) = -1/2
or X=+1/2-e where e is a small positive number determined by the
precision of the fractional data. Particularly the points (-112,
-112) (-1/2, l/2-e), (1/2-e, -1/2) and (1/2-e, 1/2-e) shall be
visible points at the corners of the logical screen. (In the
case of a non-square display surface, the implementer may make
his own decision. Thus we shall say that the Logical Coordinate
System contains points whose coordinates range from -1/2 to a
1 ittle less than +1/2.
Commands which take coordinate data will be available in various
modes. In absolute mode, a position is specified by giving its
coordinates in the Logical Coordinate System. In relative mode,
the difference between the coordinates of the position and the
coordinates of the current position must be specified. Thus a
coordinate datum which is an argument for an absolute mode
operation should be in the range -1/2 to +1/2-e, while one for a
relative mode operation should be in the range -l+e to +l-e.
Interest was expressed at the second Graphics GrouP Meeting in
eventually allowin~ a very lar~e coordinate space (many bits of
precision in each fractional coordinate). This is to be done by
pe rrn l t t In g the length, in g-bit bytes, of each coo r d In a t e datum
to be set (as a mode). It was decided at the meeting that two
bytes per coordinate wou l d suffice " for now , Thus "e" in the
above discussion is 2**(-15) (one in the least significant bit of
a 15-bit plus sign fractional coordinate).

-3­
 •

Text data will be transnitted as an arp,ument of various commands

for display on the output device. Network ASCI I will be used to
represent characters. At the lowest-levels of the protocol only
one character size will be available -- wha t eve r is "normal" on
the d i sp l av dev i ce , I f the dev ice has no "normal" size, 72
characters per 1 ine would be desirable. At higher levels the
size of each individual character can be specified.
Also, at the lowest levels, control characters will be passed
along to the device for it to do the best it can. However, the
consensus of the graphics neetin~ was that at some reasonably low
(but non-zero) level, carria~e return, 1 ine feed, and backspace
should be interpreted to do the right thing.
Picture Subroutines and Related Topics
At the second Network Graphics Group meeting, it was decided that
two sorts of picture subroutines were desirable, the primary
distinction between then being relative difficulty of
implementation. At the meeting, the simpler variety was called a
subpicture, and the more complex was called a subroutine. This
author bel ieves that these terms do not embody emough semantics
to facil itate keeping the two straight and so proposes to
standardize on "simple subpicture ll and "full subpicture" instead.
The only parameter which can be passed to a simple subpicture is
the "current beam position." In other wo r ds , if such a
subpicture is called more than once in a picture, the only
difference in appearance between the various calls is a
translation due to the bean position at the time of the call.
Full subpictures, on the other hand, take parameters which can
cause seal ing, rotation, reflection, or anything else we come up
wi t h ,
It is planned that a subpicture definition need be transmitted
only once (per network connection) and would not be deleted by a
"new picture" operation. Thus a changing picture could be
subdivided into several parts on a basis of static versus
changing information; only definitions of parts which change need
be transmitted to redraw the picture.
TraditionallY, picture subroutines which depend only on the
initial beam position have been restricted to relative data mode
drawing operations. In view of the fact that subpictures will
probably be used to save static picture information, it is
desirable to allow absolute data mode operations in simple
subpictures.
The next question naturally arises -- what does absolute data
r mean in a full subpicture which takes both position and scale
parameters? Is absolute data really absolute in this case? This
author bel icves that the answer is as follows: the full

-4­
 ,

/ ",

subpicture is really a picture in its own right, so it has its

own logical coordinate system, and its absolute data is really
within this coordinate system. Thus "shifting and seal ing" a
full subpicture really me an s "scale the subpicture in its O\'Jn
coordinate system and shift the result as a whole."
In summary, then, a major difference between siMPle and full
subpictures is that a full subpicture has its own logical
coordinate system and a simple subpicture uses the logical
coordinate systen of whoever calls it. This distinction is the
reason why full subpictures are harder to inplement than simple
subpictures.
Another point discussed at the meeting was a special data mode
whereby a subpicture can display data at absolute positions on
the screen, i.p.., absolutp.ly in the main (picture) program. To
achieve this, the rne e t l n e proposed special data modes for ' the
three operations: move beam invisibly, draw 1 ine, and display
dot. The intent of these data modes was to bypass all fotation,
seal ing, and cl l pp i ng functions associated with the cu r r en t level
of subpicture nesting until this mode was cleared in a certain
way. This same effect can be achieved more directly and
implemented more efficiently by t\JO commands r one to save and
one to re-establ ish the logical coordinate system for the current
subp l c t u r e . (Additionaly, of course, the "save" operation would
establ ish the initial, highest level, l o g l ca l coordinate svs t ern; )

Simple Subpicture Calls

Besides the <identifier> of the subpicture to be called, a simple
subpicture call may specify two optional parameters; the first
. is an <identifier> which is the "name" (in a sense described
below) of this particular subpicture ~ and the second is an
absolute position on the call inr, page to be invisibly moved to,
prior to call ing the s ubp l c t u r e , \'Jhen (eventually) the v l ewe r is
allowed to interact by "picking" information displayed before
him, if the information is part of a subpicture, then the "name"
of the subpicture ~ will be part of the "graphic input"
reported to the serving host. If the l n fo rma t l on picked by the
viewer is within several levels of subpicture calls, the nar1es of
each of the calls will be reported in a manner which indicates
the i r nest Ing , (Note that just the name of the s ubp l c t u r e by
itself is not sufficient, since one subpicture may be displayed
in several positions and the appl ication may wish to distinguish
be twe en individual c a l l s . ) If the identifier is not specified it
defaults to the null string. If the position (for the invisible
move) is not specified, the current beam position is used.
Which of these two parameters are present is encoded by two bits
in a code byte which preceeds the parameters. If both parameters
are present then they are always in the same order; this order
and the bits of the code byte assi~ned to the two parameters are

-5­
,

specified in the detailed description of the Simple Instance

command (and in the BNF in Appendix 1). Preceeding even the code
byte, and immediately following the name of the subpicture which
is being called upon, is a count of the data in the remainder of
the instance command. Thus is included so that it is not
necessary to decode the code byte " to determine the total length
of anyone Simple Instance operation.
\Ji nd m ·Ji ng: eli ppin g « f< 1 an kin g« 0 r (?)

Hhile on the subject of coordinate systems and subpictures, it

might be good to touch on the topic of: who (which end of the
connection) is responsible for doing v.ha t , when a picture is
potentially going to be displayed beyond the edge of the virtual
screen? It was the consensus at the ~raphics meeting that the
interpreter of the graphics protocol (i.e., the using end) would
not be held responsible for doing anything reasonable in case a
picture displays information beyond the ed~e of the screen (e.~.,
by relative moves and draus). The interpreter must react
properly to the next absolute data in the proper range, however.
Various solutions to this situation in existing graphics systems
include:
cl l pp l ng aline to display as much as is proper,
blanking the whole of aline if any part is invisible, or
discarding high order bits of the current position register, so
that no invisible positions can be represented
(llwraparound").
In addition to proble~s of edge effects at the highest level,
problems arise with respect to (full) subpictures. It is nice to
be able to select a rp.ctangular portion of a subpicture to be
displayed as part of a s ub o l c t u r e call. (See: ~lewli1an, Display
procedures, Commun l c a t l on s of the ACt~, Volune 14, Number 10,
October 1971, pp651-660). In accordance with the consensus of
the meeting, which was to make this capabil ity optional, this
author merely hopes to include in the protocol a method of
encoding this information since his site a) cari handle some such
windowing, and b) hopes to provide a service facility to perform
this function.
Appendix 2 describes how to concatenate several levels of
portions into a single rectangular test, as long as no rotations
are involved. It also outl ines the problems related to rotations
and portioning.
-
Full Subpicture Calls
We are now in a position to consider what may be specified as
part of a full subpicture call, in addition to the name of the
subpicture being called, which is, of course, required. The data
described be l ow vII 1 1 all be optional: a single code byte will
preceed all these data; the presence or absence of one of the

-6­
 J

parameters will be indicated by a bit in the code byte being one

or zero. The parameters will always appear in the same order, If
they are present. This order is given below in the detailed
description of the Full Instance command (and in the BNF in
Appendix 1). Additionally, preceeding even the code byte, will
be a <count> of the following bytes, including the code byte.
Thus it will not be necessary to decode the code byte to
determine the total length of any particular Full Instance
operation.
One parameter is an <identifier> which can be used to distinguish
this particular call to this subpicture frOM all other calls to
the subpicture. This parameter was already described under
Simple Subpicture Calls.
One parameter which may be specified is a translation: this will
be specified by giving the absolute coordinates of the center (on
the calling page) of the iMage of the subpicture; this will
default to the beam position current at the time of the call.
A rotation May be specified by givin~ a 16-bit fraction in the
range 0 to .1111111111111111 (binary) inclusive; this fraction
will represent what part of a full circle (2pi) the rotation is.
The default value of angle of rotation t/ill be zero.
(Actually, the rotation representation scheme works identically
if one thinks of it as a two's complement fraction from -1/2 to
just less than +1/2. That is, the sane bit configurations encode
the same rotation, due to the periodic nature of sine and cosine.
For example, binary zero always represents a pi; 010000 ••. 0
denotes pi/2 in both schemes; 100 ••• 00 denotes 1/2 in one scheme
and -1/2 in the other, which correspond to rotations of +pi and
-p l respectively, i.e. identical r o t a t l on s . )

Also specifyable as a part of a full subpicture call is a

rectangular portion of the called picture to be imaged on the
call ing picture (see previous section for a discussion of
cl ipping). This rectangle is specified by its center and one
hal f i t s tot a 1 s i z e i n x and v , That is, the r e c tan g 1 e \'1 ill
consist of all points whose x coordinate differs from that of the
center by no more than the specified x-size and whose y
coordinate satisfies a similar condition. The default for these
values will place the center at the origin arid ~ive both the x
half width and the y half width the value of +1/2. Thus the
default includes the \/hole of the logical coordinate system of
the called page (and also some points one of whose coordinates
are +1/2, which, strictly speaking, 1 ie "outside" of the
coordinate system; how this inconsistancy is resolved is left
unspecified).
Finally, one mus t specify the seal iny, to be app l ied in
determining the image; this can be done in many ways. One way is

-7­
 /

to specify a unifor~ ~agnification to be appl ied to the

subpicture. So that magnifications in a wide range can be
achieved, it is the author's opinion that some form of scientific
notation (i.e., floating point) will have to be employed. If
there is already a network standard floating point notation
(wh l ch I am not awa r e of) it should be employed. Fail ing that,
It is suggested that this notation consist of an a-bit (two's
conplement) exponent followed by a 16-bit (two's complement)
fractional part.
Another form of seal ing is to specify separate ma~nifications in
x and in y, to be appl led to the subpicture before any rotation
is performed. Yet a third way is to specify a rectangular area
in the calling picture's coordinate system to be filled with the
image of the subpicture. Since the center of the image is
already specified (by the translation), this image information
consists only of half-edge size data. If none of the three
methods of seal ing are chosen (and an affine transformation (see
below) is not given expl icitly), then a uniform magnification of
unity (i.e., no seal ing) is used. Note that the three forms of
seal ing tend to contradict each other and only one of them should
be used in anyone call. What happens If self-contradictory
information is given in these fields is left unspecified.
Appendix .2 presents the ~athematics involved in transforming the
subpicture's coordinate system into the calling picture's
..: coordinate system. It is shown there that all the individual
operations (seal lng, rotating, and translating) can be
represented as a single affine transformation (which consists of
6 values). It might be nice to permit the servin~ program to
specify this transformation directly. Accordingly, one possible
parameter of a full subpicture call will consist of six floating
point numbers (of the form described under magnification, above)
to be interpreted as an affine t r an s f o rma t l on , i'ldeed, if the
-affine transformation has the following form:
L Ix Iy_/ =L x y / * / Lll LI2 / + L Tl T2 /
L L21 L22 _/
then the values shall (arbitrarily) be sent in the following
(columnar) order: Lll, L21, L12, L22, T1, T2. This affine
transformation should be invertible; that is, LI1*L22 - L21*L12
should not be zero.
Yie\'Jport jng

Another topic discussed at the meeting, and referred to the

protocol con~ittee for decision, was the capabil ity of placing
t h e .1 t op 1 eve 1 I Ipicture
· • •
In some rectangle of the virtual screen.
The default rectangle might be the full screen. Alternatively it
might be left up to the v l ewe r to specify the default (Y...L2.)
interaction with the graphics system at the Using Host). In

-8­
~-'1 ' general, vie v,porting a l l ows more than one "top level" picture to
be viewed at once. The desire to view several different pictures
on the same screen arises in cases v.he r e multiple users are
working together and in cases where one user is interacting with
a group of appl ications (in separate serving hosts>. This author
maintains that the coordinate transformations required by this
feature are simpler than that of "full subpictures" since no
rotations are involved, and would be part of the same mechanism
in its implementation. In particular, merely another affine
transformation (see Appendix 2> would be added to the levels
caused by full s ubp i c t u r e calls. All that is required is keeping
track of viewport identifiers and the associated rectangles.
Since little extra work is involved, it is proposed that this
feature be included at so~e high level of the protocol.
Command Codes
Each command in the graphics protocol will he assigned a
non-negative value which will represent this command in the byte
stream. The algorithn whereby values and commands are associated
is, it turns out, a very touchy subject. There are five or ten
different criteria for a "best" algorithm, each criterion
different in emphasis. This Gordian knot will be cut, In this
proposal, by ordering the co~mands approximately according to
level, and then just numbering them. In addition, if several
closely related commands occur at the same level, some attempt
will be made to encode variations of meanings in terms of bit
configurations. Even if some later consideration causes a change
in ordering to be proposed, it is this committee's feel ing that
the numbering should not be altered. Howev e r , until this matter
is firmly settled, it is strongly advised that any implementation
take into account the possibil ity of reassignment of command
codes.
Particular Proposal for Leyel 0 Protocol
It is proposed that level 0 be kept very simple. This is so that
impleDentation can be quickly accompl ished and experimentation
with the protocol begun. Another reason is that the least
powerful host and even programmable terminals should be able to
implement it. In accordance w I t h this, the "rule" was made that
a command be included only if its output is a function solely of
the current cOr.lDand and the "beam position" current at the start
of the command. In other words, the interpreter for level 0 need
have no internal storage for "modes" or pu s hdown stacks. ,..,rith
this restriction it is hoped that a very simple implementation
will be possible for level o. In particular, perhaps one could
eventually build a hardware translator from level 0 code to one's
own particular terninal 's code.
Note that in the opcode assig~nent for level 0, bits 4, 2, and 1
have special meaning for the move, line, and dot commands. In

-9­
particular, the 1 bit encodes absolute versus relative data mode,
the 4 bit encodes whether any visible output occurs, and the 2
bit determines whether the visible output is aline or a dot.
Level 0; Command Summary
The following is a 1 ist of com~ands (and their syntax) in level
zero. Detailed descriptions of these commands follow in the next
section. Commands deal ing with protocol may be added by the
Connection Committee. (They currently request opcodes in the
range 128 to 255.)
(As described in Basic Data Forms, above, <x coordinate>, <y
coordinate>, <x delta> and <y delta> are two-byte coordinate
values, <string> is a count followed by (count) many bytes and
<value> is an eir,ht bit number.)
Decimal Octal Binary Format
o 0 00000000 Nu 11

1 1 00000001 Erase screen and reset beam

2 2 00000010 Move Absolute <x coordinate> <y

coordinate>

3 3 00000011 Move Relative <x delta> <y delta>

4 4 00000100 Draw Absolute <x coordinate> <y

coordinate>

5 5 00000101 Draw Relative <x delta> <y delta>

6 6 00000110 Dot Absolute <x coordinate> <y

coordinate>

7 7 00000111 Dot Relative <x delta> <y delta>

8 10 00001000 Text <string>

9 11 00001001 TextR <string>
1'0 12 00001010 End of Picture
11 13 00001011 Escape <value> <string>
Level 0; Com~and pescriptions
o Null Statement (IINULL").

This statement has no ar~uments--and no effect, either.

1 Erase screen and reset beam to origin ("ERASE").

This command indicates that a ·new picture is about to be drawn.

It should always be (eventually) paired with a following End of

Picture command.

2 Move beam invisibly to absolute position

( t--1 0VEA" ) <x coordinate> <v coordinate>.

IJothing is dravm; the beam is positioned to the specified

absolute x,y position.

3 Move beam invisibly by relative amount

(IlMOVER") <x delta> <y delta>.

IJothing is drawn; the beam is shifted by the specified amount in

-10­
,...·1 x an d v ,

4 Draw line to absolute position

<x coordinate> <v coordinate>.

(IlDRA~'JAIl)
Aline is drawn from the current beam position to the specified

absolute x,y position.

5 Draw 1 inc to relative position

<x delta> <v delta>.

(IlDRA~'JR")
A line is drawn from the current beam position to the position

delta x and delta yaway.

6 Display a Dot at absolute position

(IlDOTA Il) <x coordinate> <v coordinate>.

The beam is moved invisibly to absolute position x,y and a dot is

displayed there.

7 Display a Dot at relative position

(IIDOTR") <x delta> <y delta>.

The beam is moved invisiblY by the specified amount in x and y

and a dot is displayed there.

8 Display text ("TEXT") <strinp;>.

At the current beam position, display some characters at the

normal size for the device being operated. <string> consists of

a <count> f o l l ov/e d by count many characters. If there is no

"normal s i ze s " choose the size so that s ev en t v-itwo characters are

displayed per line. The characters in the string are coded in

ne two r k ASCII; all codes be twe e n 0 and 127 (decimal) inclusive

are permitted. (At level zero, what happens to control

characters is left unspecifie~.) ~here the beam is, following

execution of this command, is left unspecified, except that

another Display Text comnand immediately following will append

its text to the previous string. (The use of the TEXT command is

discouraged; use TextR instead.) The position of the first

character relative to the initial beam position is left

unspecfied.

9 Display text and restore beam ("TEXTR") <string>.

At the current beam position, display a string of characters at

the normal size for the device being operated; then reposition

the beam to where it was before the command. <string> consists

of a <count> followed by count many charact~rs. If there is no

"normal s l ze s " choose the size so that s e ve n t y-r two characters are

displayed per line. The characters in the string are coded in

network ASCI I; all codes between 0 and 127 (decimal) inclusive

are permitted. (At level zero, what happens to control

characters is left unspecified.) The position of the first

character relative to the initial bean position is left

unspecified.

-11­
..--, 10 En J 0 f Pic t u r e ( liEN DPIC II ) •
This command denotes the end of a new picture. It must be paired
with a preceeding ERASE command.
11 Escape to device specifics ("ESCDEV") <value> <strin~>.
If "value" is the code as s l rme d (by the Protocol Committee) to
the device being operated, then transmit the eight-bit bytes in
<string> (which starts with a <count> indicatin~ the number of
bytes) to the device without examining them. Otherwise ignore
this corman d , If the device does not accept a-bit information,
reformat the data in some device specific way; an example would
be throwing away the hi~h order hit for a seven bit device, or
gathering 58-bit bytes into one 3G-bit word, again discarding
the high order bits, perhaps. The action of the bytes in the
string should leave alone (or at least restore) any hardware beam
position registers in the device which the interpreter might
concievably depend on.
This command really should not be used; it was included at level
o so that specific appl ications can do mode settin~ and other
device specific manipulations. For example, ARDS terminals may
optionally have several independently addressable output scopes.
The selection mechanism changes state only when a particular
sequence of ASCI I characters reaches the terminal. Thus ESCDEV
would be used to select which scope(s) is/are to be affected by
following commands. (The current state is invisible to the
graphics package at the Using Host.)
Further, suppose that another nake of terminal has a similar
option, which responds to a diferent code sequence. This
po s s l b l l ity is the motivation for conditionally ignoring the
ESCDEV command based on the "<value>" specified. Given that a
particular appl ication will only be used to output to either an
ARDS or this second make (with the multiple scope option), then
the appl ication could always send two ESCDEV commands, one
applicable only to ARDS terminals, and the other applicable only
to the second make.

-12­
LEVEL 1
*Set Line mode (ILINf.'IOn") <value>.
This command sets the current 1 ine mode; possible modes and the
<value> ....h l ch sets each are: sol id (0), dashed (1), dotted (2),
and others (3 or ». At the beginning of a new picture (i.e.,
after an Erase and Reset co~nand), 1 ine mode is sol ide If a site
does not have a certain mode readily available, it maya)
simulate it in software, b) substitute another in its place
(dashed for dotted, or vice versa) c) ignore it entirely. What
is provided should be clearly indicated in any publ ic document.
It is strongly recommend that at least sol id and one other mode
be provided.
*Set intensity (IISETINT II ) <value>.
This command sets the intensity of 1 ines, dots and characters
displayed following the command. If <value> is 128 decimal,
normal intensity should be set. If <value> is 255 decimal,
brightest should be selected, and if it is 0, then the beam
should be blanked. Intermediate values should be mapped
appropriately as the implementer sees fit. For instance, if
brightest is the same as normal, all values from 128 through 255
should be mapped to nornal. Information displayed between the
start of a new picture (the ERASE comnand) and the first SETINT
command appears at no rrna l intensity.
*Text out ("TEXTO") <strins;>.
Starting from the current beam position, this COmMand displays
the <string> (of net v.o r k ASCII characters) formatted as if it
we r e typed material (at the current intensity). <string>
consists of a <count> followed by count many characters. That
is, text extending past the ri~ht mar~in \"il 1 be broken and
repositioned at the left margin on the next 1 ine down. Of the
control characters, only carriage return, 1 ine feed, and
backspace are required to be interpreted properly.
*Subpicture header ("SUBIIED") <identifier> <count> <header info>.
This command begins the definition of a subpicture named
"<identifier>lI. This definition is terminated by a matching
SUBEND command. The definition will be remembered until a new
one is specified or until the graphics network connection is
broken. Note that <identifier> is a <string> consisting solely
of capital letters and numbers.
Subpicture definitions may be nested; this will be equivalent to
transmitting the two definitions separately. In other words, all
s ubp l c t u r e names are g l o ba l s and are "knm'm" to all other
subpictures. If a subpicture definition has not been received
prior to its use in a picture, the empty subpicture should be
displayed in its place until a definition is received.

-13­
A subpicture definition need not be transmitted as part of a
picture (i.e., within an ERASE and END command pair). Indeed,
all subpicture definitions might preceed the main picture.
Currently, the <count> will always be 1, indicating only one byte
of <header info> follows, but at higher levels of the protocol
room for expansion may be required. In the <header info>, the 80
hex bit will be set if this subpicture can be a simple
subpicture, and the 40 hex bit will be set if the subpicture can
be a full subpicture. (It is possible that one subpicture can be
both.)
Other information that may beven uall ~ be present in <header
info> include whether the current value of a certain mode or
parameter should be saved on entry to, and restored on exit from,
this subroutine whenever it is called. These modes and
para meters include: 1 ine mode, intensity, character size, and
data length.

*Subpicture end (IISUBEND II).

This command ends the definition of a subpicture. Each SUBEND

must match a preceeding SUBHED command.

*Simple instance (1IIUSTS") <identifier> <simple instance tail>

This command indicates that the subpicture <identifier> is to be

called (instanced>' At this level, level 1, no s ubp l c t u r e may

call another; if one does, what happens is left unspecified.

Also, this must be a call to a simple subpicture. Thus the 80

hex bit of the single byte of <header info> must have been set in

the SUBHED command which started the definition of <identifier> •

. If the subpicture <identifier> has never been defined, the empty

subpicture should be displayed in its place.

"The <simple instance tail> begins with a count of the amount of

information which follows. This count may be zero. If non-zero,

the next byte is a code byte to be interpreted to see what

further information follows. If the 30-hex bit is set, next in

the byte stream is an <identifier> (called liAS l nfo rrne t t on ") .

This <identifier> is the name of this particular instance of the

subpicture as described under Simple Subpicture Calls. If the

40-hex bit is set, then next in the byte stream (following the AS

information, if present) is an x,y position (in the calling

picture's coordinate scheme) at which the subpicture will be

centered. (This is called AT inforMation.)

If AT information is not specified, the current beam position is

used as a default. If AS information is not specified, it

defaults to the <string> containing zero characters. If neither

the 40 hex nor the 80 hex bits are set, then neither the AT

information nor the AS information is present, and the code byte

should be zero. (Also, the length count had better be 1.)

-14­
 /

Changes to level a commands for level 1.

TEXT and TEXTR -- Carria~e return, 1 ine feed and backspace
characters should definitelY be interpreted whenever they appear
In <string>. The results of other control characters remain
unspecified. The intensity of the characters shall be affected
by the SETItJT command.
ERASE -- Normal intensity and sol id 1 ine mode must be establ ished
at the start of a new picture.
DRAWA and DRAWR -- Line mode and intensity shall be affected by
the LINMOD and SETINT commands.
DaTA and DOTR -- Intensity shall be affected by the SElINT
command.

-15­
LEVEL 2
*1·lark ("I·:ARI~").

This comnand causes the current x,y bean position to be saved on

a pu s hdown s t ac l:.• This pus hdown stack r.1USt be separate f r om the

sub p l c t u r e call pu s h down stack.

*l·iove to nark and pop ("I·OV:::r :I~II).

This command sets the current be ar i position equal to the x,y

position at the top of t he "ria r l. " ou s hdov.n stack. If the stack

is empty, the o r l rt i n is u s e J, instead. Then the stack is popped

u p ( un 1e s s i t i s ernp t y ).

*Drav/ to ma r k and pop ("Dr:,\ \:'I:I'.").

If the "rna r k " pu s hdov.n s t ac l: is not erm t v , t h l s cormanJ ~Ira\"ls a

1 ine (of the current 1 ine l ' ~ode and I n t e n s i t v ) f r om the current

bean position to the ;<,'J position at the tor> of the "ma r k "

pu s h down s t ac l: , and sets the be art r>OS i t ion to that val UP.. Then

the stack is popped. If the s t ac k is crip t v , the 1 ine i~: d r av.n to

the ori~in and the bean position is set t~ere also.

Chanxe s to level U and 1 far level 2.

Ir!STS -- arbitrary levels of s Irnp l e s ubn l c t u r e s nu s t he

s u ppo r t e d , (Ilo t e that recursive use of s u b p i c t u r e s is not
a l Lowe d : once recursion starts, it can never be s t o ppe d ; ) The
pu s h down stack for s u b p l c t u r e calls rnu s t be kept separate fror.l
the "ma r k " pu s h dov.n stack.

-lG­
 ,
I

Leve 1 3
(Perhaps all rotational transformations should be put at a h l zhe r
level, for instance higher than viewport operations.)
*Full Instance ("ItJSTF") <identifier> <full instance tail>
This comnand indicates that the subpicture <identifier> is to be
called (instanced) in a "full II manner as described in an
explanatroy section. For one thing, this means that the 40 hex
bit of the single byte of <header info> must have been set in the
SUBHED command which started the definition of <identifier>. If
<identifier> has never been defined, the empty subpicture (i.e.,
nothing) should be displayed in its place.
The <full instance tail> is similar to the <simple instance tail>
described under the Ir~STS command, but the former contains more
information. Below is a 1 ist of the information which can be
specified, and the bit assigned to the presence/absence of each
piece of information . The pieces of information which are
present always appear in the byte stream in the order they are
described in this 1 ist. (All the pieces of information are
described more fully in Full Subpicture Calls, except for the liAs
l n f o rrua t l on " wh l ch is described in Simple Subpicture Cal l s , )
Bit(hex) Information
80 As inforrlation -- II namell of this particular
instance. Consists of an <identifier>.
40 Translation infor~ation -- Center of the
subpicture's image on the call ing page. Consists
of an <x coordinate> and a <y coordinate>.
20 Rotation -- Fractional part of 2pi to rotate the
image counterclockwise. Consists of a 16-bit
unsigned fraction.

10 Portion Infornation -- Rectangular part of

s ubp i c t u r e vrh l c h is to be displayed. Consists of
<x coordinate>, <y coordinate>, <x delta), and <y
delta>.
8 Uniform ~agnification -- Amount to scale the whole
subpicture. Consists of a floating point number
(which should not be zero).
4 Separate x and y mar,nification -- Separate scales
for the x and y axes of the subpicture. Consists
of two floating point numbers (neither of which
s hou 1 d be ze ro ) •
2 Image Size -- How large a rectangle on the calling
page is the ima~e to occupy. Consists of an <x
delta> and a <y delta) (neither of which should be

-17­
 ze ro ) •

1 Affine transformation -- The map from the called

to the call ing coordinate system. Consists of six
floating point numbers.
No t e s :
1) At most one of the three bits: 8, 4, and 2, should be set.

2) 1ft he 1 bit iss e t , bit s 2 , l~ , 8, 2 0, and l~ 0, s h0 u 1 d not be

set.

3) If additional optional parameters are ever added to the full

subpicture call, another code byte could follow all the above

information. In that case, the <count> part of the <full

instance tail> would include this second code byte and any

additional bytes of information.

* Escape to top level coordinate system ("ESCTOp").

Until a RES LEV co~and is (subsequently) executed, all display
commands (moves, draws, dots, and texts) shall operate as if they
were issued by the top level (main) picture instead of the
subpicture containing them. That is, they shall be mapped to the
screen according to the map for the highest level. Subpicture
calls themselves, which are made while an ESCrap command is in
effect, are not affected by the command. That is, transformations
are calculated as if the command were not in effect. The
calculated transformations are ignored, however, and information
displayed by the subpicture still appears to be at the top level,
until a RESLEV command null ifies the [SCTap mode. Thus a
subp l c t u r e call executed wh l l e an ESCTap command is in effect,
,acts as if a RESLEV were executed inmediately before the call,
and an ESCTap command were executed as the first command of the
subpicture. Similar considerations hold for returning from
subpictures.
*Resurne current level coordinate system ("RESLEV").

This command restores the logical coordinate system corresponding

to the subpicture currently executing, in case that coordinate

system was disabled by an [SCTap command. (See ESCTap.)

Changes to levels 0, 1, and 2 for level 3.

MARK -- the saved beam position shall be in terms of the logical
coordinate system, not the physical coordinate system.
TEXTR, TEXT, TEXTO -- Since a full subpicture is supposed to be
transformaed as a whole, as if it were a picture in its own
right, it appears to this author that, in particular, all beam
movements related to characters should be affected. This
includes character size, tab, carriage return and 1 ine feed. In
particular, carriage return should set the beam to the left
margin-- that is, to the left edge of the logIcal coordinate

-18­
~1 .
system of the called subpicture. All these chan~es may be very
hard to accoMplish, and what should be done will be left
unspecified at this time, with comment from readers particularly
invited.

-19­
 --- - ---~

Leve 1. 4
(Perhaps v l ewpo r t operations can he included in . level 3.)

*Declare Viewport

("SETV\~lI) <v l ewpo r t l d > <x coordinate> <v coordinate> <x delta>

<y delta>

Set the viewport identified by <viewport id> to represent the

indicated area of the logical screen. The x and y data are not

physical screen coordinates, since that would involve device

dependencies. This command completely superceeds any previous

declaration of the same viewport. If information is already

displayed within the viewport specified, this command causes the

displayed information to be relocated on the screen to its new

position.

If the area specified exceeds the I imits of the graphics standard

display screen, what happens is left unspecified. Viewports need

not he disjoint; iri other words, two viewports can present

display information at the same point on the screen.

If <x delta> or <y delta> are negative, the viewport named should

be deleted. All information displayed by it shall no l on ge r

appear.

Because it affects the top level picture, this author feels that

J this command should not occur as part of a picture or in a

subpicture declaration.

*AJd su bp l c t u r e to v l ewpo r t ("ADDSV\-1") <identifier> <v l ewpo r t l d >

The subpicture named <identifier> is displayed within the
viewport specified, if it is not already displayed there. (If .it
is, nothing is done.) The subpicture "must be capable of being
~alled via a full subpicture call. If the viewport has never
been declared .Y-La a SETV\i command v/hat happens is left
unspecified. (Three possibilities are: no t h l ng is displayed;
the viewport defaults to the who l e logical screen; the human
v l ewe r is permitted by the Using Host to specify the v l ewoo r t . )
If the viewport is subsequently declared, the subpicture shall be
displayed in it. If the subpicture has never be declared,
nothing is displayed for it; -whe n and if it is subsequently
declared, the new definition is displayed in the v i ewpo r t , nore
than one subpicture may be displayed in a single viewport at
once.
Because it affects the top level picture, this author feels that
this command should not occur as part of a picture or in a
subpicture declaration.

*Clear viewport (IlCLV\"I") <viewport id>

All subpictures which have been added with the ADOSVW comMand to

-20­
 I

the viewport specified in this co~mand are removed from it. Thus
the specified viev/port contributes nothing to what the human
viewer sees. (After a CLVW, the area of the viewport may not be
blank due to other, non-cleared viewports which overlap it.)
Because it affects the top level picture, this author feels that
this command should not occur as part of a picture or in a
subpicture declaration.

Changes to levels 0, 1, 2, and 3 for level 4.

ERASE -- All viewports are cleared (as in the CLVW command) but
their declarations a r e r ernernbe r e d ,
ENDPIC -- This command partially loses its purpose: it no longer
serves to mark the end of all picture information to be presented
to the user, since vicv/port operations may follow which amend or
alter the picture. This function is partially taken over by the
DELAY and NODELAY connands described below.

-21­
 I
I

( -.\ . Leye 1 ?

*Set Character Sizf! (IISETCHS II) <x delta> <y delta>.

Until further notice, characters shall be displayed so that each
occupies approximately <x delta> and <y delta> in the appropriate
coordinate direction in the current logical coordinate system.
Inter-character and inter-l ine spacing could be certain
percentages (any ideas?) more than <x delta> and <y delta>, or
they could be specifif!d separately. In any case, only a IIbest
e f f o r t " wou l d be expected at a site. Character size is always
set to normal (as defined by level 0 character size being normal)
by the ERASE comman d , <x del ta> and <y del ta> should be
positive, except that if <xdelta> is equal to zero, then <y
delta> being negative, zero, or positive, correspond to a
character size wh l c h is "sraa l l e r than normal", "normal," or
"larger than no rrna l ;." How much srna l l e r or larger than normal is
left up to the site.
Changes to levels 0 and 1 for level ?
TEXTR, TEXT, and TEXTO -- Characters are to be displayed
according to the current character size.
ERASE -- Must establ ish normal character size, normal being that
for level O.

-22­
 / '-: .:,9

Leve 1 ? I

*Set Data Length ("SETDLN") <value>.

Until this mode is expl icitly changed with another SETDLN,

various data will consist of <value> number of bytes. <value> may

be 1, 2, 3, or 4. Affected are the following syntactic types

(refer to Appendix 1): <coordinate>, <x coordinate>, <y

coordinate>, <double coordinate>, <x delta>, <v delta>, <ang l e >,

and the fractional part of a floating point number. When a

network connection is initially establ ished, the data length is

two.

Leve 1 ? I I
(These com~ands should probably be at the same level as viewport
ope rat ion s, if no tea r 1 i e r • )
*Extens ive Changes Fo l l ow ("DELAY").
This optional command is designed to el iminate futile effort on
the part of the Usinr, Host pror,rams. At some hosts and/or with
some output devices (particularly storage tubes) a non-neg] igible
amount of time may be required to present an ima~e to the human
. viewer. If extensive changes are going to be made, this cOr.lmand
wou l d be used to prevent the Us l nz Host graphics package from
updating the image after every chan~e. A NODELAY command exits
from the DELAY mode and causes the iMar,e to be prepared and
presented to the viewer.
For example, the current picture may display four subpictures
each of which is ~oinr, to be redefined. Without a DELAY command,
the viewer would see successive stages of the change, each
possihly involving a large amount of computation or transmission
time.

*End of Extensive Changes ("NODELAY")

This optional co~mand undoes the effect of the DELAY command.

-23­
 I

'-\
. .. Appendix 1: BNF for the Graphics Protocol Byte Stream
Key to below:
Non-terminals are represented in < >.
Terminals which are keywords standing for particular eight-bit
values are in capitals.
Terminals whose meaning should be clear to the reader are in
lower case. Note that "empty_string" means "zero bytes," not "a
<s t r i n g > \'J h0 s e <co u n t > i s z e r 0 • II

<graphics output byte stream> ::= empty_string

I (picture> <graphics output byte stream>
I <subpicture declaration> <graphics output
byte stream>

I <viewport operatIon> <graphics output byte

stream>

I <transmission control stt> <graphics output

byte strearl>

<picture> ::= <new picture stt> <program stt group> <end picture
stt>
<subpicture declaration> ::= <subpicture header stt> <program stt
group> <subpicture end stt>
<viewport operation> ::= <declare viewport stt>

I <add subpicture to viewport stt>

I <clear viewport stt>

<transmission control stt> ::= <set data length stt>

I <extensive chan~es follow stt>

I <end of extensive changes stt>

<program stt group> ::= empty_string I <pro~ram stt> <prograM stt

group>
<program stt> ::= <picture control stt> I <display stt>
<transmission control stt>
<picture control stt> ::= <escape to device stt>
I <escape to highest coordinate system stt>
I <restore coordinate system stt>
I <mark stt>
I <null stt>
I <line mode stt>
I <set intensity stt>
I <subpicture declaration>
I <siMPle instance stt>
I <full instance stt>
I <set character size stt>
<display stt> ::= <move absolute stt>

I <move relative stt>

I <draw absolute stt>

I <draw relative stt>

I <dot absolute stt>

I <dot relative stt>

I <move to mark and pop stt>

I <draw to Mark and pop stt>

-24­
 <text and re5tore beam stt>

<text stt>

<text out stt>

<new picture stt> ::= ERASE

<end picture stt> ::= ENDPIC
<subpicture header stt> ::= SUBHED <identifier> <count> <header info>
<header info> ::= aO-hex I 40-hex I CO-hex
<subpicture end stt> ::= SUBEND
<set viewport stt> ::= SETVW <viewport id> <x coordinate> <y
coordinate> <x delta> <y delta>

<add subpicture to viewport stt> ::= ADDSVW <identifier>

<v ewpo r t
l l d >

<clear viewport stt> ::= CLVW <viewport id>

<extensive changes follow stt> ::= DELAY

<end of extens ive changes s t t > ::= r~ODELAY

<escape to device stt> ::= ESCDEV <device code> <string>

<escape to highest coordinate system stt> ::= ESCTOP

<restore coordinate system stt> ::= RES LEV

<null s t t > ::= IlULL

<mark stt> ::= MARK

<line mode stt> ::= L1t~I~OD <value>

<set intensity s t t > ::= SETIIJT <value>

<set character size stt> ::= SETCHS <x delta> <y delta>

<set data length stt> ::= SETDLN <value>

<move absolute stt> ::= MOVEA <x coordinate> <y coordinate>

<move relative stt> ::= MOVER <x delta> <y delta>

<draw absolute stt> ::= DRAWA <x coordinate> <y coordinate>

<d r a v, re 1 a t i ve s t t > :: = DRA\1 R <x del t a > <y del t a >

<dot absolute stt> ::= DOTA <x coordinate> <y coordinate>

<dot relative stt> ::= DOTR <x delta> <y uelta>

<move to mark and pop stt> ::= NOVEMK

Cd r aw to rna rk and pop s t t > :: = DRA\'IHK

<text and restore beam stt> ::= TEXTR <string>

<text stt> ::= TEXT <string>

<text out stt> ::= TEXTO <string>

<simple instance stt> ::= II:STS <identifier> <simple instance

ta i 1 >
<full instance stt> ::= It!STF <identifier> <full instance tall>
<simple instance tail> ::= eig!"lt_bits_of_binary_O
I <count> <tail code> <as clause> <at clause>
<tail code> ::= bi.t pattern indicating: what clauses follow
<full instance tail> ::= eip,ht_bits_of=binary_O ­
I <count> <tail code> <as clause> <at clause>
<rotation clause> <portion clause> <uniforM
magnification clause> <separate magnification
clause> <ima~e size clause> <complete
transfornation clause>
<as clause> ::= er.1pty_string I <identifier>
<at clause > ::= empty_string I <x co o r d I na t e > <v coordinate>
.~ <rotation clause> ::= empty_string I <angle>

-25­
- ..­

<portion clause> ::= empty_string I <x coordinate> <y coordinate>

<x delta> <y delta>
<uniform magnification clause> ::= empty_string I <floatinF, point
number>
<separate magnification clause> ::= empty_string I <floating
point number> <floating point number>
<image size clause> ::= empty_strin~ I <x delta> <y delta>
<complete transformation clause> ::= empty_string I six_<floating
point number>'s
<angle> ::= 16-bit_non-negative_fractional_part_of_a_circle

<x coordinate> ::= <coordinate>

<y coordinate> ::= <coordinate>

<x delta> ::= <double coordinate>

<y delta> ::= <double coordinate>

<coordinate> ::= signed,_two's-complement,_fraction_in_range

-1/2 to less than +1/2

<double coordinate> ::= si~ned,_two's=complement,_fraction,
range_strictlY_between_-l_and_+l
<floating point number> ::= network_standard_floating_point
numbe r_i f _any
I 8-bit_two's_complement_exponent_part and a
16-bit_two's_complement_fraction_part <count>
::= 7-bit_non-negative_integer
I 15-bit_non-negative_integer_represented_in
"excess_2**15"_notation
<string> ::= <co~nt> count_8-bit_bytes
<identifier> ::= <count> count_upper_case_letters_or_numbers
<v l ewpo r t l d > ::= <identifier>
<device code> ::= 8-bit_integer
<value> ::= 8-bit_integer

-26­
 Appendix 2. Mathematical Eor~ulae for Subpictures
Transforr:1ations
In this appendix positions in a logical coordinate system will be
represented by a row vector with two elements, as in L x y_I.
Vectors and matrices will be del imited by these funny brackets:
L _I. various symbols will be used to represent parameters in a
full subpicture call relating to a transfor~ation from one
coordinate system to another; these are defined below:
Mx and My : magnifications in x and y to be appl ied before
any rotation. They may be negative indicating
reflection.
8 an angle of rotation in the range 0 to just less than
2p i .
L Icx Icy_I: the center (in the calling picture) of the
image of the suhpicture.
Isx and Isy : the half-sizes, in the x and y directions, of
the image on the call ing page in terms of the
call ing page's coordinate system. They may be
negative to indicate reflection.
L x y_1 : a position on the called page.
L Ix ly_/: the position on the call ing page corresponding
to L x y_l.
L Pcx Pcy_l: The center of the portion of the called
subpicture's coordinate system which is to he
mapped to the call in~ par,e. This defaults to L 0
0_1 if not specified.
Psx and Psy : The half-sizes in x and y of the portion of
the subpicture to be mapped. These both default
to +1/2 in not specified.
(.i a uniform magnification is specified, s~t Mx and My equal to
it and proceed below as if they were specified.)

If maenifications are specified, the following holds:

L Ix ly_1 = (L x y_1 - L Pcx Pcy_/) * I Mx/Psx a I *
L 0 My/Psy_1

I cos 8 I 1/2 o I + L I ex
L -sinS L 0 112_1
or, in other words,
1)
Llx ly_1 = L x-Pcx y-Pcy_1 * I t ~x cos8/2Psx t1x sin8/2Psx I
L -My sin8/2Psy My cos8/2Psy_1
+ L Icx Icy_I

-27­
(The factor of 1/2 is necessary because, for instance,
(x-Pcx)/Psx ranges from -1 to +1 for x values within the portion
( 1. e ., s uc h t hat I x- Pcx I < IPs x I ) \'J her e as the image , i nth e
call ing subpicture's coordinate system, should only range from
-1/2 to +1/2.)
If the image size is specified instead of the magnification, we
have the following:
L Ix ly_1 = (L x Y_I - LPcx Pcy I) * / I/Psx 0 / *
L 0 11 Psy _I

I cos8 sin8 ' 1 * 1 Isx 0 I + L Icx

L -sinS cose _I L o Isy_1
or, in other wo r ds ,
2)
Llx ly_1 = Lx-Pcx y-Pcy_1 * Ilsx cosS/Psx Isy sin8/Psx I
L-Isx sin~/Psy Isy cosS/Psy_1

Expanding the parenthesized quantities in equations 1) and 2), we

have:
3a) Llx ly_1 = Lx y_1 * /Mx cos8/2Psx I'lx sinS/2Psx I
L-~iy s inS/2Psy r.1y cosS/2Psy_1
+ Llcx-PcxNxcos8/2Psx+PcyMysinS/2Psy
Icy-PcxMxsin8/2Psx-PcyMycosS/2Psy _I
and
3b) Llx ly_1 = Lx y_/ * Ilsx cos8/Psx Isy sin8/Psx I
L-Isx sin8/Psy Isy cos8/Psy_1
+ Llcx-Pcxlsxcos8/Psx+Pcylsxsin8/Psy
Icy-Pcxlsysin8/Psx-Pcylsycos8/Psy_1
Various interesting substitutions can be made in 3a) and 3b).
For example, if 8=0 (no rotation), then we have:
4a) LI x Iy_/ = Lx v.J * /t.1x/2Psx 0 I + Llcx-PcxMx/2Psx
ICy-Pcyf.iy/2Psy_/
L 0 My/2Psy_1
4b) Llx Iy_/ = Lx y_1 * 1 I sxl Psx 0 I + Llcx-Pcxlsx/Psx
Icy - Pcy I s vt» s y_/
L 0 I syl PsY_I

-28­
 .... .
•

1
. .· Another example is if no portioning is done (Pex~Pey=O,
Psx=Psy=1/2):
Sa) Llx Iy_/ = Lx y_/ * /Mx eosS Mx sinS / + Llex

L -t-1y s l ns My sln9_1

Sb) Llx Iy-' = Lx y_1 * 121sx cosS 21sy sinS I + Llcx Icy_I
L-2lsx sinS 21sy eosS_1
If, in addition, 6=0, we have:
6a) LI x I v.:' = L x~'ix+ Iex yMy+ Icy_I
6b) Llx IY_I =L x*2Isx+lcx y*2Isy+lcy_/
Of course, in all cases, the t r ans f o rma t l on from Lx y_/ to Llx
ly_1 can be written in the form:
Llx ly_1 = Lx y_1 * I 2 by 2 I + L translation _I
L mat r i x _I
In general, a transformation combinin~ a linear transformation
and a translation is called an affine transformation.
Transformations \\Iith I!ested Levels
The combination of two affine transforMations is again an affine
transformation. Indeed, if
Llx Iy-' = Lx y_I * I MatI / + L TranI _I

L _I

and
Llx' ly'_1 = Llx ly_1 * I Mat2 I + L Tran2 _I
L _I
then
Llx' I y'_1 = Lx y_1 *( I MatI I * I Mat2 I)
L _I L _I

+ (L Tran2 _I + L TranI I * / Mat2 /)

L _I
Thus if one has nested full subpicture calls, the data at any
level need be transforned only once, namely, by the
transformation whicll is the conbination of the single step
transformations at each level of nesting. A new "grand
combination l ' affine transformation should be computed whenever a
full subpicture is called (after pushing down the current
transformation) by combining the current ~rand combination with

-29­
-.

the affine transformation for this particular subpicture call.

Portions with Nested Levels

As long as no rotations are involved, or even only rotations in
multiples of pi/2, then multiple levels of portions are easy to
implement. In the discussion in the next two paragraphs let us
assume that no rotations other than whole multiples of pi/2 are
involved.
Just as one can keep track of " a "grand combination" affine
transformation, so can one keep a p,rand combination of portions.
At each level, one can proceed as follows: Save a copy of the
current grand portion, and use the inverse of the single level
affine transformation (specified in the subpicture call) to
determine what rectangle of the called page corresponds to the
current grand portion (on the call ing page).
Various relations may exist between this rectangle and the
rectangle specified (or defaulted) in the subpicture call. They
may be disjoint (in which case this subpicture need not be called
at all); they may be equal (an easy case); one may contain the
other or thwy may partially overlap. If there ~ any
intersection, it will be a rectangle, and this rectangle becomes
the new grand combination portion.
The problem with rotations other than multiples of pi/2 is that
the inverse image of the rectangle is no longer in the standard
orientation (vertical and horizontal edp,es). This means that its
Intersection with the portion specified on the subpicture call
may have 3, 4, 5, 6, 7, or 8 edges (if it is non-empty). Deeper
levels may get even worse if they involve rotations too. While
there may be no conceptual difficulty (for some) in working with
such a situation, si~nificantly more computation is involved than
In the simple horizontal and vertical edge case.
This protocol puts forward no recommendation in the case that
rotations other than whole multiples of pi/2 are involved with
portions. It does suggest that nested portions be handled as
described above in the more str~ightforward case.

-30­