diff options
Diffstat (limited to 'doc/rfc/rfc965.txt')
| -rw-r--r-- | doc/rfc/rfc965.txt | 2905 |
1 files changed, 2905 insertions, 0 deletions
diff --git a/doc/rfc/rfc965.txt b/doc/rfc/rfc965.txt new file mode 100644 index 0000000..b3340bc --- /dev/null +++ b/doc/rfc/rfc965.txt @@ -0,0 +1,2905 @@ +Network Working Group Lorenzo Aguilar +Request for Comments: 965 SRI International + December 1985 + + A Format for a Graphical Communication Protocol + + +STATUS OF THIS MEMO + + This paper describes the requirements for a graphical format on which + to base a graphical on-line communication protocol. The proposal is + an Interactive Graphical Communication Format using the GKSM session + metafile. Distribution of this memo is unlimited. + +ABSTRACT + + This paper describes the requirements for a graphical format on which + to base a graphical on-line communication protocol. It is argued that + on-line graphical communication is similar to graphical session + capture, and thus we propose an Interactive Graphical Communication + Format using the GKSM session metafile. + + We discuss the items that we believe complement the GKSM metafile as + a format for on-line interactive exchanges. One key application area + of such a format is multi-media on-line conferencing; therefore, we + present a conferencing software architecture for processing the + proposed format. We make this format specification available to those + planning multi-media conferencing systems as a contribution toward + the development of a graphical communication protocol that will + permit the interoperation of these systems. + + We hope this contribution will encourage the discussion of multimedia + data exchange and the proposal of solutions. At SRI, we stay open to + the exploration of alternatives and we will continue our research and + development work in this problem area. + +ACKNOWLEDGEMENTS + + The author wants to thank Andy Poggio of SRI who made many insightful + and valuable suggestions that trimmed and improved level U. His + expertise in multi-media communication systems and his encouragement + were a most positive input to the creation of this IGCF. Dave + Worthington of SRI also participated in the project discussions + involving this IGCF. Thanks are also due to Tom Powers, chairman of + ANSI X3H33, who opened this forum to the presentation of an earlier + version of this paper, thereby providing an opportunity for the + invaluable feedback of the X3H33 members. Jon Postel of ISI + recommended a number of changes that made this paper more coherent + and accessible. + + + + +Aguilar [Page 1] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + Most of the work reported in this paper was sponsored by the U.S. + Navy, Naval Electronic Systems Command, Washington D.C., under + Contract No. N00039-83-K-0623. + +I. INTRODUCTION + + A. Use of a Graphical Communication Protocol + + In the field of computer communications, a protocol is a procedure + executed by two cooperating processes in order to attain a + meaningful exchange of information. A graphical communication + protocol is needed to exchange interactive vector graphics + information, possibly in conjunction with other information media + like voice, text, and video. Within this multi-media communication + environment, computer vector graphics plays a key role because it + takes full advantage of the processing capabilities of + communicating computers and human users, and thus it is far more + compact than digital images which are not generated from data + structures containing positional information. Vector graphical + communication trades intensive use of storage and processing, at + the communicating ends, in return for a low volume of exchanged + data, because workstations with graphical hardware exchange + graphics commands in conjunction with large data structures at the + transmitter and receivers. In this manner, the transmission of a + single command can produce extensive changes in the data displayed + at the sending and receiving ends. + + It is helpful to situate the aforesaid protocol at one of the + functional levels of the ISO Open Systems Interconnection + Reference Model [1]. Within such a model, a graphical protocol + functionality belongs primarily in the application level, though + some of it fits in the presentation level. We can distinguish the + following components of a communication protocol: + + a) a data format + b) rules to interpret transmitted data + c) state information tables + d) message exchange rules + + A format for a graphical protocol should provide the layout of the + transmitted data, and indicate how the formated data are + associated with interpretation rules. The choice of format + influences the state tables to be maintained for the correct + processing of the transmitted data stream. The graphical format + has a minor influence on the exchange rules, which should provide + for the efficient use of transmission capacity to transport the + data under such a format. Besides the graphical format, there are + + +Aguilar [Page 2] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + other aspects of a graphical protocol that determine state tables + and exchange rules. This paper concentrates in the data format, + and it does not discuss the message exchange. Nevertheless, we + discuss a simple software architecture for generating and + interpreting data streams written in our proposed format. Further, + we give an example of an application of a proposed format (in + Appendix B), and it illustrates the type of message exchanges that + are needed for establishing a communication session and exchanging + graphical information. + + Those in the computer communication field are well aware of the + importance of widely accepted protocols in order to achieve + meaningful communication. Those who need to implement interactive + graphical communications today are confronted with the lack of an + standard for computer graphics communication among application + programs. Nevertheless, we can use some of the work already done + by the computer graphics standard bodies. As a matter of fact, ISO + and ANSI have already appended, to the Graphical Kernel System + (GKS) standard, the GKSM session metafile specification that has + many of the features needed for an on-line graphical protocol. + + It is pertinent to mention an example of graphical communication + that illustrates the real-time nature of the interaction and also + illustrates the use of graphics in conjunction with other + information media. With audio-graphics conferencing, a group of + individuals at two or more locations can carry on an electronic + meeting. They can converse over voice channels and concurrently + share a graphics space on which they can display, point at, and + manipulate vector graphics pictures [2, 3, 4, 5, 6, 7]. + + The conference voice channels can be provided by a variety of + transmission technologies. The shared graphics space can be + implemented on workstations that display the pictures and permit + graphical interaction and communication with other locations. The + communication of operations upon pictures involves modifications + to the underlying data structures, but we are concerned with + graphical database updating only to the extent that such updating + supports the communication. + + In order to play out a recorded graphical session, we will need + indications of the rate at which the graphical elements must be + shown and the graphical operations recreated. We do not include + the means for indicating the timing of a session in a format + because our main purpose is to use it in mixed-media communication + environments. In these environments, the play-out timing must be + compatible across information media in order to coordinate them. + Therefore, we leave the timing mechanisms to conference-control + + +Aguilar [Page 3] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + modules. We also leave to conference control processes the manner + in which a conferee station emulates a graphical capability that + it lacks. One example is the representation of color in monochrome + displays. + + B. Relationship to Other Work + + There are a number of actual, and proposed, standards for graphics + information exchange. In the following, we explain the reasons + why, at present, none of them can be used as the basis of an + on-line protocol. As some of these standards evolve, however, some + may become suitable. Moreover, the experience gained with early + on-line graphics communication systems will provide insight into + the proper standard extensions to support more advanced systems. + Such insight could also be used to modify the format proposed in + this paper, which we consider an initial approach to the problem. + In the future, the format proposed in this paper could be replaced + by one of the aforesaid extended standards. + + The North American Presentation Level Protocol Syntax, NAPLPS, + specifies a data syntax and application semantics for one-way + teletext information dissemination and two-way videotex database + access and transaction services. The two-way videotex operational + model is based on the concept of a consumer and an information + provider or service operator. Because of this asymmetry, it is + assumed that almost all graphical information will flow from the + provider toward the consumer. In the reverse direction, the + consumer is expected to manipulate and transmit alphanumeric + information, for the most part. Although this standard includes + geometric drawing primitives, a user cannot directly modify shapes + drawn with the primitives. + + At present, NAPLPS does not include interaction concepts like + picture transformations or detectability, which are fundamental + for attaining a shared graphical workspace. Neither does it allow + key graphics input devices like mice, joysticks, stylus, rotating + balls, or light pens, which are needed for simple and efficient + editing of the shared workspace. + + We want to have user-to-user graphical communication that features + the level of sophistication and ease of interaction provided by + today's interactive graphics packages. Computer vector graphics + can provide both because its paradigm includes an application + program that keeps track of a very large number of possible + changes of state of the displayed picture. In addition, the + application drives a powerful graphics package, like GKS or ACM + Core. In the videotex paradigm, the provider application only + + +Aguilar [Page 4] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + allows limited changes to the displayed image, primarily database + retrieval requests. Also, the paradigm does not include a separate + graphics package. Both the graphics functionality and the data + format are collapsed into a coding specification, like NAPLPS. + + In this paper we are interested primarily in business and + industrial applications where there is a two-way, or multi-way, + flow of vector graphics information among the users. The users + will have workstations with substantial processing and storage + capacities, and high-resolution monitors; moreover, the + communication will be on a distributed architecture not depending + on a central server host, like the provider application host of + videotex. + + Currently, the videotex equipment at the consumer end consists of + inexpensive microprocessor-based decoders or personal computer + boards driving, in most cases, low-resolution standard TV sets and + personal computer displays. There is already affordable technology + to produce sophisticated decoders and high-resolution graphics + devices. The videotex standards need extensive revisions to take + advantage of these advances; in particular, they should consider + the receiving devices as capable of hosting a programmable + customer-application process. When this happens, videotex + protocols will be applicable to our intended problem areas [8]. + + The Computer Graphics Metafile [9] will become an international + and North American standard for graphics picture interchange in + the near future. However, the CGM, also referred as VDM, is a + picture-capture metafile that only records the final result of a + graphics session. It is not intended to record the + picture-creation process, which is fundamental for the interactive + applications that we are addressing. Moreover, the CGM is + presently aimed at a minimum support of GKS functionality. It will + be some time before the CGM will have some of the elements needed + for on-line interaction. If, after these additions, the CGM is + augmented for session capture, it would become a logical candidate + for a protocol format. + + Another future standard is the Computer Graphics Interface, CGI + also referred as VDI [10]. The CGI is a standard functional and + syntactical specification of the control and data exchange between + device-independent graphics software and one or more + device-dependent graphics device drivers. A major use of the CGI + is for the communication between an application host and a + graphics device, but the asymmetry between its intended + communicating ends hinders the use of CGI for our purposes. + + + +Aguilar [Page 5] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + As previously stated, we want to take advantage of intelligence + and storage at the communicating ends in order to achieve powerful + information-conveying effects using narrow-bandwidth channels. + This requires that the format we seek must have items for + communication between two applications. In contrast, the CGI + streams are processed by device-dependent drivers, rather than by + applications. The CGI specification does include application data + elements, but only to be stored in a metafile. These application + data elements are not interpreted by the drivers, but by + applications that read the metafile, some time after metafile + creation. + + Furthermore, the CGI has elements for obtaining graphical input, + as well as elements for inquiring graphics device capabilities, + characteristics, and states. Later, in Section III, we explain why + these two classes of elements are unnecessary for the + communication protocol we need. As the CGI evolves, it will + undergo significant changes, and, in the future, it may become a + very suitable kernel for the graphics protocol we seek. As a + matter of fact, the CGI will be the communication protocol between + graphical application hosts and graphics terminals. At SRI we are + tracking its evolution, and we are interested in defining a format + based on the CGI. + + Finally, the Initial Graphics Exchange Specification [11] is not + aimed at our primary area of interest. The IGES defines standard + file and language formats for storing and transmitting + product-definition data that can be used, in part, to generate + engineering drawings and other graphical representations of + engineering products. Besides the CAD orientation of IGES, the + graphical output function may be secondary to other goals like + transmitting numerical-control machine instructions. + +II. OPERATIONAL REQUIREMENTS AND USABILITY + + The main goal of this paper is to lay the groundwork for the + development of a vector graphics format to be used as a basis for an + on-line graphical communication protocol. We call such a format an + "interactive graphical communication format," or IGCF. In this + section we describe some operational requirements and usable + characteristics for an IGCF. + + A. Interoperation of Heterogeneous Systems + + A first functional requirement is that an IGCF must permit + communication among heterogeneous graphical systems differing both + in the hardware used and in the software of their graphics + + +Aguilar [Page 6] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + application interfaces. This is a fundamental for attaining + communication among similar graphical application programs running + on dissimilar hardware and using dissimilar graphics interface + packages. Some examples of such application programs are graphics + editors, CAD systems, and graphical database retrieval programs + communicating with other editors, CAD programs, and graphical + databases, respectively. + + B. Picture Capture + + A required characteristic of an IGCF is that it must be usable for + the exchange of static graphic pictures, i.e. for picture capture; + yet, it must not be restricted to final picture recording only. + There will be picture exchanges as part of the interactive + communication, and we anticipate the need to record the state of a + picture at some points during the on-line graphics engagement. We + foresee the creation of graphical IGCF libraries containing object + definitions and pictures for inclusion in new pictures. Since + metafiles have been used for a long time to capture pictures, + there is a strong motivation to base an IGCF on a metafile + standard in order to secure compatibility with a large number of + metafile sources and consumers. + + C. Prompt Transmission + + In some forms of interactive graphical communication, like + audiographics conferencing, it is critical to convey across users + the real-time nature of the interaction. This dictates that object + creations and manipulations be transmitted as they happen rather + than as a final result since a substantial part of the information + may be transmitted concurrently with the construction or operation + of an object, possibly through associated media like voice. Since + both construction and manipulation processes have to be + transmitted, there is a limit to the number of intermediate states + that can be economically transmitted. + + A third requirement is, therefore, that the IGCF elements provide + fine "granularity" to convey the dynamics of the constructions and + manipulations. We believe that it is sufficient that the IGCF have + basic construction elements like polygons, markers, polylines, and + text strings and that it transmit them only when they are + completed; i.e., it is not necessary to transmit partial + constructions of such elements. + + The problem for manipulations extends beyond an IGCF. Whereas we + know that an IGCF should include segment transformations, segment + highlighting and segment visibility on/off, the transmitter must + + +Aguilar [Page 7] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + decide how often to sample an on-going transformation and transmit + its current state. The choice of a sampling frequency will depend + on the available transmission bandwidth. + + D. Low Traffic Volume + + In many of the applications we envision, coordinate graphics will + be transmitted over narrow bandwidth channels, and thus it is + essential to minimize traffic. Accordingly, several requirements + are imposed on an IGCF to take advantage of the characteristics of + the graphics communication intercourse and architecture in order + to minimize traffic. + + An IGCF can help reduce traffic by including the basic geometric + objects from which so many other objects are built. Moreover, an + IGCF should permit the use of objects for the creation of more + complex objects; since reuse is very common, the result is a + reduction of traffic and storage cost. + + E. Preservation of Application Semantic Units + + A related requirement is that an IGCF must include elements to + represent graphical objects corresponding to real world entities + of the intended applications. For example, in a Navy application, + the entities of interest are carriers, submarines, planes, and the + like. We want to communicate such semantic units across systems + and to treat them as unitary objects because, in many + applications, communication is based on creating and operating + such units. If an IGCF has elements to represent such semantic + units, the communication traffic decreases because the entity + definitions can be transmitted only once and then reused, and + because the entities are manipulated as units rather than + separately manipulating their components. + + It turns out that there is a small set of primary operations that + can be applied to a graphical object, and an IGCF must have + elements representing such operations. In contrast to dumb + graphics terminals receiving screen refresh information from a + host, we foresee graphical communication taking place among + intelligent workstations that can exchange encoded operations, + interpret them, and apply them to objects stored locally. + + F. Transmission Batching + + We previously indicated the desirability of conveying to the human + users the real-time tempo of interactive graphics exchanges. + However, it is possible to do so without having to transmit + + +Aguilar [Page 8] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + immediately all IGCF elements. As a matter of fact, IGCF elements + should be divided into those causing a change on a displayed + picture and those that do not, although both classes may cause + changes to the stored graphical data structures. + + It is only necessary to transmit immediately those elements + causing a visible change on a displayed picture because they are + the ones whose reception and interpretation delivers information + to a human user. The second class of elements can be batched and + queued for transmission until one element of the first class is + submitted. We call the first class update Group-1, and the second, + update Group-2. + + The aforesaid division is quite important for packet + communications because each packet contains a hefty amount of + overhead control traffic. It is therefore mandatory to batch, into + a packet, as much client data as possible in order to reduce total + traffic. The batching units can be varied in size according to the + network traffic and response time of conference hosts. During + congested periods, the units may have to be increased, thus + lowering the number of messages, and then reduced when congestion + eases, thus increasing the number of messages. + + G. Simple Translation Between IGCF and User Interface + + According to the first requirement, an IGCF must permit the + interoperation of related heterogeneous graphics applications. + Such interoperation has, as an objective, the communication + between human users or between a human and a database. + Correspondingly, the interoperation involves a mapping between the + user interface commands and the IGCF elements. It is not advisable + to use the commands themselves as the IGCF elements; otherwise the + exchange would depend on the communicating systems, and every pair + of communicating systems would require an ad-hoc protocol. + + An additional usability characteristic is that there must be a + simple mapping between IGCF elements and the actions represented + by the user interface commands employed for graphical + communications. This simplicity is a must because every + communicating graphical system must have a translator that ideally + should be very simple. It seems that the inclusion of command + sequence delimiters in the IGCF helps the simplicity since the + delimiters permit keeping a smaller amount of state information + for processing an IGCF stream. + + We have verified the mapping from one set of commands for + audiographics conferencing to the IGCF proposed in this paper. The + + +Aguilar [Page 9] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + mapping from user interface commands to IGCF can be done in a + direct and efficient manner; on the other hand, the reverse + mapping, from IGCF to user interface commands, is a more difficult + task. We anticipate that, in order to improve performance, we will + have to map the IGCF elements to calls to lower level subroutines + implementing the user interface actions. Whereas such mapping is + conceptually no more complex than translating IGCF to the commands + themselves, it will require considerably more programming. + +III. ELEMENTS OF AN IGCF + + IGCF Element Classes + + In this section we list the classes of elements that we believe an + IGCF should have in order to exchange vector graphics under the + requirements of the previous section. The classes correspond to + the common function classes in computer graphics interfaces, and + each contains elements corresponding to interface primitives and + attributes. We do not list the elements for each class because + they are exemplified by the elements in the proposed IGCF. + + In the following list, two categories of functions are missing: + functions used to query the status of a graphics system, and input + functions. As a matter of fact, an IGCF only needs to have + elements representing actions that cause a change in the state of + the communicating graphical systems, and the inquire functions + obviously do not change their state. Even though an input function + executed at the transmitting end causes a local change, it is not + necessary to transmit the input command itself. The receivers only + need to get the data input, in IGCF representation, and they can + process the data in any manner, maybe simulating local input + actions. + + Control + + Elements for workstation: initialization, control and + transformation; and elements for normalization transformation. + (The normalization and workstation transformations can be used + to implement zooming.) + + Primitive attributes + + Elements for primitive, segment, and workstation attributes. + + Output primitives + + Elements for output primitives. + + +Aguilar [Page 10] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + Segmentation + + Elements for basic segmentation and workstation independent + segment storage. + + Object manipulations can be implemented with segment + transformations. Object insertion can be implemented using + segment recall and segment visibility. Object deletion can be + implemented using segment deletion and segment visibility. + Object selection can use segment highlighting as feedback to + the user. + + Dynamics + + A considerable part of the graphical information exchanged + through an IGCF will be in the form of pointer movements over a + background picture. Pointer tracking is used to transmit points + sampled from a graphical pointer trace in order to reproduce, + at the receivers, the movement of the pointer at the sender + site. This can be done either by just moving the cursor or by + tracing its movement with a line. Rubber band echoes are used + to signal areas, routes, and scopes in a highly dynamic way. + These are indicated by an echo reference point and a feedback + point. + + Hierarchical object definitions + + The requirement for preserving application semantics dictated that + an IGCF include the means to represent objects that stand for + application entities, and to manipulate such entities as graphical + units. Furthermore, the low-traffic-volume requirement called for + the use of already existing objects for the creation of new ones. + + One way to meet the aforesaid requirements is by including in an + IGCF the means to represent object hierarchies. In such a + hierarchy an object is a set of output primitives associated with + a set of attribute values or a set of lower-level objects, each + associated with a composition of transformations [12]. + + Graphics segments can be used to implement objects in the lowest + level of a hierarchy. The definition of a higher-level object can + be represented by sequences of IGCF elements describing the + definition process. Such a definition can be done by instantiating + lower-level objects with specific transformation parameters. Thus + an IGCF must incorporate brackets to mark the beginning and end of + object definitions, object instantiations, and object + redefinitions. + + +Aguilar [Page 11] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + In order to complement the mechanism for object definition, an + IGCF must permit the use of a flexible alphabet for creating + object identifiers that ensure the uniqueness of an identifier in + a hierarchy. The construction of the object identifiers is not + part of an IGCF, an IGCF only has to represent the identifiers. + Further, an identifier has to be independent of a communication + session and a particular graphics system so that identifiers + created at a host during one session can be used, in other + sessions possibly involving other hosts, to recall the objects + they label. + + We also leave to the communicating systems the implementation of + mechanisms to resolve duplicate identifiers when merging two + hierarchies, created in different sessions. In this paper we shall + limit ourselves to the warning that segment numbers do not qualify + as identifiers because they depend on the session and state of the + system in which they are created. + + In addition to object definition and instantiation, an IGCF should + have elements representing operations on objects. The operations + so far identified are: transformation, deletion, display, + disappearance, expose, and hide. Expose is used to uncover objects + on a screen that are hidden by other objects; hide is used to + place an object behind others on a screen. + +IV. A PROPOSED IGCF + + A. Using the GKSM as a Basis + + An IGCF must be usable to transmit all graphical actions in a + conference session. This suggests to base an IGCF on a standard + session-capture graphics metafile, thus ensuring compatibility + with a large user population. We have based the proposed IGCF, + PIGCF, on the GKSM session-capture metafile specification because + GKSM contains many of the elements identified for an IGCF [14]. In + addition, the audit trail orientation of GKSM permits the + recording of interactive communication sessions for later play + out, and this is a feature that we anticipate will be frequently + used. + + The GKSM is a proper subset of our PIGCF and thus any graphical + system developed to handle the PIGCF, can read a GKSM metafile. + Conversely, the applications using the PIGCF should have an option + for constraining session recording only to the GKSM part, possibly + suppressing some session events. By doing so, we will be able to + ship a GKSM metafile to any correspondent who has GKSM + + + +Aguilar [Page 12] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + interpretation software. Alternatively, an application with a + GKSM interpreter but without an PIGCF interpreter can read a PIGCF + file interpreting only the GKSM part and ignoring the rest. + + Whereas the GKSM was specified for the GKS system, we believe that + the GKSM is a sound and general basis for all of our 2-D + applications. We feel that the GKSM specification is not parochial + to GKS systems but contains all the most useful items desired in a + metafile. In the future, we expect to tackle applications + requiring 3-D, like interactive repair and maintenance aids. When + GKS be augmented with 3-D capabilities [13], we will extend the + PIGCF with any necessary elements. + + We are aware that the GKSM specification is not part of the GKS + standard itself but is an appendix recommending such a metafile + format. Nevertheless, all the GKS vendor implementations that we + know of, at the present time, support GKSM metafile output and + interpretation. If this trend continues, as we expect, we will be + able to exchange graphical files with a large base of GKS + installations. There will indeed be many of them since GKS will be + adopted as an standard by ISO and by many national standard bodies + in the near future. + + B. Positional Information Coordinates + + Following the GKSM convention, the PIGCF positional information is + in normalized device coordinates, NDC. Thus the originator of a + conference must indicate the workstation window for the + conference. This window is the sub-rectangle of the NDC space + enclosing the area of interest for the conference. In most cases, + the participating workstations will take this window as their own. + However, the graphical systems should provide for the possibility + of a workstation choosing a different workstation window, which + may contain the conference window or just overlap it. Except for + special cases, a conference originator should not state a + conference workstation viewport. In this manner, each workstation + can display its workstation viewport in the most convenient + portion of the screen. + + There will be conferences where the participating workstations + will maintain the positional information in world coordinates, WC. + It might be necessary to reconstruct the world dimensions after + transmission because such dimensions have a relevant meaning for + the application, like sizes of components or distances. In this + case, a workstation will have to map from WC to NDC before + transmitting and from NDC to WC after receiving. At the outset, + the conference originator has to specify the world window and the + + +Aguilar [Page 13] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + NDC viewport used in the conference in order for the conferencing + workstations to do such mappings. These mappings could be done by + the presentation layer, in terms of the ISO Open Systems + Interconnection Reference Model, in a manner that is transparent + to the communicating application programs. + + Most often all workstations will have the same world windows and + NDC viewports. However, the graphical systems will provide for the + possibility of a workstation choosing a different window or + viewport, but such workstation will have to record the conference + ones for doing the aforesaid mappings. There are graphical + systems, like the ACM Core, that do not provide for a workstation + transformation. In such systems, the NDC viewport is considered to + be the workstation window for the aforesaid mappings. + + C. Layers of the PIGCF + + There are two levels in the PIGCF a lower level L and an upper one + U. The lower level L is just the GKSM metafile specification as + defined in Appendix E of the proposed GKS ANSI standard [14]. We + have excerpted most of Appendix E of [14] at the end of this RFC + as our Appendix A. All level L elements belong to the update + Group-1 except: SET DEFERRAL STATE, the output primitive attribute + elements, the workstation attribute elements, CLIPPING RECTANGLE, + CREATE SEGMENT, CLOSE SEGMENT, RENAME SEGMENT, SET SEGMENT + PRIORITY, and SET DETECTABILITY. + + The upper level U is those elements that we believe complement the + GKSM for general on-line graphical exchanges. This layering + conforms to the graphics metafile level-structure described in + Enderle et. al [15]. Under such structuring, an application + oriented metafile can be based on graphical metafiles. + + D. PIGCF Elements in the Level U + + The level U items are encoded as GKSM user item elements so that a + PIGCF file will conform to the GKSM metafile specification. + Accordingly, a PIGCF file will be a GKSM metafile in its entirety. + We use the same formatting conventions as the GKSM specification. + Those unfamiliar with these conventions should read the beginning + of the appendix. The following items belong to the second update + group: the two items for object definition, the two items for + object redefinition, the two items for object instantiation, the + two items for normalization transformation, SELECT COMPONENT, and + RECALL LIBRARY. The remaining items belong to the first update + group. + + + +Aguilar [Page 14] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + Items for Object Definition + + BEGIN DEFINITION + + | 'GKSM 120' | L | + + Indicates beginning of object definition sequence + + END DEFINITION + + | 'GKSM 121' | L | I | + + Indicates end of object definition sequence. I(Nc): object + identifier ( N preceding c, i, r means an arbitrary number + of characters, integers, or reals.) Objects defined + interactively are made visible on the screen; i.e. they are + automatically instantiated. If only the definition is to be + kept but not the image, a DISAPPEAR item must follow. + + BEGIN REDEFINITION + + | 'GKSM 122' | L | I | + + Indicates beginning of object redefinition sequence + I(Nc): object identifier + + END REDEFINITION + + | 'GKSM 123' | L | + + Indicates end of object redefinition sequence + + Items for Object Instantiation + + BEGIN INSTANTIATION + + | 'GKSM 124' | L | I | + + Indicates beginning of object instantiation sequence + I(Nc): Object identifier + + END INSTANTIATION + + | 'GKSM 125' | L | + + Indicates end of object instantiation sequence + + + +Aguilar [Page 15] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + Items for Object Manipulation + + TRANSFORM OBJECT + + | 'GKSM 126' | L | C | I | M | + + Apply transformation M to object I + C: number of characters in identifier + I(Nc): object id + M(6r): upper and center rows of a 3x3 matrix representing + a 2D homogeneous transformation [12]. + M 11 M 12 M 13 M 21 M 22 M 23 + + DELETE OBJECT + + | 'GKSM 127' | L | I | + + I(Nc): object identifier + + DISPLAY OBJECT + + | 'GKSM 128' | L | I | + + Turn on visibility of object I + I(Nc): object identifier + + DISAPPEAR OBJECT + + | 'GKSM 129' | L | I | + + Turn off visibility of object I + I(Nc): object identifier + + EXPOSE OBJECT + + | 'GKSM 130' | L | I | + + Redisplay object I on top of any overlapping objects + I(c): object identifier + + HIDE OBJECT + + | 'GKSM 131' | L | I | + + Redisplay object I behind any overlapping objects + I(c): object identifier + + + +Aguilar [Page 16] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + SELECT COMPONENT + + | 'GKSM 132' | L | I | P | + + Select component P of object I + I(c): object identifier + P(i): pick id of component + This is used to select a group of output primitives + identified by P in a segment associated with I. + + ERASE COMPONENT + + | 'GKSM 133' | L | I | P | + + Erase component P of object I + I(c): object identifier + P(i): pick id of component + + This erases a group of output primitives identified by P in + a segment associated with I. This element can be used only + within a REDEFINE OBJECT sequence. + + Items for Normalization Transformation + + SET WINDOW + + | 'GKSM 134' | L | W | + + Define boundaries of world window for normalization + transformation. + W(4r): limits of world window (XMIN, XMAX, YMIN, YMAX ) + + SET VIEWPORT + + | 'GKSM 135' | L | V | + + Define boundaries of NDC viewport for normalization + transformation. + V(4r): limits of NDC viewport (XMIN, XMAX, YMIN, YMAX ) + + + + + + + + + + +Aguilar [Page 17] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + Items for Other Operations + + ABORT + + | 'GKSM 136' | L | + + Abort ongoing operation transmitted in PIGCF stream. This + provides the means to abort unwanted or erroneous + operations. Only the innermost operation of a nested + sequence is aborted; successive aborts can be used to get + out of several levels of operation nesting. + + POINTER TRACKING + + | 'GKSM 137' | L | T | P | + + Update graphical pointer position to P + T(i): 0 causes only cursor to be moved + 1 causes cursor movement to be traced with + a line + P(p): a point sampled from graphical pointer + movement trace + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aguilar [Page 18] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + RUBBER BAND + + | 'GKSM 138' | L | T | P | + + Echo a rubber band of type T with given reference and + feedback points. The first occurrence of this item in a + sequence carries the coordinates of the echo reference + point. Subsequent occurrences carry updates to a pointer + position indicating an echo feedback point. + + T(i): echo type + ( 0 echo reference point; + > 0 echo feedback: + 1 = line, + 2 = rectangle, + 3 = circle ) + P(r): echo reference point (T = 0), + or echo feedback point (T > 0) + + The reference and feedback points are: + T = 1 - reference is one end of line, feedback is + other end. + T = 2 - reference is one corner of rectangle, feedback + is opposite corner. + T = 3 - reference is center of circle, feedback is + perimeter point. + + RECALL LIBRARY + + | 'GKSM 139' | L | F | + + Recall graphical library in file F + F(i): name of file containing library + + The graphical pictures in F and all their components become + available for use during the communication session. The + pictures are assumed to be recorded with the PIGCF, and + their components have to be displayed with DISPLAY OBJECT + elements or similar actions so that the pictures become + visible. + + + + + + + + + +Aguilar [Page 19] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + +V. AN ARCHITECTURE FOR PIGCF PROCESSING + + This section presents an example software architecture for the + generation and interpretation of PIGCF in a multimedia conferencing + system using GKS as the underlying programmer's graphics interface. + This section should not be interpreted as a definitive statement of + such an architecture, but only as an exercise to illustrate how the + format proposed in this paper fits within the overall framework of a + conferencing system. Choosing GKS simplifies the example + architecture; nevertheless, other graphics packages can be used by + adding, to the architecture, the modules to interpret and generate + the PIGCF level L items. + + Figure 1 shows the major software modules charged with graphics + interaction and display at a conferencing workstation. This is a + familiar programmer's view of the graphics pipeline. A conferencing + application program updates data structures and uses + device-independent graphics services through a language binding. + These services, in turn, use device-dependent graphics services that + call on device drivers to accept input and to present graphic + pictures. The application performs numerous other functions for + conference management and control of other media streams, but we need + not consider them in this example. + + In Figure 2, the basic graphics pipeline has been augmented with the + software modules involved in the generation, transmission, reception, + and interpretation of PIGCF streams. The application has a module for + interpreting the lower and higher levels of PIGCF and one for + generating the upper level U. The device-independent graphics + services include modules for generating and interpreting the lower + level, L. This reflects the current practice of including the + generation and interpretation functions in the graphics package. + There is also a module that transmits the outgoing PIGCF streams to + remote work stations. Similarly, there is a module that receives + incoming streams from remote stations. In actual practice, the + transmit and receive modules are decomposed into several processes + implementing a layered protocol architecture. A process receives both + levels of PIGCF and writes them into a conference record metafile for + future use. A router process receives and forwards PIGCF traffic from + and to the modules previously referred. This router is likely to be + replaced by independent communication interfaces between pairs of + modules exchanging PIGCF. + + The thick arrows show the flow of outgoing PIGCF, whereas the thin + arrows show the incoming PIGCF flow. We first follow the outgoing + path, starting at the application. The application processes local + user actions which are transformed into data structure updates, level + + +Aguilar [Page 20] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + U PIGCF elements, and executions of device independent graphics + subroutines that, among other things, generate level L PIGCF (GKSM) + elements. + + The router merges both level streams according to generation order + and sends them to the local copy of the conference record and to the + transmission module. The latter batches Group-2 PIGCF items until it + receives a Group-1 item. It also timestamps the PIGCF stream to + synchronize its play-back, at the receiver, with the play-back of + other media information. The PIGCF may be separated into traffic + categories transmitted over diverse communication facilities + according to the transport services required by the categories, for + example, real-time service for pointer updates, highly reliable + transmission for new object definitions, or low-priority service for + graphical library transfers. Finally, the transmit module must + acknowledge the reception of incoming PIGCF, and of other media + traffic as well. + + The receive module is the entry point for incoming PIGCF streams that + may come within diverse traffic categories requiring merging. It + checks the timestamps for synchronizing PIGCF items with related data + in other media, for example, voice. It is possible to include here a + high-level error-correction function that validates the received + streams using state and context information about PIGCF syntax and + semantics. The receive module passes the streams to the router which + forwards them to three processes: It sends level L items to the GKSM + interpreter which produces the corresponding changes on the displayed + picture; it sends level L and level U items to the conference record, + as well as to the PIGCF interpretation code in the application. The + level U items cause updates to both the data structures modeling + object hierarchies, and the pictorial representation of the + hierarchies, through the execution of graphics services. U items also + update graphics cursors and may recall new graphics libraries. The + application must process level L items because they could indicate + updates to the data structures; this happens if, for example, the + structures record attribute value information for the object + hierarchies. The application coordinates these actions with other + media effects according to the timestamps. Conference record + play-back is done in off-line mode. Record items are received by the + router and thereafter processed similarly to incoming PIGCF. + + + + + + + + + +Aguilar [Page 21] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + +------------+ +-------------+ + |APPLICATION | | OTHER | + | DATA | | MEDIA | + |STRUCTURES | |-------------| + +-----|------+ | CONFERENCE | + |----------> | APPLICATION | + | GRAPHICS | + |----------> | | + +-----|------+ | | + | LANGUAGE | +-------------+ + | BINDING | + +-----|------+ +-------------+ + |----------> | DEVICE- | + +------------+ | INDEPENDENT | + | DEVICE | | GRAPHICS | + | DEPENDENT | <---> | SERVICES | + | GRAPHICS | | | + | SERVICES | | | + +-----|------+ | | + | | | + v | | + +------------+ | | + | DEVICE | | | + | DRIVERS | | | + +------------+ +-------------+ + + FIGURE 1 - THE BASIC GRAPHICS PIPELINE + IN A CONFERENCING SYSTEM + + + + + + + + + + + + + + + + + + + + + +Aguilar [Page 22] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + ++------------+ +------------+ +------------------+ +|APPLICATION | | OTHER | | TRANSMIT | +| DATA | | MEDIA | | ACK |=> +| STRUCTURES | |------------| +-----+ | SEPARATE TRAFFIC |=> ++-----|------+ | CONFERENCE | | |===> | BATCHING |=> + |---------->|APPLICATION | | | | TIMESTAMPING | + | GRAPHICS | | | +------------------+ + |---------->|------------| | | + | | PIGCF L, U | <---| | +------------------+ ++-----|------| | INTERPRETER| | | | RECEIVE | +| LANGUAGE | +------------+ | R | | MERGE TRAFFIC |<- +| BINDING | | PIGCF U |===> | O | <---| CHECK TIMESTAMPS |<- ++-----|------+ | GENERATOR | | U | | ERROR CORRECTION |<- + | +------------+ | T | | | + ------------------| | E | +------------------+ ++------------+ +-----V------+ | R | +| DEVICE | | DEVICE | | | +------------------+ +| DEPENDENT | |INDEPENDENT | | |====>| | +| GRAPHICS |<-->| GRAPHICS | | |---->| CONFERENCE | +| SERVICES | | SERVICES | | | | RECORD | +| | | | | | | | ++-----|------+ |------------| | | +------------------+ + | | GKSM | | | + v | INTERPRETER|<--- | | <--- INCOMING PIGCF ++------------+ +------------+ | | +| DEVICE | | GKSM | | | ===> OUTGOING PIGCF +| DRIVERS | | GENERATOR |===> | | ++------------+ +------------+ +-----+ + +FIGURE 2 - A CONFERENCING SOFTWARE ARCHITECTURE FOR PROCESSING PIGCF + +VI. CONCLUSIONS + + Teleconferencing and other multi-media applications will be part of + the communication resources available to organizations in the near + future. This will prompt computer graphics and computer communication + practitioners to address the issue of application-to-application + graphics communication. A key element of the issue is a protocol, and + a key component of the protocol is a data format. We have presented + the operational requirements for such a protocol and have proposed a + format that fulfills these requirements. + + At present, none of the existing or emerging graphics standards can + be used as the needed protocol or as a format for the protocol, but + this may change as the standards evolve. We are monitoring the + standards development and will study the use of some of them as a + format basis, in particular the CGI. Nevertheless, the computer + + +Aguilar [Page 23] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + communication community badly needs experience with multi-media + conferencing implementations. In order for these applications to + happen, one can base a graphics communication protocol on an official + or on a de-facto standard that is likely to gain wide use thus + assuring interoperability with a broad user base. We believe that, + by using the GKSM session metafile, we are moving in the proper + direction. + + Planning the software architecture for generating and interpreting + the proposed PIGCF has brought up some problems we will confront as + we continue our work toward the development of a complete graphics + protocol. This is being done as part of the SRI on-going program in + multimedia communications. Within this program, we are implementing + a simple multi-media conferencing prototype and will design a more + complete one. The experience from both exercises will be a valuable + input to the protocol architecture design. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aguilar [Page 24] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + +APPENDIX A + + Excerpt from "Draft Proposal: Graphical Kernel System" [14] + + E.2 Metafile Based on ISO DIS7942 + + This metafile may be categorized as one which aims to provide a + means of recording the exact sequence of function calls made to + GKS. Its functional capability covers the entire range of GKS + output functions, from level m to level 2. It is, therefore, + suitable for applications where the individual graphics actions + need to be 'played back', perhaps with selective graphical editing + being done by the interpreter. + + Two encodings have been specified for this metafile. One encoding + is inefficient for many applications. The second allows an + unspecified binary format. The remainder of this IGCF appendix + gives full details of these metafile structures and encodings. + + E.2.1 File Format and Data Format + + The GKS metafile is built up as a sequence of logical data + items. The file starts with a file header in fixed format which + describes the origin of the metafile (author, installation), + the format of the following items, and the number + representation. The file ends with an end item indicating the + logical end of the file. In between these two items, the + following information is recorded in the sense of an audit + trail: + + a) workstation control items and message items; + + b) output primitive items, describing elementary + graphics objects; + + c) attribute information, including output primitive + attributes; segment attributes, and workstation + attributes; + + d) segment items, describing the segment structure and + dynamic segment manipulations; + + e) user items. + + + + + + +Aguilar [Page 25] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + The overall structure of the GKS metafile is as follows: + + FILE: |file |item|---|item|---|end | + |header| 1 | | i | |item| + + ITEM: |item |item data record| + |header | | + + ITEM |'GKSM' |identification|length of item data| + + HEADER: |optional| number | in bytes | + + All data items except the file header have an item header + containing: + + a) the character string 'GKSM' (optional) which is + present to improve legibility of the file and to + provide an error control facility; + + b) the item type identification number which indicates + the kind of information that is contained in the + item; + + c) the length of the item data record. + + The lengths of these fields of the item header are + implementation dependent and are specified in the file header. + The content of the item data record is fully described below + for each item type. + + The metafile contains characters, integer numbers, and real + numbers marked (c), (i), (r) in the item description. + Characters in the metafile are represented according to ISO 646 + and ISO 2022. Numbers will be represented according to ISO 6093 + using format F1 for integers and format F2 for reals. (Remark: + Formats F1 and F2 can be written and read via FORTRAN formats I + and F respectively.) + + Real numbers describing coordinates and length units are stored + as normalized device coordinates. The workstation + transformation, if specified in the application program for a + workstation writing a metafile of this format, is not performed + but WORKSTATION WINDOW and WORKSTATION VIEWPORT are stored in + data items for later usage. Real numbers may be stored as + integers. In this case transformation parameters are specified + in the file header to allow proper transformation of integers + into normalized device coordinates. + + +Aguilar [Page 26] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + For reasons of economy, numbers can be stored using an internal + binary format. As no standard exists for binary number + representation, this format limits the portability of the + metafile. The specification of such a binary number + representation is outside the scope of this document. + + When exchanging metafiles between different installations, the + physical structure of data sets on specific storage media + should be standardized. Such a definition is outside the scope + of this standard. + + E.3 Generation of Metafiles + + Table E1 contains a list, by class, of all GKS functions which + apply to workstations of category MO, and their effects on this + GKSM. In the table, GKSM-OUT is a workstation identifier + indicating a workstation writing a metafile of this format. + + The concepts of clipping rectangle and clipping indicator are + encapsulated in one metafile item which specifies a clipping + rectangle. This item is written to the metafile on activate + workstation with the values (0, 1, 0, 1), if the clipping + indicator is OFF, or the viewport of the current normalization + transformation, if the clipping indicator is ON. If the viewport + of the current normalization transformation is redefined or a + different normalization transformation is selected when the + clipping indicator is ON, a further clipping rectangle item is + written. If the clipping indicator is changed to OFF, a clipping + rectangle item (0, 1, 0, 1) is written. If the clipping indicator + is changed to ON, an item containing the viewport of the current + normalization transformation is written. This is analogous to the + handling of clipping in segments (see 4.7.6 [14]). + + +GKS functions which apply to workstations GKSM item created +of category MO or effect +======================================================================== + +Control functions + +OPEN WORKSTATION (GKSM-OUT,...) - (file header) + 1 (CONDITIONAL) +CLOSE WORKSTATION (GKSM-OUT) 0 (end item) +ACTIVATE WORKSTATION (GKSM-OUT) (61, 21-44) + ensure attributes + current; + enable output + + +Aguilar [Page 27] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + +DEACTIVATE WORKSTATION (GKSM-OUT) disable output +CLEAR WORKSTATION (GKSM-OUT,...) 1 + 2 +REDRAW ALL SEGMENTS ON WORKSTATION (GKSM-OUT) +UPDATE WORKSTATION (GKSM-OUT,...) 3 +SET DEFERRAL STATE (GKSM-OUT,...) 4 +MESSAGE (GKSM-OUT,...) 5 (message) +ESCAPE 6 +________________________________________________________________________ + +Output Primitives + +POLYLINE 11 +POLYMARKER 12 +TEXT 13 +FILL AREA 14 +CELL ARRAY 15 +GENERALIZED DRAWING PRIMITIVE 16 +________________________________________________________________________ + +Output Attributes + +SET POLYLINE INDEX 21 +SET LINETYPE 22 +SET LINEWIDTH SCALE FACTOR 23 +SET POLYLINE COLOUR INDEX 24 +SET POLYMARKER INDEX 25 +SET MARKER TYPE 26 +SET MARKER SIZE SCALE FACTOR 27 +SET POLYMARKER COLOUR INDEX 28 +SET TEXT INDEX 29 +SET TEXT FONT AND PRECISION 30 +SET CHARACTER EXPANSION FACTOR 31 +SET CHARACTER SPACING 32 +SET TEXT COLOUR INDEX 33 +SET CHARACTER HEIGHT 34 +SET CHARACTER UP VECTOR 34 +SET TEXT PATH 35 +SET TEXT ALIGNMENT 36 +SET FILL AREA INDEX 37 +SET FILL AREA INTERIOR STYLE 38 +SET FILL AREA STYLE INDEX 39 +SET FILL AREA COLOUR INDEX 40 + +SET PATTERN SIZE 41 +SET PATTERN REFERENCE POINT 42 + + + +Aguilar [Page 28] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + +SET ASPECT SOURCE FLAGS 43 +SET PICK IDENTIFIER 44 +________________________________________________________________________ + +Workstation Attributes + +SET POLYLINE REPRESENTATION (GKSM-OUT,...) 51 +SET POLYMARKER REPRESENTATION (GKSM-OUT,...) 52 +SET TEXT REPRESENTATION (GKSM-OUT,...) 53 +SET FILL AREA REPRESENTATION (GKSM-OUT,...) 54 +SET PATTERN REPRESENTATION (GKSM-OUT,...) 55 +SET COLOUR REPRESENTATION (GKSM-OUT,...) 56 +________________________________________________________________________ + +Transformation Functions + +SET WINDOW of current normalization 34, 41, 42 +transformation +SET VIEWPOINT of current normalization 61, 34, 41, 42 +transformation +SELECT NORMALIZATION TRANSFORMATION 61, 34, 41, 42 +SET CLIPPING INDICATOR 61 +SET WORKSTATION WINDOW (GKSM-OUT,...) 71 +SET WORKSTATION WINDOW VIEWPORT (GKSM-OUT,...) 72 + +Note: item 61 (CLIPPING RECTANGLE) is described more fully in E.2.2. + +Note: When the current normalization transformation is altered, items +corresponding to attributes containing coordinate information are sent +(items 34, 41, and 42). +________________________________________________________________________ + +Segment Functions + +CREATE SEGMENT 81 +CLOSE SEGMENT 82 +RENAME SEGMENT 83 +DELETE SEGMENT 84 + +DELETE SEGMENT FROM WORKSTATION (GKSM-OUT,...) 84 +ASSOCIATE SEGMENT WITH WORKSTATION 81, (21-44), (11-16), +(GKSM-OUT,...) (61), 82 +COPY SEGMENT TO WORKSTATION (GKSM-OUT,...) (21-44), (11-16), (61) + +INSERT SEGMENT (21-44), (11-16), (61) +________________________________________________________________________ + + + +Aguilar [Page 29] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + +Segment Attributes + +SET SEGMENT TRANSFORMATION 91 + +SET VISIBILITY 92 +SET HIGHLIGHTING 93 +SET SEGMENT PRIORITY 94 +SET DETECTABILITY 95 +________________________________________________________________________ + +Metafile Functions + +WRITE ITEM TO GKSM > 100 +________________________________________________________________________ + + E.4 Interpretation of Metafiles + + E.4.1 Introduction + + The interpretation of metafiles in GKS is described in 4.9 + [14]. The effects of INTERPRET ITEM for all types of metafile + item are described in the following sections. Items are grouped + by class of functionality. + + E.4.2 Control Items + + Interpretation of items in this class is described under the + definitions of each item in E.5. ([14] reads "E.2.4" instead of + "E.5" which we believe is an error). + + E.4.3 Output Primitives + + Interpretation of items in this class generates output + corresponding to the primitive functions, except that + coordinates of points are expressed in NDC. Primitive + attributes bound to primitives are those which have originated + from interpretation of primitive attribute items in this + particular metafile (see E.4.4). + + E.4.4 Output Primative Attributes + + Interpretation of items in this class sets values for use in + the display of primitives subsequently originating from this + particular metafile (see E.4.3). No changes are made to entries + in the GKS state list. + + + + +Aguilar [Page 30] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + E.4.5 Workstation Attributes + + Interpretation of items in this class has the same effect as + invocation of the corresponding GKS functions shown in Table + E1. The GKS functions are performed on all active workstations. + + E.4.6 Transformations + + Interpretation of a clipping rectangle item sets values for use + in clipping output primitives subsequently originating from + this particular metafile. No changes are made to entries in the + GKS state list. Interpretation of other items in this class + (WORKSTATION WINDOW and WORKSTATION VIEWPORT) causes the + invocation of the corresponding GKS functions on all active + workstations. + + E.4.7 Segment Manipulation + + Interpretation of items in this class has the same effect as + invocation of the corresponding GKS functions shown in Table + E1. (Item 84 causes an invocation of DELETE SEGMENT.) + + E.4.8 Segment Attributes + + Interpretation of items in this class has the same effect as + invocation of the corresponding GKS functions shown in Table + E1. + + E.5 Control Items + + FILE HEADER + + | GKSM | N | D | V | H | T | L | I | R | F | RI | ZERO | ONE | + +All fields in the file header item have fixed length. Numbers are +formated according to ISO 6093 - Format F1. + +General Information: + +GKSM 4 bytes containing string 'GKSM' +N 40 bytes containing name of author/installation +D 8 bytes date (year/month/day, e.g., 79/12/31) +V 2 bytes version number: the metafile described here has + version number 1 +H 2 bytes integer specifying how many bytes of the string 'GKSM' + are repeated at the beginning of each record. + Possible values: 0, 1, 2, 3, 4 + + +Aguilar [Page 31] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + +T 2 bytes length of item type indicator field +L 2 bytes length of item data record length indicator field +I 2 bytes length of field for each integer in the + item data record (applied to all data marked (i) + in the item description) +R 2 bytes length of field for each real in the item data record + (applies to all data marked (r) in the item + description). + +Specification of Number Representation: + +F 2 bytes Possible values: 1, 2. This applies to all data + in the items marked (i) or (r) and to item type + and item data record length: + 1: all numbers are formatted according to ISO 6093 + 2: all numbers (except in the file header) are + stored in an internal binary format +RI 2 bytes Possible values: 1, 2. This is the number + representation for data marked (r): + 1 = real, 2 = integer +ZERO 11 bytes integer equivalent to 0.0, if RI = 2 +ONE 11 bytes integer equivalent to 1.0, if RI = 2 + + After the file header, which is in fixed format, all values in + the following items are in the format defined by the file + header. For the following description, the setting: + + H = 4; T = 3; F = 1 + + is assumed. In addition to formats (c), (i) and (r), which are + already described, (p) denotes a point represented by a pair of + real numbers (2r). The notation allows the single letter to be + preceded by an expression, indicating the number of values of + that type. + + {Explanatory comments have been added to some item + specifications; these are not part of the GKS Appendix E and + they are enclosed in braces {}. A complete definition of the + generation and interpretation of the GKSM items is given by the + definition of the corresponding GKS functions [14].} + + END ITEM + + | 'GKSM 0' | L | + + Last item of every GKS Metafile. Sets condition for the error. + + + +Aguilar [Page 32] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + CLEAR WORKSTATION + + | 'GKSM 1' | L | C | + + Requests CLEAR WORKSTATION on all active workstations. + + C(i): clearing control flag + (0 = CONDITIONAL, 1 = ALWAYS) + + REDRAW ALL SEGMENTS ON WORKSTATION + + | 'GKSM 3' | L | R | + + Requests UPDATE WORKSTATION on all active workstations. + + R(i): regeneration flag + (0 = PERFORM, 1 = SUSPEND) + + DEFERRAL STATE + + | 'GKSM 4' | L | D | R | + + Requests SET DEFERRAL STATE on all active workstations. + + D(i): deferral mode + (0 = ASAP, 1 = BNIG, 2 = BNIL, 3 = ASTI) + + R(i): implicit regeneration mode + (0 = ALLOWED, 1 = SUPPRESSED) + + {This item provides control over the occurrence of the visual + effect of GKS functions in order to optimize the use of + workstation capabilities according to application needs.} + + MESSAGE + + | 'GKSM 5' | L | N | T | + + Requests MESSAGE on all active workstations. + N(i): number of characters in string + T(Nc): string with N characters. + + {The message is not part of a metafile output primitives; the + message is only for interpretation by workstation operators.} + + + + + +Aguilar [Page 33] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + ESCAPE + + | 'GKSM 6' | L | FI | L | M | I | R | + + Requests ESCAPE + + FI(i): function identifier + L(i): length of integer data in data record + M(i): length of real data in data record + I(Li): integer data + R(Mr): real data. + + {This item permits the invocation of a specific non-standard + escape function FI. The execution of the function with the + given parameters must not alter the GKS state list nor produce + geometrical output.} + + E.6 Items for Output Primitives + + POLYLINE + + | 'GKSM 11' | L | N | P | + + N(i): number of points of the polyline + P(Np): list of points + + POLYMARKER + + | 'GKSM 12' | L | N | P | + + N(i): number of points + P(Np): list of points. + + TEXT + + | 'GKSM 13' | L | P | N | T | + + P(p): starting point of character string + N(i): number of characters in string T + T(Nc): string with N characters from the set of ISO 646 + + FILL AREA + + | 'GKSM 14' | L | N | P | + + N(i): number of points + P(Np): list of points. + + +Aguilar [Page 34] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + CELL ARRAY + + | 'GKSM 15' | L | P | Q | R | N | M | CT | + + P(p),Q(p),R(p): coordinates of corner points of pixel array + (P and Q are the images of the points P and + Q specified in the function CELL ARRAY and + R is another corner) + M(i): number of rows in array + N(i): number of columns in array + CT(MNi): array of colour indices stored row by row + + {This item permits passing raster images to GKS. The raster + image is defined by the colour index matrix CT, and its World + Coordinate position given by points P and Q.} + + GENERALIZED DRAWING PRIMITIVE + + | 'GKSM 16' | L | GI | N | P | L | M | I | R | + + GI(i): GDP identifier + N(i): number of points + P(Np): list of points + L(i): length of integer data in data record + M(i): length of real data in data record + I(Li): integer data + R(Mr): real data. + + {This item provides a standard way for drawing additional + non-standard output primitives. The generalized drawing + primitive GI is drawn according to the point list P and the + data record in I and R.} + + E.7 Items for Output Primitive Attributes + + POLYLINE INDEX + + | 'GKSM 21' | L | LT | + + LT(i): linetype + + + + + + + + + +Aguilar [Page 35] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + LINEWIDTH SCALE FACTOR + + | 'GKSM 23' | L | LW | + + LW(r): linewidth scale factor + + {In GKS, the line width is not affected by GKS transformations. + However, the effective line width is calculated as the product + of the nominal line width times the line width scale factor in + effect when a line is drawn.} + + POLYLINE COLOUR INDEX + + | 'GKSM 24' | L | CI | + + CI(i): polyline colour index + + POLYMARKER INDEX + + | 'GKSM 25' | L | I | + + I(i): polymarker index + + MARKER TYPE + + | 'GKSM 26' | L | MT | + + MT(i): marker type + + MARKER SIZE SCALE FACTOR + + | 'GKSM 27' | L | MS | + + MS(r): marker size scale factor + + {In GKS, the marker size is not affected by GKS + transformations. However, the effective marker size is + calculated as the product of the nominal marker size times the + marker size scale factor in effect when a marker is drawn.} + + POLYMARKER COLOUR INDEX + + | 'GKSM 28' | L | CI | + + CI(i): polymarker colour index + + + + +Aguilar [Page 36] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + TEXT INDEX + + | 'GKSM 29' | L | I | + + I(i): text index + + TEXT FONT AND PRECISION + + | 'GKSM 30' | L | F | P | + + F(i): text font + P(i): text precision + (0 = STRING, 1 = CHAR, 2 = STROKE) + + CHARACTER EXPANSION FACTOR + + | 'GKSM 31' | L | CEF | + + CEF(r): character expansion factor + + {This item allows the manipulation of the width/height of the + character body. The width of the character body is scaled by + the CEF factor.} + + CHARACTER SPACING + + | 'GKSM 32' | L | CS | + + CS(r): character spacing + + TEXT COLOUR INDEX + + | 'GKSM 33' | L | CI | + + CI(i): text colour index + + + + + + + + + + + + + + +Aguilar [Page 37] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + CHARACTER VECTORS + + | 'GKSM 34' | L | CH | CW | + + CH(2r): character height vector + CW(2r): character width vector + + Note: These vectors are the height and width vectors described + in 4.4.5 of [14]. + + {The character height vector is parallel to the character up + vector and has a length equal to character height. The + character height specifies the height of a capital letter. The + character width vector is perpendicular to the height vector, + in the direction of the character baseline, and has the same + length.} + + TEXT PATH + + | 'GKSM 35' | L | P | + + P(i): text path + (0 = LEFT, 1 = RIGHT, 2 = UP, 3 = DOWN) + + TEXT ALIGNMENT + + | 'GKSM 36' | L | H | V | + + H(i): horizontal character alignment + (0 = NORMAL, 1 = LEFT, 2 = CENTRE, 3 = RIGHT) + V(i): vertical character alignment + (0 = NORMAL, 1 = TOP, 2 = CAP, 3 = HALF, 4 = BASE, + 5 = BOTTOM) + + FILL AREA INDEX + + | 'GKSM 37' | L | I | + + I(i): fill area index + + FILL AREA INTERIOR STYLE + + | 'GKSM 38' | L | S | + + S(i): fill area interior style + (0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH) + + + +Aguilar [Page 38] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + FILL AREA STYLE INDEX + + | 'GKSM 39' | L | SI | + + SI(i): fill area style index + + FILL AREA COLOUR INDEX + + | 'GKSM 40' | L | CI | + + CI(i): fill area colour index + + PATTERN SIZE + + | 'GKSM 41' | L | PW | PH | + + PW(2r): pattern width vector + PH(2r): pattern height vector + + {One style for filling areas is with a pattern of color cells. + Such a pattern is defined by an array of color indices which is + mapped into a pattern rectangle with dimensions given by PW and + PH.} + + PATTERN REFERENCE POINT + + | 'GKSM 42' | L | P | + + P(p): reference point + + {One style for filling areas is with a pattern of color cells. + Such a pattern is defined by an array of color indices which is + mapped into a pattern rectangle whose lower left corner is + given by P.} + + + + + + + + + + + + + + + +Aguilar [Page 39] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + ASPECT SOURCE FLAGS + + | 'GKSM 43' | L | F | + + F(13i): aspect source flags + (0 = BUNDLED, 1 = INDIVIDUAL) + + {An application can set an output primitive attribute to either + bundled or individual. Bundled attributes are + workstation-dependent, their binding is delayed, and their + values can change dynamically. Individual attributes are global + attributes, they are bound immediately, and their value is + static and cannot be manipulated.} + + PICK IDENTIFIER + + | 'GKSM 44' | L | P | + + P(i): pick identifier + + E.8 Items for Workstation Attributes + + POLYLINE REPRESENTATION + + | 'GKSM 51' | L | I | LT | LW | CI | + + I(i): polyline index + LT(i): linetype number + LW(r): linewidth scale factor + CI(i): polyline colour index + + POLYMARKER REPRESENTATION + + | 'GKSM 52' | L | I | MT | MS | CI | + + I(i): polymarker index + MT(i): marker type + MS(r): marker size scale factor + CI(i): polymarker colour index + + + + + + + + + + +Aguilar [Page 40] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + TEXT REPRESENTATION + + | 'GKSM 53' | L | I | F | P | CEF | CS | CI | + + I(i): text index + F(i): text font + P(i): text precision + (0 = STRING, 1 = CHAR, 2 = STROKE) + CEF(r): character expansion factor + CS(r): character spacing + CI(i): text colour index + + FILL AREA REPRESENTATION + + | 'GKSM 54' | L | I | S | SI | CI | + + I(i): fill area index + S(i): fill area interior style + (0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH) SI(i): fill + area style index + CI(i): fill area colour index + + PATTERN REPRESENTATION + + | 'GKSM 55' | L | I | N | M | CT | + + I(i): pattern index + N(i): number of columns in array* + M(i): number of rows in array + CT(MNi): table of colour indices stores row by row + + {* The ANSI document reads "area" instead of "array".} + + {One style for filling areas is with a pattern of color cells. + Such a pattern is defined by a pattern representation.} + + COLOUR REPRESENTATION + + | 'GKSM 56' | L | CI | RGB | + + CI(i): colour index + RGB(3r): red, green, blue intensities + + + + + + + +Aguilar [Page 41] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + E.9 Items for Transformations + + CLIPPING RECTANGLE + + | 'GKSM 61' | L | C | + + C(4r): limits of clipping rectangle (XMIN, XMAX, YMIN, YMAX) + + WORKSTATION WINDOW + + | 'GKSM 71' | L | W | + + W(4r): limits of workstation window (XMIN, XMAX, YMIN, YMAX) + + {GKS includes a workstation transformation that maps a + rectangle of the NDC space (a workstation window) into a + rectangle of the device coordinate space (a workstation + viewport).} + + WORKSTATION VIEWPORT + + | 'GKSM 72' | L | V | + + V(4r): limits of workstation viewport (XMIN, XMAX, YMIN, YMAX) + + E.10 Items for Segment Manipulation + + CREATE SEGMENT + + | 'GKSM 81' | L | S | + + S(i): segment name + + CLOSE SEGMENT + + | 'GKSM 82' | L | + + indicates end of segment + + RENAME SEGMENT + + | 'GKSM 83' | L | SO | SN | + + SO(i): old segment name + SN(i): new segment name + + + + +Aguilar [Page 42] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + DELETE SEGMENT + + | 'GKSM 84' | L | S | + + S(i): segment name + + E.11 Items for Segment Attributes + + SET SEGMENT TRANSFORMATION + + | 'GKSM 91' | L | S | M | + + S(i): segment name + M(6r): transformation matrix + upper and center rows of a 3x3 matrix representing + a 2D homogeneous transformation [9] + M 11 M 12 M 13 M 21 M 22 M 23 + + {This differs from the ANSI X3.124 Jan. 5 1984 document, in the + matrix elements indicated. We believe there is an error in such + document.} + + SET VISIBILITY + + | 'GKSM 92' | L | S | V | + + S(i): segment name + V(i): visibility + (0 = VISIBLE, 1 = INVISIBLE) + + SET HIGHLIGHTING + + | 'GKSM 93' | L | S | H | + + S(i): segment name + H(i): highlighting + (0 = NORMAL, 1 = HIGHLIGHTED) + + SET SEGMENT PRIORITY + + | 'GKSM 94' | L | S | P | + + S(i): segment name + P(r): segment priority + + + + + +Aguilar [Page 43] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + SET DETECTABILITY + + | 'GKSM 95' | L | S | D | + + S(i): segment name + D(i): detectability + (0 = UNDETECTABLE, 1 = DETECTABLE) + + E.12 User Items + + USER ITEM + + | 'GKSMXXX' | L | D | + + XXX > 100 + D: user data (L bytes) + + {The PIGCF level U items are encoded as GKSM USER ITEM elements + so that a PIGCF file will conform to the GKSM metafile + specification.} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aguilar [Page 44] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + +APPENDIX B + + Example of PIGCF Use in Conferencing + + This section presents an example illustrating the proposed PIGCF + graphical component in an audio-graphics conference exchange. We + present only the graphical part of the conference exchange, which + actually would be complemented with speech. For the sake of briefness + the example does not contain all the parameter negotiation that a + conference set-up would require. + + The example is about an on-line audio-graphics conference between a + Navy command and control center and a Navy task force. The PIGCF + items shown do not belong to a single transmission stream. The stream + they belong to is determined by the station that transmits them, and + the identification of the transmitter belongs to lower level + communication protocols. We use the character encoding, rather than + the binary one, for this PIGCF example. We illustrate just a few of + the possible groups of items that could be batched in this example. + The plot of the example is as follows. + + The command center (center) establishes a conference with some ships + in a task force (platforms) to coordinate the interception of an + unidentified ship that has been sighted in a conflict area. After + recalling graphical libraries, all conference sites can see in their + screens a map of the sighting area as well as iconic representations + of the task force ships. Then the center interactively draws an + iconic representation of the unidentified vessel, scales it, and + places it in the sighting location. + + The platforms explain possible courses of action using graphical + pointers. The center draws the expected trajectory of the + unidentified ship and the platforms situate the task force icons at + the expected points of interception. Then the center zooms into the + interception area and the platforms use rubber bands to discuss + interception maneuvers. + + Now we proceed to list the PIGCF items exchanged. The center + initiates the conference graphical set-up with the FILE HEADER item + to set basic representation parameters for the graphical + information to be exchanged. This item can be interpreted + according to its definition in E.5 [14]. The most important + parameter selections for this example are: + + i) The items contain 0 characters of the "GKSM" string in the + identification field of the item header. + ii) The item type indicator field containing the PIGCF + + +Aguilar [Page 45] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + item number is three bytes long in each item. + iii) The integers are 4 bytes long, and the reals 6 bytes long. + iv) The item data record length indicator is 2 bytes long. + + We will obey the PIGCF specification field lengths and the aforesaid + field length settings. However, we will add one space before and + after the "|" separator to improve legibility. Also, every item will + be preceded with its name to help identification. + + FILE HEADER: + + | GKSM | center | 84/11/10 | 1 | 0 | 3 | 2 | 4 | 6 | 1 | 1 + | | | + + The center states the boundaries of the work station window for the + conference. + + WORKSTATION WINDOW: | 71 | 24 | 0.0 0.5 0.0 0.375 | + + In this example, we assume that the conferencing work stations use + world coordinates for the internal representation of positional + information. Accordingly, the center states the boundaries of the + world window for the normalization transformation used in the + conference. + + SET WINDOW: | 134 | 28 | 0.0 320.0 0.0 240.0 | + + The center informs the location of its local NDC viewport, however, + other conferees can choose different NDC viewports for the same + transformation, but their work station window should include the + conference's. All systems record the conference: world window, NDC + viewport, and work station widow. + + SET VIEWPORT: | 135 | 28 | 0.0 0.5 0.0 0.375 | + + The center recalls graphical libraries containing geographical maps + of the crisis area and icons of the task forces in the area. It + also displays a graphical object that provides a background picture. + + RECALL LIBRARY: | 139 | 9 | caribbean | + DISPLAY OBJECT: | 128 | 11 | coast_lines | + RECALL LIBRARY: | 139 | 10 | task_units | + + The center proceeds to instantiate one of the task forces in the + task_units library. This is done by recalling some of the library + objects and applying transformations to the objects, later. Since set + window, set viewport, and recall library belong to the update + + +Aguilar [Page 46] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + Group-2, they can be batched until display object, from update + Group-1, is entered. The second recall library can be batched + together with the following begin instantiation until display object + is produced. The rest of the example contains more cases of item + sequences which can be batched; however, for briefness we do not + indicate any more of them. + + BEGIN INSTANTIATION: | 124 | 15 | US_CONSTITUTION | + DISPLAY OBJECT: | 128 | 15 | US_CONSTITUTION | + TRANSFORM OBJECT: | 126 | 55 | 15 | US_CONSTITUTION | + 0.1 0.0 0.0 0.0 0.1 0.0 | + TRANSFORM OBJECT: | 126 | 55 | 15 | US_CONSTITUTION | + 0.1 0.0 0.312 0.0 0.1 0.078 | + END INSTANTIATION: | 125 | 0 | + + BEGIN INSTANTIATION: | 124 | 13 | US_NEW_JERSEY | + DISPLAY OBJECT: | 128 | 13 | US_NEW_JERSEY | + TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY | + 0.1 0.0 0.0 0.0 0.1 0.0 | + TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY | + 0.1 0.0 0.312 0.0 0.1 0.093 | + END INSTANTIATION: | 125 | 0 | + + Next the center sets values for two output primitive attributes in + preparation for drawing a new icon on the screens. We assume that all + the other attributes have been assigned default values as a result of + the conference set-up. + + POLYLINE INDEX: | 21 | 4 | 20 | + POLYLINE COLOUR INDEX: | 24 | 4 | 200 | + + The following items correspond to the interactive definition of the + unidentified vessel. Since the definition is done interactively, the + vessel image remains visible on the screens after definition. + + BEGIN DEFINITION: | 120 | 0 | + POLYLINE: | 11 | 64 | 5 | + 0.047 0.063 0.063 0.047 0.125 0.047 0.14 0.063 0.047 0.047 | + POLYLINE: | 11 | 52 | 3 | + 0.078 0.063 0.078 0.078 0.109 0.078 0.109 0.063 | + END DEFINITION: | 121 | 8 | sighting | + + Then the unidentified vessel "sighting" is scaled and placed at the + sighting site. + + + + + +Aguilar [Page 47] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + BEGIN INSTANTIATION: | 124 | 8 | sighting | + TRANSFORM OBJECT: | 126 | 48 | 8 | sighting | + 0.2 0.0 0.0 + 0.0 0.2 0.0 | + TRANSFORM OBJECT: | 126 | 48 | 8 | sighting | + 0.1 0.0 0.156 + 0.0 0.1 0.016 | + END INSTANTIATION: | 125 | 0 | + + The center and the platforms use graphical pointer movements to + discuss possible routes the unidentified vessel might follow. We only + show a few pointer updates. In practice, there would typically be a + large number of points transmitted to convey the movement of the + pointers over the screens. + + from the center: + + POINTER TRACKING: | 137 | 16 | 0 | 0.39 0.032 | + POINTER TRACKING: | 137 | 16 | 0 | 0.388 0.035 | + POINTER TRACKING: | 137 | 16 | 0 | 0.388 0.039 | + POINTER TRACKING: | 137 | 16 | 0 | 0.386 0.04 | + + from one of the platforms: + + POINTER TRACKING: | 137 | 16 | 0 | 0.22 0.016 | + POINTER TRACKING: | 137 | 16 | 0 | 0.222 0.159 | + POINTER TRACKING: | 137 | 16 | 0 | 0.233 0.157 | + POINTER TRACKING: | 137 | 16 | 0 | 0.24 0.155 | + + The center now draws the expected route to be followed by the + unidentified ship. This time the pointer trace is recorded on the + screen by drawing a line. + + POINTER TRACKING: | 137 | 16 | 1 | 0.388 0.038 | + POINTER TRACKING: | 137 | 16 | 1 | 0.386 0.038 | + POINTER TRACKING: | 137 | 16 | 1 | 0.386 0.052 | + POINTER TRACKING: | 137 | 16 | 1 | 0.375 0.078 | + POINTER TRACKING: | 137 | 16 | 1 | 0.369 0.105 | + POINTER TRACKING: | 137 | 16 | 1 | 0.361 0.125 | + POINTER TRACKING: | 137 | 16 | 1 | 0.352 0.144 | + POINTER TRACKING: | 137 | 16 | 1 | 0.351 0.156 | + POINTER TRACKING: | 137 | 16 | 1 | 0.35 0.16 | + + A platform moves the two US ship icons to interception positions. + + + + + +Aguilar [Page 48] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + TRANSFORM OBJECT: | 126 | 55 | 15 | US_CONSTITUTION | + 1.0 0.0 0.16 + 0.0 1.0 -0.046 | + TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY | + 1.0 0.0 0.113 + 0.0 1.0 -0.034 | + + The center zooms into the interception area in order to obtain a + larger view for further discussion. + + WORKSTATION WINDOW: | 71 | 24 | 0.286 0.403 0.077 0.177 | + + The two platforms indicate their striking ranges using circular + rubber bands centered at each ship. For each platform, we show first + the echo reference point and then two echo feedback points. Typically + there will be a large number of feedback points. + + RUBBER BAND: | 138 | 10 | 0 | 0.335 0.125 | + RUBBER BAND: | 138 | 10 | 3 | 0.35 0.128 | + RUBBER BAND: | 138 | 10 | 3 | 0.37 0.128 | + + RUBBER BAND: | 138 | 10 | 0 | 0.384 0.13 | + RUBBER BAND: | 138 | 10 | 3 | 0.367 0.128 | + RUBBER BAND: | 138 | 10 | 3 | 0.346 0.129 | + + Once the interception strategy has been agreed upon, the center zooms + out to the original, larger picture. + + WORKSTATION WINDOW: | 71 | 24 | 0.0 0.5 0.0 0.375 | + + The center terminates the conference + + END ITEM: | 0 | 0 | + + At the end of a conference, the final pictures remain visible on the + screens. In addition, the PIGCF items will be recorded in its + entirety in order to play back the conference session if necessary. + The conference record could also be sent to other locations as part + of a multi-media message. + + + + + + + + + + +Aguilar [Page 49] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + +REFERENCES + + [1] J. D. Day and H. Zimmermann, "The OSI Reference Model", + Proceedings of the IEEE, V 71, N 12; Dec. 1983, pp 1334-1340. + + [2] W. Pferd, L. A. Peralta and F. X. Prendergast, "Interactive + Graphics Teleconferencing", IEEE Computer, V 12, N 11; Nov. + 1979, pp 62-72. + + [3] K. S. Sarin, "Interactive On-Line Conferences", Ph.D. Diss. + MIT, Dept. of EE and CS, 1984. + + [4] S. Randall, "The Shared Graphic Workspace: Interactive Data + Sharing in a Teleconference Environment", Proceedings CompCon + 82 Fall, IEEE Computer Society, pp 535-542. + + [5] G. Heffron, "Teleconferencing Comes of Age", IEEE Spectrum, + Oct. 1984, pp 61-66, pp 61-66. + + [6] R. W. Hough and R. R. Panko, "Teleconferencing Systems: A + State-of-the-Art Survey and Preliminary Analysis", SRI + International, Menlo Park California, SRI project 3735, April + 1977. + + [7] C. W. Kelly III, "An Enhanced Presence Video Teleconferencing + System" Proc. CompCon 1982, Sept. 20-23 Washington D.C., pp + 544-551. + + [8] J. Vanglian, "Private Communication", Comments on the + suitability of videotex for on-line graphical communication. + + [9] ANSI Technical Committee X3H, "Draft Proposal: Virtual Device + Metafile", X3.122, X3 Secretariat, CBEMA, Washington, D.C. + + [10] American National Standards Committee X3H3, "Virtual Device + Interface", X3 - Information Processing Systems, Working + Document, Jan. 2, 1985 Available from Computer and Business + Equipment Manufacturers Association, Washington D.C. + + [11] E. Van Deusen, "Graphics Standards Handbook", CC Exchange 1984, + P.O. Box 1251, Laguna Beach, CA 92652. + + [12] J. D. Foley and A. Van Dam, "Fundamentals of Interactive + Computer Graphics", Addison-Wesley, 1982. + + + + + +Aguilar [Page 50] + + + +RFC 965 December 1985 +A Format for a Graphical Communication Protocol + + + [13] American National Standards Committee X3H3, "GKS -- 3D + Extensions", X3 - Information Processing Systems, Working + Document, Nov. 16 1984 Available from Computer and Business + Equipment Manufacturers Association, Washington D.C. + + [14] ANSI Technical Committee X3H3, "Draft Proposal: Graphical + Kernel System", X3.124, X3 Secretariat, CBEMA, Washington, D.C. + + [15] G. Enderle, K. Kansy, and G. Pfaff, "Computer Graphics + Programming", Springer-Verlag, 1984. + + [16] International Organization for Standardization "Information + processing - Representation of numerical values in character + strings for information interchange", ISO/DIS 6093.2, ISO/TC + 97, 1984-01-19; available from ANSI, New York, N.Y. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aguilar [Page 51] + |