Browse Prior Art Database

Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream (RFC0125) Disclosure Number: IPCOM000002066D
Original Publication Date: 1971-Apr-18
Included in the Prior Art Database: 2000-Sep-12
Document File: 3 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. McConnell: AUTHOR


APRIL 18, 1971

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 38% of the total text.



NIC 5841

APRIL 18, 1971




Response to RFC #86, Proposal for Network Standard Format for a graphics

data stream.

Category D.6

RFCs obsoleted None

RFCs updated 86

The basic approach of transmitting an intermediate, device independent

language which is translated into specific device codes at the

receiving host is sound. It appears to be the only approach that will

allow thought to be centered on picture descriptions. Ames Research

Center has adopted this approach in tying its graphic facilities, of

various types, and on various computers together. At present, we are

in the design phase and expect our package to be running in about six

months. The main objections to the structure as it now exists, is that

it takes no cognizance of the many features available on graphics

devices. Since these features will always be changing with new

devices, a set of option or mode primitives should be defined which

are logically separate from the drawing primitives provided in RFC 86.

The mode primitives will act upon the drawing primitives to modify

their actions. The scope of a mode primitive extends until a new mode

primitive resets an option. The use of mode primitives will allow the

network standard stream interpreter to treat them as null operations

if the features are missing at a particular host, or to perform more

detailed interpretation of the following data stream to achieve

results. The drawing primitives may also then keep a standard format

which need not be changed to incorporate new features.

Overall modes which primitives could control would be intensity

levels, or color selections for objects, in addition blinking of

objects should be provided. For vectors, the additional facility for

drawing dashed lines is necessary.

Character strings require another set of specification. The convention

for the beam is usually that it is in the center of the rectangular

area defining a character's boundaries. The beam position is usually

undefined at the finish of drawing a character string. A strong

exception is taken to the exclusion of form control characters from

strings. If included in the character string, they could provide for

shifting from upper to lower case, subscripting, superscripting, and

underscoring, as well as tab and other "carriage" motion functions.

The appropriate characters could be extracted at interpretation time

to provide the necessary information to display more complex strings.

To allow the facility for generating ALGOL-like delimiters, such as

"then", a convention for canonical character string should be adopted.

I believe the Multics conventions described in reference 1 will


Additional options for character strings should include a size

specification and an orientation sel...