RFC191 Graphics implementation and conceptualization at AugmentationResearch Center

0191 Graphics implementation and conceptualization at AugmentationResearch Center. C.H. Irby. July 1971. (Format: TXT=8179 bytes) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

RFC 191                                             Charles Irby
NIC 7136                            Augmentation Research Center
Category D.6, I.1                    Stanford Research Institute
                                                       13-JUL-71

          GRAPHICS IMPLEMENTATION AND CONCEPTUALIZATION AT ARC

Overview:

This document is a brief description of the way in which graphics
terminals are conceptualized and used at the Augmentation
Research Center. All things described are implemented and have
been operational for several months. Although our attention has
initially been centered about the display of textual material, we
are now about to turn our attention toward pictorial displays
(hopefully much enhanced over our previous 940 line drawing
capabilities).

   This document will discuss only those facits of display use
   which have been implemented and are currently operational,
   namely only those dealing with textual display.

included is a discussion of the use of multiple file viewing
display areas in NLS to provide cross file editing capabilities.
A description of our display and terminal input equipment will
be issued as a separate document.

NOTE: RFC 190 includes a functional description of the
implementation of the interface to our displays and is a
description of the way this interface was extended to include
"Processor-displays" (an IMLAC PDS-1, in this case) to our
system, thus enabling one to use Display NLS over any of our
teletype lines (including the network).

   A "processor dsplay" is a display with Processing power which
   can be controlled by character strings.

Description of the "conceptual display" implemented at ARC

The allocatable output unit for our display terminals (which
include our local terminals and all remote processor-displays) is










                                                                [Page 1]

a rectangular "display area". A program treats this display area
much like it would a file which it has opened with write access.

When requesting the allocation of a display area, a program
specifies its attributes, including where it is to be on the
screen. The program is returned an identifier which it
subsequently uses to manipulate images within the display area
and the display area itself. Each string which the program
writes into the display area is also given an identifier, which
can subsequently be used to move, delete, replace, or change the
characteristics of that string.

   The currently implemented characteristics are character size,
   horizontal spacing between characters, and font of the
   characters (e.g. blinking, italics, intensity, etc.).

   The position of items in the display area are given relative
   to the 0,0, which is the lower left corner of the display
   area.  The horizontal coordinate increases to the right and the
   vertical coordinate increases toward the top.

In addition to above described manipulation of strings within
display areas a program can suppress the display of individual
strings within display areas or suppress whole display areas.

Also, a program can switch the terminal's state from teletype
simulation to display mode and vis versa.

   When in display mode, the teletype simulation display area is
   suppressed and the coordinates of the cursor are input with
   each character. When in teletype simulation mode, all user
   owned display areas are suppressed and the coordinates of the
   cursor are not input with each character.

At TENEX startup time, display areas are allocated for a teletype
simulation and a cursor for each local display terminal. Programs
can change the string being displayed as the cursor to give the
human feedback as to the programs state.

Within NLS:

   The NLS subsystem deals only with the cursor and the display
   areas it has requested from the system for output to the user.
   The display area formatters assumes that the display has 64K
   by 64K addressable points (with 0,0 at upper left), several
   different character sizes and fonts, and 7-bit ASCII.





                                                                [Page 2]

   The display area formatters use format parameters during the
   format process and post-processors to convert the vertual
   format to one that is acceptable to the device for which the
   formatting was being done (a display area on the screen, a
   page for a printer, a microfilm device, or a teletype).

   NLS allows the user to specify arguments to commands by
   selecting items from the current display image. This is
   accomplished through the use of a data structure, which
   describes the current display image, to map the cursor
   coordinates, which are input with each character, into the
   proper selection.

Multiple text display areas in NLS

When the user's device is a display, NLS allows him to subdivide
the file-viewing display area (the one in which he views his
file) and view (and edit across) several different files at once.
Following is a discussion of the commands and capabilities
associated with this new feature.

  new commands

    Horizontal split

      splits a file-viewing display area horizontally (into an
      upper and lower segment) at the selected location moving
      the image of the original display area to the upper or
      lower segment depending on whether the cursor is above or
      below the bugged position when the final Command Accept is
      input.

         No display area will be created which is smaller then 2
         lines by 20 columns (using the character size of the
         original display area).

    Vertical split

      splits a file-viewing display area vertically (into a left
      and right segment) at the selected location moving the
      image of the original display area to the left or right
      segment depending on whether the cursor is to the left or
      right of the selected position when the final CA is input.

         No display area will he created which is smaller then 2
         lines by 20 columns (using the character size of the
         original display area).



                                                                [Page 3]

    Move boundary

      The selected boundary is moved to the new position. A
      boundary will not be moved passed a boundary of a neighbor.
      A boundary is moved for all display areas for which it is a
      boundary. Any resulting display area which is smaller than
      two lines by twenty columns will be deleted.

    Character size

      The current character size of the display area which
      currently contains the cursor is displayed, and the user
      may type a number (0, 1, 2, 3) for a new character size.
      The final Command Accept causes the character size to be
      changed. The horizontal and vertical increment are
      automatically adjusted. Different display areas may
      simultaneously have different character sizes.

    Clear display area

      The selected display area is cleared, i.e. the image is
      erased, the return and file return rings are released, and
      the association of a file with that display area is
      removed. The display area itself is not deleted.

One may freely edit and jump using several display areas. The
position of the cursor is used to resolve ambiguities.

   For example, If one executes a Jump command, the position of
   the cursor when the final Command Accept is entered determines
   in which display area the new image is to appear.

   Also, If one changes viewspecs using the leftmost two buttons
   of the mouse, the viewspecs of the display area containing the
   cursor when the buttons go down are used as the initial values
   and are displayed in the viewspec area. When the buttons are
   released, the display area containing the cursor receives the
   new viewspecs.


       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]







                                                                [Page 4]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

GREATEST関数 引数のうち最大値を返す

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る