RFC 181 UNKNOWN GRAPHICS · ARPANET

Modifications to RFC 177

A revision to how coordinate areas work in the network standard graphics display list proposal.

On rfc-editor.org ↗
PUBLISHED
July 1971
AUTHORS
J. McConnell
STREAM
Legacy
BUILDS ON
RFC 177 — Device independent graphical display description
COORDINATE FORMAT
16-bit unsigned normalized fractions
AREA NAME
16-bit integer
NEW MODE STACK ITEMS
Types 14 to 17
DOI
10.17487/RFC0181

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
                         NETWORK WORKING GROUP

                        REQUEST FOR COMMENTS 181

                               NIC #7124

                             JUNE 27, 1971



                            JOHN Mc CONNELL


                          AMES RESEARCH CENTER

                        MOFFET FIELD, CALIFORNIA



                       MODIFICATIONS TO RFC #177




CATEGORY  D.6
RFC's Obsoleted  none
RFC's Updated    177

                      MODIFICATIONS TO RFC #177

    This RFC is intended to modifiy the proposal for a device
independent graphical display description discussed in RFC #177.  Thanks
are due to Stan Mantiply of Ames for his ideas.  The main changes are in
the defini- tion of coordinate areas to avoid one problem encountered
with the old definition and to provide more flexibility.  Terms used are
those defined in RFC #177.

    The problem encountered in the previous proposal was that the areas
of the NGS (network standard graphics screen), which were supposed to be
absolute boundaries, could be crossed when a list was executed within
that space.  Scaling of lists was also awkwardly done with specific
commands in the network standard graphic display list (NGDL).

    Coordinates will still be defined with 16 bit unsigned normalized
fractions.  This will leave the resolution of the picture up to the de-
vice which eventually receives the NGDL.  The values will not now be
tied to the NGS or an area of the screen, but will be fractional
displace- ments from the lower left corner of the screen, an area, or an
image space.

    Areas will still be rectangular and will be allowed to overlap, but
not contain another area completely.  The attributes of an area are: its
16 bit integer name, by which it may be manipulated, two (x,y) pairs
which will define its lower left and upper right corners with respect to
the NGS.  No list executed in an area may cross its boundaries.  Within
an area may be any number of image spaces which are dynamically defined
with the execution of a list and define its relationship to the contain-
ing area.

    The list item types 7 and 8 shall be changed from EXECUTE LIST
(Name,x,y) and COPY LIST (Name,x,y) to EXECUTE LIST
(Name,(Xl,Yl),(Xr,Yr)) and COPY LIST (Name,(Xl,Yl),(Xr,Yr))
respectively.  The coordinate pairs (Xl,Yl) and (Xr,Yr) define the image
area of that list as displacements from the lower left corner of the
containing area.  If the list executes other lists within it, their
image areas are defined as displacements from the image area of the list
containing the execute command.  Thus each list can be scaled
differently each time it is executed and may even be distorted if the
image area defined has different ratios of X and Y lengths.  Lists
executed within other lists will have the same relationship to their
containing lists regardless of that lists's rela- tionship to the NGS
area.  Since the initial image area is defined rela- tive to the NGSD
area, no overlaps can occur.

If a table (item type = 9) is executed, the coordinate pairs it
contains are relative to whatever area is valid at the time of its exe-
cution.

    A change to the NGLI is implied.  Whenever an EXECUTE LIST command
is encountered, the current state is saved, a new current origin is com-
puted, NGLP is reset to zero, and new X and Y scale factors must be cal-
culated to transform the coordinates in the new list to actual screen
coor- dinates.

    Another construct for graphics processing will be added.  This is
the mode stack for each graphics mode.  It will be used for saving and
restoring character and vector mode values as lists are recursively exe-
cuted.  Four new list items will be added to handle these operations.

   PUSH CHARACTER MODE    (item type = 14)
   PUSH VECTOR MODE       (item type = 15)
   POP CHARACTER MODE     (item type = 16)
   POP VECTOR MODE        (item type = 17)

    The DEFINE LIST command (type = 1) shall have its parameters
changed.  It shall have two parameters, a 16 bit integer name, by which
it may be manipulated and referenced, and a 16 bit integer defining the
length of the list in bytes rather than items.  This change is intended
to make processing the NGDS easier and will eliminate the TABLE item
(type = 11).

    The first three list items should have the WORD IMAGE eliminated
from them, since they are defining NGS areas now.

    The list command DEFINE IMAGE ARE (type = 2) shall be changed to
DEFINE AREA for the same reasons.


       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Gert Doering 6/97 ]

AI ELI5

On this page
PROBLEMIn the graphics proposal of RFC 177, areas of the network standard graphics screen were meant to be absolute boundaries but could be crossed by an executing list, and scaling was awkward.
MECHANISMCoordinates become 16-bit unsigned normalized fractions measured from the lower left corner of an area or image space, and EXECUTE LIST and COPY LIST take two corner points that define the image area.
WHAT CHANGESThis lets each list be scaled differently on each execution. It also adds mode stacks and changes DEFINE LIST. It updates RFC 177.

§1The Problem with RFC 177 Areas

This RFC modifies the proposal for a device-independent graphical display description in RFC 177, using its terms. The earlier problem was that areas of the NGS (network standard graphics screen), meant to be absolute boundaries, could be crossed when a list ran inside them. Scaling of lists in the network standard graphic display list (NGDL) was also awkwardly done with specific commands.

Pictures could spill out of their frames, and shrinking them was clumsy.

§2Areas and Relative Coordinates

Coordinates stay 16-bit unsigned normalized fractions, leaving resolution to the receiving device. They are now fractional displacements from the lower left corner of the screen, an area or an image space.

Areas stay rectangular and may overlap but not completely contain another area. An area has a 16-bit integer name and two (x,y) pairs for its lower left and upper right corners with respect to the NGS. No list executed in an area may cross its boundaries.

Positions are now measured as a fraction of the frame, so the same picture fits any frame size.

§3Execute List, Scaling and Mode Stacks

List item types 7 and 8 change to EXECUTE LIST (Name,(Xl,Yl),(Xr,Yr)) and COPY LIST (Name,(Xl,Yl),(Xr,Yr)). The two pairs define the image area as displacements from the lower left corner of the containing area, so each list can be scaled differently each time and can even be distorted if the X and Y ratios differ. Tables (item type 9) are relative to the area valid when they run.

Executing a list saves the current state, computes a new origin, resets NGLP to zero and calculates new X and Y scale factors. A mode stack is added for each graphics mode, with PUSH CHARACTER MODE (14), PUSH VECTOR MODE (15), POP CHARACTER MODE (16) and POP VECTOR MODE (17).

Each time you stick a picture into a frame you say how big, and the computer remembers your old pen settings so it can go back to them.

§4Other Changes

DEFINE LIST (type 1) now takes a 16-bit integer name and a 16-bit length in bytes rather than items. This eases processing and eliminates the TABLE item (type 11). The first three list items drop the WORD IMAGE, since they now define NGS areas, and DEFINE IMAGE ARE (type 2) becomes DEFINE AREA.

A few commands get new names and simpler settings to make the rulebook tidier.

§5References