RFC 191

RFC 191 ✨ Graphics Implementation and Conceptualization at ARC

Okay bestie, the title block 🎀 says this was written by Charles Irby (NIC 7136) at the Augmentation Research Center, Stanford Research Institute, dated 13-JUL-71. It's filed under Category D.6, I.1 (no idea what those codes mean, but they're giving mystery 💀). It doesn't list anything it obsoletes or updates. 🫶

Overview 🦋

So this doc is a quick tour of how graphics terminals are conceptualized and used at ARC. Everything in here is implemented and has been running for several months ✨. We started out focused on displaying text, but now we're about to turn our attention to pictures (hopefully way upgraded from our old 940 line drawing capabilities 👀).

This document only covers the stuff that's actually implemented and operational right now, which means the text display stuff. Nothing else. Just text 💅.

This doc also includes a discussion of using multiple file viewing display areas in NLS for cross file editing 🌈. A description of our display and terminal input equipment will come out as a separate document 📄.

NOTE: RFC 190 has a functional description of how the interface to our displays was built, and how that interface got extended to include "Processor-displays" (an IMLAC PDS-1, in this case) so you can use Display NLS over any of our teletype lines (including the network) 🧚.

A "processor display" is a display with processing power that can be controlled by character strings 🤖.

Description of the "Conceptual Display" Implemented at ARC 🌸

So the allocatable output unit for our display terminals (which covers our local terminals and all remote processor-displays) is a rectangular "display area" 🪟. A program treats this display area kind of like a file it opened with write access 📁.

When a program requests a display area, it specifies its attributes, including where it goes on the screen. In return, it gets an identifier, which it uses to manipulate the images inside the display area and the display area itself 🧠. Every string the program writes into the display area also gets its own identifier, so it can later 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.) ✍️.

Positions of items in the display area are given relative to 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 🆙.

On top of all that string manipulation, a program can suppress the display of individual strings, or suppress whole display areas 🙈.

A program can also switch the terminal's state from teletype simulation to display mode, and vice versa ⚡.

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

At TENEX startup, display areas get allocated for a teletype simulation, plus a cursor for each local display terminal 🖥️. Programs can change the string being displayed as the cursor, which gives the human feedback about what the program is doing 🫶.

Within NLS 💅

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

The display area formatters use format parameters during the format process, plus post-processors to turn the virtual format into one the target device can accept. That target could be a display area on the screen, a page for a printer, a microfilm device, or a teletype 🖨️.

NLS also lets the user specify command arguments by selecting items from the current display image 👆. This works through a data structure that describes the current display image, which maps the cursor coordinates (input with each character) to the right selection 🎯.

Multiple Text Display Areas in NLS 👑

When the user's device is a display, NLS lets them subdivide the file-viewing display area (the one where you look at your file) and view, and edit across, several different files at once 💖. Here are the commands and capabilities for this new feature 🎀.

New Commands ✨

Horizontal split

Splits a file-viewing display area horizontally (into an upper and lower segment) at the selected location. The image of the original display area moves 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 that is smaller than 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. The image of the original display area moves 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 be created that is smaller than 2 lines by 20 columns (using the character size of the original display area) 🙅.

Move boundary

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

Character size

The current character size of the display area containing the cursor is displayed, and the user can type a number (0, 1, 2, 3) for a new character size 🔠. The final Command Accept makes the change. The horizontal and vertical increments are adjusted automatically. Different display areas can have different character sizes at the same time 🌈.

Clear display area

The selected display area gets cleared, aka 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 can freely edit and jump using several display areas. The position of the cursor is used to resolve ambiguities 🧭.

For example, if you run a Jump command, the position of the cursor when the final Command Accept is entered decides which display area the new image shows up in 🦘.

Also, if you change 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 they're 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   ]