Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream (RFC0125)
Original Publication Date: 1971-Apr-01
Included in the Prior Art Database: 2019-Feb-10
Internet Society Requests For Comment (RFCs)
NETWORK WORKING GROUP
REQUEST FOR COMMENT: 125
APRIL 18, 1971
AMES RESEARCH CENTER MOFFETT FIELD, CALIFORNIA
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 suffice.
Additional options for character strings should include a size specification and an orientation selection. As many devices, have hardware character generators that are fixed, some of these options may not be desirable to implement as sub...