Movatterモバイル変換

                         NETWORK WORKING GROUP                        REQUEST FOR COMMENT: 125                                NIC 5841                             APRIL 18, 1971JOHN McCONNELL                          AMES RESEARCH CENTER                       MOFFETT FIELD, CALIFORNIAResponse to RFC #86, Proposal for Network Standard Format for a graphicsdata stream.Category         D.6RFCs obsoleted   NoneRFCs updated     86                                                                [Page 1]

The basic approach of transmitting an intermediate, device independentlanguage which is translated into specific device codes at thereceiving host is sound. It appears to be the only approach that willallow thought to be centered on picture descriptions. Ames ResearchCenter has adopted this approach in tying its graphic facilities, ofvarious types, and on various computers together. At present, we arein the design phase and expect our package to be running in about sixmonths. The main objections to the structure as it now exists, is thatit takes no cognizance of the many features available on graphicsdevices. Since these features will always be changing with newdevices, a set of option or mode primitives should be defined whichare logically separate from the drawing primitives provided inRFC 86.The mode primitives will act upon the drawing primitives to modifytheir actions. The scope of a mode primitive extends until a new modeprimitive resets an option. The use of mode primitives will allow thenetwork standard stream interpreter to treat them as null operationsif the features are missing at a particular host, or to perform moredetailed interpretation of the following data stream to achieveresults. The drawing primitives may also then keep a standard formatwhich need not be changed to incorporate new features.Overall modes which primitives could control would be intensitylevels, or color selections for objects, in addition blinking ofobjects should be provided. For vectors, the additional facility fordrawing dashed lines is necessary.Character strings require another set of specification. The conventionfor the beam is usually that it is in the center of the rectangulararea defining a character's boundaries. The beam position is usuallyundefined at the finish of drawing a character string. A strongexception is taken to the exclusion of form control characters fromstrings. If included in the character string, they could provide forshifting from upper to lower case, subscripting, superscripting, andunderscoring, as well as tab and other "carriage" motion functions.The appropriate characters could be extracted at interpretation timeto 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 willsuffice.Additional options for character strings should include a sizespecification and an orientation selection. As many devices, havehardware character generators that are fixed, some of these optionsmay not be desirable to implement as subroutines.Another area that should be looked at further is the additionalsymbols available which are not specified in ASCII. Some means of                                                                [Page 2]

defining them should be provided within the argument string itself,again Multics has allowed the specification of arbitrary characters byentering their octal equivalents. The convention should use a controlcharacter code followed by a l6-bit list name which specifies thesub-list defining the character. The other alternative is to allow8-bit characters and allow the interpreter to choose a sub-list if thecharacter is not realizable with a hardware generator.The special form control characters to be used are:    a. BS    - backspace    b. LF    - for new line    c. SO/Sl - shift case    d. DC2   - superscript following characters    e. DC4   - subscript following characters    f. DC3   - special non-ASCII character follows    g. Tab   - position to next tab. May be predefined or specified.Another construct should be added to those proposed inRFC 86. This isthe display list pointer (NGDLP). It will have as a value the nextdrawing primitive to be executed. The value is a displacement from thehead of a list. With no mode setting primitives, this value is one toone with the drawing primitives transmitted in the NGDS. The NGDLP isneeded for consistency for execution of the nested list structure.Whenever an execute list primitive is encountered, the current valueof the NGDLP is saved along with the list name and current originvalue. When execution of a list is finished, the last values saved arerestored.An include list primitive would allow the treatment of a sub-list tobe equivalent to a macro instead of a subroutine. This would benecessary to avoid changes to all sub-pictures on the screen due tothe manipulation of a sub-list. The include primitive should have asparameters such specifications as size, intensity, orientation,blinking, etc. After a sub-list has been included in another list, itis no longer distinguished as a separate entity.To cut down on the volume of data being transferred, other commands tobe parsed by the stream interpreter should be added. These would allowthe manipulation of a list by the receiving host without aretransmission.  The types of manipulations would include rescalingthe coordinates for shrinking or zooming, translation of the origin,or rotation. Other manipulations to provide for displaying or notdisplaying a list, or enabling of disabling light pen detections wouldbe desirable.The problem of interaction with the displayed picture has yet to beaddressed, so this will be an attempt to elicit some more discussion                                                                [Page 3]

in this area. The use of a keyboard or function keys poses no problemin that both can be handled as a standard message from the graphicsterminal. The use of devices that interact with the picture or thescreen such as light pens, mice, joysticks, or tablets presents adifferent and more complex problem. This problem is the standard oneof making an association between the point selected and somemeaningful entity such as a list or a primitive. This associationshould be made at the receiving host since the NGDS has been changedin unknown ways.To allow the transmitting host to identify the object pointed at, thestack of suspended lists and the current value of the NGDLP willqualify the object to any level in a hierarchical structure. Inaddition, normalized x,y coordinates should be returned, as well as acharacter displacement if a string was pointed at. This structure willserve a light pen device very well since the light pen mechanismallows the determination of the currently executing primitive. Otherdevices interact with the picture in an asynchronous fashion and theassociation of an x,y pair to a structure is a more difficult problem.This may require that the host generating the graphic data stream beresponsible for making that association. A further complication ariseswhen it is desired to use a light pen in an area where no beam motionoccurs, then some directive to periodically sweep the screen and"find" the pen must be provided. This might be a sub-list which isexecuted periodically for this function.       [ This RFC was put into machine readable form for entry ]        [ into the online RFC archives by Jerry Tenenbaum 4/97 ]---------------------------------------------------------------------------Reference: Osanna, J., Sahzer, J.           Remote Terminal Character Stream Processing of Multics           Proceedings SJCC, 1970, p. 671                                                                [Page 4]