home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 900s / rfc965.txt < prev    next >
Text File  |  1992-09-22  |  105KB  |  2,906 lines
  1. Network Working Group                                    Lorenzo Aguilar
  2. Request for Comments: 965                              SRI International
  3.                                                            December 1985
  4.  
  5.             A Format for a Graphical Communication Protocol
  6.  
  7.  
  8. STATUS OF THIS MEMO
  9.  
  10.    This paper describes the requirements for a graphical format on which
  11.    to base a graphical on-line communication protocol.  The proposal is
  12.    an Interactive Graphical Communication Format using the GKSM session
  13.    metafile.  Distribution of this memo is unlimited.
  14.  
  15. ABSTRACT
  16.  
  17.    This paper describes the requirements for a graphical format on which
  18.    to base a graphical on-line communication protocol. It is argued that
  19.    on-line graphical communication is similar to graphical session
  20.    capture, and thus we propose an Interactive Graphical Communication
  21.    Format using the GKSM session metafile.
  22.  
  23.    We discuss the items that we believe complement the GKSM metafile as
  24.    a format for on-line interactive exchanges. One key application area
  25.    of such a format is multi-media on-line conferencing; therefore, we
  26.    present a conferencing software architecture for processing the
  27.    proposed format. We make this format specification available to those
  28.    planning multi-media conferencing systems as a contribution toward
  29.    the development of a graphical communication protocol that will
  30.    permit the interoperation of these systems.
  31.  
  32.    We hope this contribution will encourage the discussion of multimedia
  33.    data exchange and the proposal of solutions. At SRI, we stay open to
  34.    the exploration of alternatives and we will continue our research and
  35.    development work in this problem area.
  36.  
  37. ACKNOWLEDGEMENTS
  38.  
  39.    The author wants to thank Andy Poggio of SRI who made many insightful
  40.    and valuable suggestions that trimmed and improved level U. His
  41.    expertise in multi-media communication systems and his encouragement
  42.    were a most positive input to the creation of this IGCF. Dave
  43.    Worthington of SRI also participated in the project discussions
  44.    involving this IGCF. Thanks are also due to Tom Powers, chairman of
  45.    ANSI X3H33, who opened this forum to the presentation of an earlier
  46.    version of this paper, thereby providing an opportunity for the
  47.    invaluable feedback of the X3H33 members. Jon Postel of ISI
  48.    recommended a number of changes that made this paper more coherent
  49.    and accessible.
  50.  
  51.  
  52.  
  53.  
  54. Aguilar                                                         [Page 1]
  55.  
  56.  
  57.  
  58. RFC 965                                                    December 1985
  59. A Format for a Graphical Communication Protocol
  60.  
  61.  
  62.    Most of the work reported in this paper was sponsored by the U.S.
  63.    Navy, Naval Electronic Systems Command, Washington D.C., under
  64.    Contract No. N00039-83-K-0623.
  65.  
  66. I.  INTRODUCTION
  67.  
  68.    A. Use of a Graphical Communication Protocol
  69.  
  70.       In the field of computer communications, a protocol is a procedure
  71.       executed by two cooperating processes in order to attain a
  72.       meaningful exchange of information. A graphical communication
  73.       protocol is needed to exchange interactive vector graphics
  74.       information, possibly in conjunction with other information media
  75.       like voice, text, and video. Within this multi-media communication
  76.       environment, computer vector graphics plays a key role because it
  77.       takes full advantage of the processing capabilities of
  78.       communicating computers and human users, and thus it is far more
  79.       compact than digital images which are not generated from data
  80.       structures containing positional information. Vector graphical
  81.       communication trades intensive use of storage and processing, at
  82.       the communicating ends, in return for a low volume of exchanged
  83.       data, because workstations with graphical hardware exchange
  84.       graphics commands in conjunction with large data structures at the
  85.       transmitter and receivers. In this manner, the transmission of a
  86.       single command can produce extensive changes in the data displayed
  87.       at the sending and receiving ends.
  88.  
  89.       It is helpful to situate the aforesaid protocol at one of the
  90.       functional levels of the ISO Open Systems Interconnection
  91.       Reference Model [1]. Within such a model, a graphical protocol
  92.       functionality belongs primarily in the application level, though
  93.       some of it fits in the presentation level.  We can distinguish the
  94.       following components of a communication protocol:
  95.  
  96.          a) a data format
  97.          b) rules to interpret transmitted data
  98.          c) state information tables
  99.          d) message exchange rules
  100.  
  101.       A format for a graphical protocol should provide the layout of the
  102.       transmitted data, and indicate how the formated data are
  103.       associated with interpretation rules. The choice of format
  104.       influences the state tables to be maintained for the correct
  105.       processing of the transmitted data stream. The graphical format
  106.       has a minor influence on the exchange rules, which should provide
  107.       for the efficient use of transmission capacity to transport the
  108.       data under such a format. Besides the graphical format, there are
  109.  
  110.  
  111. Aguilar                                                         [Page 2]
  112.  
  113.  
  114.  
  115. RFC 965                                                    December 1985
  116. A Format for a Graphical Communication Protocol
  117.  
  118.  
  119.       other aspects of a graphical protocol that determine state tables
  120.       and exchange rules. This paper concentrates in the data format,
  121.       and it does not discuss the message exchange. Nevertheless, we
  122.       discuss a simple software architecture for generating and
  123.       interpreting data streams written in our proposed format. Further,
  124.       we give an example of an application of a proposed format (in
  125.       Appendix B), and it illustrates the type of message exchanges that
  126.       are needed for establishing a communication session and exchanging
  127.       graphical information.
  128.  
  129.       Those in the computer communication field are well aware of the
  130.       importance of widely accepted protocols in order to achieve
  131.       meaningful communication. Those who need to implement interactive
  132.       graphical communications today are confronted with the lack of an
  133.       standard for computer graphics communication among application
  134.       programs. Nevertheless, we can use some of the work already done
  135.       by the computer graphics standard bodies. As a matter of fact, ISO
  136.       and ANSI have already appended, to the Graphical Kernel System
  137.       (GKS) standard, the GKSM session metafile specification that has
  138.       many of the features needed for an on-line graphical protocol.
  139.  
  140.       It is pertinent to mention an example of graphical communication
  141.       that illustrates the real-time nature of the interaction and also
  142.       illustrates the use of graphics in conjunction with other
  143.       information media. With audio-graphics conferencing, a group of
  144.       individuals at two or more locations can carry on an electronic
  145.       meeting. They can converse over voice channels and concurrently
  146.       share a graphics space on which they can display, point at, and
  147.       manipulate vector graphics pictures [2, 3, 4, 5, 6, 7].
  148.  
  149.       The conference voice channels can be provided by a variety of
  150.       transmission technologies. The shared graphics space can be
  151.       implemented on workstations that display the pictures and permit
  152.       graphical interaction and communication with other locations. The
  153.       communication of operations upon pictures involves modifications
  154.       to the underlying data structures, but we are concerned with
  155.       graphical database updating only to the extent that such updating
  156.       supports the communication.
  157.  
  158.       In order to play out a recorded graphical session, we will need
  159.       indications of the rate at which the graphical elements must be
  160.       shown and the graphical operations recreated. We do not include
  161.       the means for indicating the timing of a session in a format
  162.       because our main purpose is to use it in mixed-media communication
  163.       environments.  In these environments, the play-out timing must be
  164.       compatible across information media in order to coordinate them.
  165.       Therefore, we leave the timing mechanisms to conference-control
  166.  
  167.  
  168. Aguilar                                                         [Page 3]
  169.  
  170.  
  171.  
  172. RFC 965                                                    December 1985
  173. A Format for a Graphical Communication Protocol
  174.  
  175.  
  176.       modules. We also leave to conference control processes the manner
  177.       in which a conferee station emulates a graphical capability that
  178.       it lacks. One example is the representation of color in monochrome
  179.       displays.
  180.  
  181.    B. Relationship to Other Work
  182.  
  183.       There are a number of actual, and proposed, standards for graphics
  184.       information exchange. In the following, we explain the reasons
  185.       why, at present, none of them can be used as the basis of an
  186.       on-line protocol. As some of these standards evolve, however, some
  187.       may become suitable. Moreover, the experience gained with early
  188.       on-line graphics communication systems will provide insight into
  189.       the proper standard extensions to support more advanced systems.
  190.       Such insight could also be used to modify the format proposed in
  191.       this paper, which we consider an initial approach to the problem.
  192.       In the future, the format proposed in this paper could be replaced
  193.       by one of the aforesaid extended standards.
  194.  
  195.       The North American Presentation Level Protocol Syntax, NAPLPS,
  196.       specifies a data syntax and application semantics for one-way
  197.       teletext information dissemination and two-way videotex database
  198.       access and transaction services. The two-way videotex operational
  199.       model is based on the concept of a consumer and an information
  200.       provider or service operator. Because of this asymmetry, it is
  201.       assumed that almost all graphical information will flow from the
  202.       provider toward the consumer. In the reverse direction, the
  203.       consumer is expected to manipulate and transmit alphanumeric
  204.       information, for the most part. Although this standard includes
  205.       geometric drawing primitives, a user cannot directly modify shapes
  206.       drawn with the primitives.
  207.  
  208.       At present, NAPLPS does not include interaction concepts like
  209.       picture transformations or detectability, which are fundamental
  210.       for attaining a shared graphical workspace. Neither does it allow
  211.       key graphics input devices like mice, joysticks, stylus, rotating
  212.       balls, or light pens, which are needed for simple and efficient
  213.       editing of the shared workspace.
  214.  
  215.       We want to have user-to-user graphical communication that features
  216.       the level of sophistication and ease of interaction provided by
  217.       today's interactive graphics packages. Computer vector graphics
  218.       can provide both because its paradigm includes an application
  219.       program that keeps track of a very large number of possible
  220.       changes of state of the displayed picture. In addition, the
  221.       application drives a powerful graphics package, like GKS or ACM
  222.       Core. In the videotex paradigm, the provider application only
  223.  
  224.  
  225. Aguilar                                                         [Page 4]
  226.  
  227.  
  228.  
  229. RFC 965                                                    December 1985
  230. A Format for a Graphical Communication Protocol
  231.  
  232.  
  233.       allows limited changes to the displayed image, primarily database
  234.       retrieval requests. Also, the paradigm does not include a separate
  235.       graphics package. Both the graphics functionality and the data
  236.       format are collapsed into a coding specification, like NAPLPS.
  237.  
  238.       In this paper we are interested primarily in business and
  239.       industrial applications where there is a two-way, or multi-way,
  240.       flow of vector graphics information among the users. The users
  241.       will have workstations with substantial processing and storage
  242.       capacities, and high-resolution monitors; moreover, the
  243.       communication will be on a distributed architecture not depending
  244.       on a central server host, like the provider application host of
  245.       videotex.
  246.  
  247.       Currently, the videotex equipment at the consumer end consists of
  248.       inexpensive microprocessor-based decoders or personal computer
  249.       boards driving, in most cases, low-resolution standard TV sets and
  250.       personal computer displays. There is already affordable technology
  251.       to produce sophisticated decoders and high-resolution graphics
  252.       devices. The videotex standards need extensive revisions to take
  253.       advantage of these advances; in particular, they should consider
  254.       the receiving devices as capable of hosting a programmable
  255.       customer-application process. When this happens, videotex
  256.       protocols will be applicable to our intended problem areas [8].
  257.  
  258.       The Computer Graphics Metafile [9] will become an international
  259.       and North American standard for graphics picture interchange in
  260.       the near future. However, the CGM, also referred as VDM, is a
  261.       picture-capture metafile that only records the final result of a
  262.       graphics session. It is not intended to record the
  263.       picture-creation process, which is fundamental for the interactive
  264.       applications that we are addressing. Moreover, the CGM is
  265.       presently aimed at a minimum support of GKS functionality. It will
  266.       be some time before the CGM will have some of the elements needed
  267.       for on-line interaction. If, after these additions, the CGM is
  268.       augmented for session capture, it would become a logical candidate
  269.       for a protocol format.
  270.  
  271.       Another future standard is the Computer Graphics Interface, CGI
  272.       also referred as VDI [10]. The CGI is a standard functional and
  273.       syntactical specification of the control and data exchange between
  274.       device-independent graphics software and one or more
  275.       device-dependent graphics device drivers. A major use of the CGI
  276.       is for the communication between an application host and a
  277.       graphics device, but the asymmetry between its intended
  278.       communicating ends hinders the use of CGI for our purposes.
  279.  
  280.  
  281.  
  282. Aguilar                                                         [Page 5]
  283.  
  284.  
  285.  
  286. RFC 965                                                    December 1985
  287. A Format for a Graphical Communication Protocol
  288.  
  289.  
  290.       As previously stated, we want to take advantage of intelligence
  291.       and storage at the communicating ends in order to achieve powerful
  292.       information-conveying effects using narrow-bandwidth channels.
  293.       This requires that the format we seek must have items for
  294.       communication between two applications. In contrast, the CGI
  295.       streams are processed by device-dependent drivers, rather than by
  296.       applications. The CGI specification does include application data
  297.       elements, but only to be stored in a metafile. These application
  298.       data elements are not interpreted by the drivers, but by
  299.       applications that read the metafile, some time after metafile
  300.       creation.
  301.  
  302.       Furthermore, the CGI has elements for obtaining graphical input,
  303.       as well as elements for inquiring graphics device capabilities,
  304.       characteristics, and states. Later, in Section III, we explain why
  305.       these two classes of elements are unnecessary for the
  306.       communication protocol we need. As the CGI evolves, it will
  307.       undergo significant changes, and, in the future, it may become a
  308.       very suitable kernel for the graphics protocol we seek.  As a
  309.       matter of fact, the CGI will be the communication protocol between
  310.       graphical application hosts and graphics terminals.  At SRI we are
  311.       tracking its evolution, and we are interested in defining a format
  312.       based on the CGI.
  313.  
  314.       Finally, the Initial Graphics Exchange Specification [11] is not
  315.       aimed at our primary area of interest. The IGES defines standard
  316.       file and language formats for storing and transmitting
  317.       product-definition data that can be used, in part, to generate
  318.       engineering drawings and other graphical representations of
  319.       engineering products.  Besides the CAD orientation of IGES, the
  320.       graphical output function may be secondary to other goals like
  321.       transmitting numerical-control machine instructions.
  322.  
  323. II.  OPERATIONAL REQUIREMENTS AND USABILITY
  324.  
  325.    The main goal of this paper is to lay the groundwork for the
  326.    development of a vector graphics format to be used as a basis for an
  327.    on-line graphical communication protocol. We call such a format an
  328.    "interactive graphical communication format," or IGCF. In this
  329.    section we describe some operational requirements and usable
  330.    characteristics for an IGCF.
  331.  
  332.    A. Interoperation of Heterogeneous Systems
  333.  
  334.       A first functional requirement is that an IGCF must permit
  335.       communication among heterogeneous graphical systems differing both
  336.       in the hardware used and in the software of their graphics
  337.  
  338.  
  339. Aguilar                                                         [Page 6]
  340.  
  341.  
  342.  
  343. RFC 965                                                    December 1985
  344. A Format for a Graphical Communication Protocol
  345.  
  346.  
  347.       application interfaces. This is a fundamental for attaining
  348.       communication among similar graphical application programs running
  349.       on dissimilar hardware and using dissimilar graphics interface
  350.       packages. Some examples of such application programs are graphics
  351.       editors, CAD systems, and graphical database retrieval programs
  352.       communicating with other editors, CAD programs, and graphical
  353.       databases, respectively.
  354.  
  355.    B. Picture Capture
  356.  
  357.       A required characteristic of an IGCF is that it must be usable for
  358.       the exchange of static graphic pictures, i.e. for picture capture;
  359.       yet, it must not be restricted to final picture recording only.
  360.       There will be picture exchanges as part of the interactive
  361.       communication, and we anticipate the need to record the state of a
  362.       picture at some points during the on-line graphics engagement. We
  363.       foresee the creation of graphical IGCF libraries containing object
  364.       definitions and pictures for inclusion in new pictures. Since
  365.       metafiles have been used for a long time to capture pictures,
  366.       there is a strong motivation to base an IGCF on a metafile
  367.       standard in order to secure compatibility with a large number of
  368.       metafile sources and consumers.
  369.  
  370.    C. Prompt Transmission
  371.  
  372.       In some forms of interactive graphical communication, like
  373.       audiographics conferencing, it is critical to convey across users
  374.       the real-time nature of the interaction. This dictates that object
  375.       creations and manipulations be transmitted as they happen rather
  376.       than as a final result since a substantial part of the information
  377.       may be transmitted concurrently with the construction or operation
  378.       of an object, possibly through associated media like voice. Since
  379.       both construction and manipulation processes have to be
  380.       transmitted, there is a limit to the number of intermediate states
  381.       that can be economically transmitted.
  382.  
  383.       A third requirement is, therefore, that the IGCF elements provide
  384.       fine "granularity" to convey the dynamics of the constructions and
  385.       manipulations. We believe that it is sufficient that the IGCF have
  386.       basic construction elements like polygons, markers, polylines, and
  387.       text strings and that it transmit them only when they are
  388.       completed; i.e., it is not necessary to transmit partial
  389.       constructions of such elements.
  390.  
  391.       The problem for manipulations extends beyond an IGCF. Whereas we
  392.       know that an IGCF should include segment transformations, segment
  393.       highlighting and segment visibility on/off, the transmitter must
  394.  
  395.  
  396. Aguilar                                                         [Page 7]
  397.  
  398.  
  399.  
  400. RFC 965                                                    December 1985
  401. A Format for a Graphical Communication Protocol
  402.  
  403.  
  404.       decide how often to sample an on-going transformation and transmit
  405.       its current state. The choice of a sampling frequency will depend
  406.       on the available transmission bandwidth.
  407.  
  408.    D. Low Traffic Volume
  409.  
  410.       In many of the applications we envision, coordinate graphics will
  411.       be transmitted over narrow bandwidth channels, and thus it is
  412.       essential to minimize traffic. Accordingly, several requirements
  413.       are imposed on an IGCF to take advantage of the characteristics of
  414.       the graphics communication intercourse and architecture in order
  415.       to minimize traffic.
  416.  
  417.       An IGCF can help reduce traffic by including the basic geometric
  418.       objects from which so many other objects are built. Moreover, an
  419.       IGCF should permit the use of objects for the creation of more
  420.       complex objects; since reuse is very common, the result is a
  421.       reduction of traffic and storage cost.
  422.  
  423.    E. Preservation of Application Semantic Units
  424.  
  425.       A related requirement is that an IGCF must include elements to
  426.       represent graphical objects corresponding to real world entities
  427.       of the intended applications. For example, in a Navy application,
  428.       the entities of interest are carriers, submarines, planes, and the
  429.       like. We want to communicate such semantic units across systems
  430.       and to treat them as unitary objects because, in many
  431.       applications, communication is based on creating and operating
  432.       such units. If an IGCF has elements to represent such semantic
  433.       units, the communication traffic decreases because the entity
  434.       definitions can be transmitted only once and then reused, and
  435.       because the entities are manipulated as units rather than
  436.       separately manipulating their components.
  437.  
  438.       It turns out that there is a small set of primary operations that
  439.       can be applied to a graphical object, and an IGCF must have
  440.       elements representing such operations. In contrast to dumb
  441.       graphics terminals receiving screen refresh information from a
  442.       host, we foresee graphical communication taking place among
  443.       intelligent workstations that can exchange encoded operations,
  444.       interpret them, and apply them to objects stored locally.
  445.  
  446.    F. Transmission Batching
  447.  
  448.       We previously indicated the desirability of conveying to the human
  449.       users the real-time tempo of interactive graphics exchanges.
  450.       However, it is possible to do so without having to transmit
  451.  
  452.  
  453. Aguilar                                                         [Page 8]
  454.  
  455.  
  456.  
  457. RFC 965                                                    December 1985
  458. A Format for a Graphical Communication Protocol
  459.  
  460.  
  461.       immediately all IGCF elements. As a matter of fact, IGCF elements
  462.       should be divided into those causing a change on a displayed
  463.       picture and those that do not, although both classes may cause
  464.       changes to the stored graphical data structures.
  465.  
  466.       It is only necessary to transmit immediately those elements
  467.       causing a visible change on a displayed picture because they are
  468.       the ones whose reception and interpretation delivers information
  469.       to a human user. The second class of elements can be batched and
  470.       queued for transmission until one element of the first class is
  471.       submitted. We call the first class update Group-1, and the second,
  472.       update Group-2.
  473.  
  474.       The aforesaid division is quite important for packet
  475.       communications because each packet contains a hefty amount of
  476.       overhead control traffic. It is therefore mandatory to batch, into
  477.       a packet, as much client data as possible in order to reduce total
  478.       traffic. The batching units can be varied in size according to the
  479.       network traffic and response time of conference hosts. During
  480.       congested periods, the units may have to be increased, thus
  481.       lowering the number of messages, and then reduced when congestion
  482.       eases, thus increasing the number of messages.
  483.  
  484.    G. Simple Translation Between IGCF and User Interface
  485.  
  486.       According to the first requirement, an IGCF must permit the
  487.       interoperation of related heterogeneous graphics applications.
  488.       Such interoperation has, as an objective, the communication
  489.       between human users or between a human and a database.
  490.       Correspondingly, the interoperation involves a mapping between the
  491.       user interface commands and the IGCF elements. It is not advisable
  492.       to use the commands themselves as the IGCF elements; otherwise the
  493.       exchange would depend on the communicating systems, and every pair
  494.       of communicating systems would require an ad-hoc protocol.
  495.  
  496.       An additional usability characteristic is that there must be a
  497.       simple mapping between IGCF elements and the actions represented
  498.       by the user interface commands employed for graphical
  499.       communications. This simplicity is a must because every
  500.       communicating graphical system must have a translator that ideally
  501.       should be very simple. It seems that the inclusion of command
  502.       sequence delimiters in the IGCF helps the simplicity since the
  503.       delimiters permit keeping a smaller amount of state information
  504.       for processing an IGCF stream.
  505.  
  506.       We have verified the mapping from one set of commands for
  507.       audiographics conferencing to the IGCF proposed in this paper. The
  508.  
  509.  
  510. Aguilar                                                         [Page 9]
  511.  
  512.  
  513.  
  514. RFC 965                                                    December 1985
  515. A Format for a Graphical Communication Protocol
  516.  
  517.  
  518.       mapping from user interface commands to IGCF can be done in a
  519.       direct and efficient manner; on the other hand, the reverse
  520.       mapping, from IGCF to user interface commands, is a more difficult
  521.       task. We anticipate that, in order to improve performance, we will
  522.       have to map the IGCF elements to calls to lower level subroutines
  523.       implementing the user interface actions. Whereas such mapping is
  524.       conceptually no more complex than translating IGCF to the commands
  525.       themselves, it will require considerably more programming.
  526.  
  527. III.  ELEMENTS OF AN IGCF
  528.  
  529.    IGCF Element Classes
  530.  
  531.       In this section we list the classes of elements that we believe an
  532.       IGCF should have in order to exchange vector graphics under the
  533.       requirements of the previous section. The classes correspond to
  534.       the common function classes in computer graphics interfaces, and
  535.       each contains elements corresponding to interface primitives and
  536.       attributes. We do not list the elements for each class because
  537.       they are exemplified by the elements in the proposed IGCF.
  538.  
  539.       In the following list, two categories of functions are missing:
  540.       functions used to query the status of a graphics system, and input
  541.       functions. As a matter of fact, an IGCF only needs to have
  542.       elements representing actions that cause a change in the state of
  543.       the communicating graphical systems, and the inquire functions
  544.       obviously do not change their state. Even though an input function
  545.       executed at the transmitting end causes a local change, it is not
  546.       necessary to transmit the input command itself. The receivers only
  547.       need to get the data input, in IGCF representation, and they can
  548.       process the data in any manner, maybe simulating local input
  549.       actions.
  550.  
  551.       Control
  552.  
  553.          Elements for workstation: initialization, control and
  554.          transformation; and elements for normalization transformation.
  555.          (The normalization and workstation transformations can be used
  556.          to implement zooming.)
  557.  
  558.       Primitive attributes
  559.  
  560.          Elements for primitive, segment, and workstation attributes.
  561.  
  562.       Output primitives
  563.  
  564.          Elements for output primitives.
  565.  
  566.  
  567. Aguilar                                                        [Page 10]
  568.  
  569.  
  570.  
  571. RFC 965                                                    December 1985
  572. A Format for a Graphical Communication Protocol
  573.  
  574.  
  575.       Segmentation
  576.  
  577.          Elements for basic segmentation and workstation independent
  578.          segment storage.
  579.  
  580.          Object manipulations can be implemented with segment
  581.          transformations. Object insertion can be implemented using
  582.          segment recall and segment visibility. Object deletion can be
  583.          implemented using segment deletion and segment visibility.
  584.          Object selection can use segment highlighting as feedback to
  585.          the user.
  586.  
  587.       Dynamics
  588.  
  589.          A considerable part of the graphical information exchanged
  590.          through an IGCF will be in the form of pointer movements over a
  591.          background picture. Pointer tracking is used to transmit points
  592.          sampled from a graphical pointer trace in order to reproduce,
  593.          at the receivers, the movement of the pointer at the sender
  594.          site. This can be done either by just moving the cursor or by
  595.          tracing its movement with a line. Rubber band echoes are used
  596.          to signal areas, routes, and scopes in a highly dynamic way.
  597.          These are indicated by an echo reference point and a feedback
  598.          point.
  599.  
  600.    Hierarchical object definitions
  601.  
  602.       The requirement for preserving application semantics dictated that
  603.       an IGCF include the means to represent objects that stand for
  604.       application entities, and to manipulate such entities as graphical
  605.       units. Furthermore, the low-traffic-volume requirement called for
  606.       the use of already existing objects for the creation of new ones.
  607.  
  608.       One way to meet the aforesaid requirements is by including in an
  609.       IGCF the means to represent object hierarchies. In such a
  610.       hierarchy an object is a set of output primitives associated with
  611.       a set of attribute values or a set of lower-level objects, each
  612.       associated with a composition of transformations [12].
  613.  
  614.       Graphics segments can be used to implement objects in the lowest
  615.       level of a hierarchy. The definition of a higher-level object can
  616.       be represented by sequences of IGCF elements describing the
  617.       definition process. Such a definition can be done by instantiating
  618.       lower-level objects with specific transformation parameters. Thus
  619.       an IGCF must incorporate brackets to mark the beginning and end of
  620.       object definitions, object instantiations, and object
  621.       redefinitions.
  622.  
  623.  
  624. Aguilar                                                        [Page 11]
  625.  
  626.  
  627.  
  628. RFC 965                                                    December 1985
  629. A Format for a Graphical Communication Protocol
  630.  
  631.  
  632.       In order to complement the mechanism for object definition, an
  633.       IGCF must permit the use of a flexible alphabet for creating
  634.       object identifiers that ensure the uniqueness of an identifier in
  635.       a hierarchy. The construction of the object identifiers is not
  636.       part of an IGCF, an IGCF only has to represent the identifiers.
  637.       Further, an identifier has to be independent of a communication
  638.       session and a particular graphics system so that identifiers
  639.       created at a host during one session can be used, in other
  640.       sessions possibly involving other hosts, to recall the objects
  641.       they label.
  642.  
  643.       We also leave to the communicating systems the implementation of
  644.       mechanisms to resolve duplicate identifiers when merging two
  645.       hierarchies, created in different sessions. In this paper we shall
  646.       limit ourselves to the warning that segment numbers do not qualify
  647.       as identifiers because they depend on the session and state of the
  648.       system in which they are created.
  649.  
  650.       In addition to object definition and instantiation, an IGCF should
  651.       have elements representing operations on objects. The operations
  652.       so far identified are: transformation, deletion, display,
  653.       disappearance, expose, and hide. Expose is used to uncover objects
  654.       on a screen that are hidden by other objects; hide is used to
  655.       place an object behind others on a screen.
  656.  
  657. IV.  A PROPOSED IGCF
  658.  
  659.    A. Using the GKSM as a Basis
  660.  
  661.       An IGCF must be usable to transmit all graphical actions in a
  662.       conference session. This suggests to base an IGCF on a standard
  663.       session-capture graphics metafile, thus ensuring compatibility
  664.       with a large user population. We have based the proposed IGCF,
  665.       PIGCF, on the GKSM session-capture metafile specification because
  666.       GKSM contains many of the elements identified for an IGCF [14]. In
  667.       addition, the audit trail orientation of GKSM permits the
  668.       recording of interactive communication sessions for later play
  669.       out, and this is a feature that we anticipate will be frequently
  670.       used.
  671.  
  672.       The GKSM is a proper subset of our PIGCF and thus any graphical
  673.       system developed to handle the PIGCF, can read a GKSM metafile.
  674.       Conversely, the applications using the PIGCF should have an option
  675.       for constraining session recording only to the GKSM part, possibly
  676.       suppressing some session events.  By doing so, we will be able to
  677.       ship a GKSM metafile to any correspondent who has GKSM
  678.  
  679.  
  680.  
  681. Aguilar                                                        [Page 12]
  682.  
  683.  
  684.  
  685. RFC 965                                                    December 1985
  686. A Format for a Graphical Communication Protocol
  687.  
  688.  
  689.       interpretation software.  Alternatively, an application with a
  690.       GKSM interpreter but without an PIGCF interpreter can read a PIGCF
  691.       file interpreting only the GKSM part and ignoring the rest.
  692.  
  693.       Whereas the GKSM was specified for the GKS system, we believe that
  694.       the GKSM is a sound and general basis for all of our 2-D
  695.       applications. We feel that the GKSM specification is not parochial
  696.       to GKS systems but contains all the most useful items desired in a
  697.       metafile. In the future, we expect to tackle applications
  698.       requiring 3-D, like interactive repair and maintenance aids. When
  699.       GKS be augmented with 3-D capabilities [13], we will extend the
  700.       PIGCF with any necessary elements.
  701.  
  702.       We are aware that the GKSM specification is not part of the GKS
  703.       standard itself but is an appendix recommending such a metafile
  704.       format. Nevertheless, all the GKS vendor implementations that we
  705.       know of, at the present time, support GKSM metafile output and
  706.       interpretation. If this trend continues, as we expect, we will be
  707.       able to exchange graphical files with a large base of GKS
  708.       installations. There will indeed be many of them since GKS will be
  709.       adopted as an standard by ISO and by many national standard bodies
  710.       in the near future.
  711.  
  712.    B. Positional Information Coordinates
  713.  
  714.       Following the GKSM convention, the PIGCF positional information is
  715.       in normalized device coordinates, NDC. Thus the originator of a
  716.       conference must indicate the workstation window for the
  717.       conference. This window is the sub-rectangle of the NDC space
  718.       enclosing the area of interest for the conference. In most cases,
  719.       the participating workstations will take this window as their own.
  720.       However, the graphical systems should provide for the possibility
  721.       of a workstation choosing a different workstation window, which
  722.       may contain the conference window or just overlap it. Except for
  723.       special cases, a conference originator should not state a
  724.       conference workstation viewport. In this manner, each workstation
  725.       can display its workstation viewport in the most convenient
  726.       portion of the screen.
  727.  
  728.       There will be conferences where the participating workstations
  729.       will maintain the positional information in world coordinates, WC.
  730.       It might be necessary to reconstruct the world dimensions after
  731.       transmission because such dimensions have a relevant meaning for
  732.       the application, like sizes of components or distances. In this
  733.       case, a workstation will have to map from WC to NDC before
  734.       transmitting and from NDC to WC after receiving. At the outset,
  735.       the conference originator has to specify the world window and the
  736.  
  737.  
  738. Aguilar                                                        [Page 13]
  739.  
  740.  
  741.  
  742. RFC 965                                                    December 1985
  743. A Format for a Graphical Communication Protocol
  744.  
  745.  
  746.       NDC viewport used in the conference in order for the conferencing
  747.       workstations to do such mappings. These mappings could be done by
  748.       the presentation layer, in terms of the ISO Open Systems
  749.       Interconnection Reference Model, in a manner that is transparent
  750.       to the communicating application programs.
  751.  
  752.       Most often all workstations will have the same world windows and
  753.       NDC viewports. However, the graphical systems will provide for the
  754.       possibility of a workstation choosing a different window or
  755.       viewport, but such workstation will have to record the conference
  756.       ones for doing the aforesaid mappings. There are graphical
  757.       systems, like the ACM Core, that do not provide for a workstation
  758.       transformation. In such systems, the NDC viewport is considered to
  759.       be the workstation window for the aforesaid mappings.
  760.  
  761.    C. Layers of the PIGCF
  762.  
  763.       There are two levels in the PIGCF a lower level L and an upper one
  764.       U. The lower level L is just the GKSM metafile specification as
  765.       defined in Appendix E of the proposed GKS ANSI standard [14].  We
  766.       have excerpted most of Appendix E of [14] at the end of this RFC
  767.       as our Appendix A.  All level L elements belong to the update
  768.       Group-1 except: SET DEFERRAL STATE, the output primitive attribute
  769.       elements, the workstation attribute elements, CLIPPING RECTANGLE,
  770.       CREATE SEGMENT, CLOSE SEGMENT, RENAME SEGMENT, SET SEGMENT
  771.       PRIORITY, and SET DETECTABILITY.
  772.  
  773.       The upper level U is those elements that we believe complement the
  774.       GKSM for general on-line graphical exchanges. This layering
  775.       conforms to the graphics metafile level-structure described in
  776.       Enderle et. al [15]. Under such structuring, an application
  777.       oriented metafile can be based on graphical metafiles.
  778.  
  779.    D. PIGCF Elements in the Level U
  780.  
  781.       The level U items are encoded as GKSM user item elements so that a
  782.       PIGCF file will conform to the GKSM metafile specification.
  783.       Accordingly, a PIGCF file will be a GKSM metafile in its entirety.
  784.       We use the same formatting conventions as the GKSM specification.
  785.       Those unfamiliar with these conventions should read the beginning
  786.       of the appendix. The following items belong to the second update
  787.       group: the two items for object definition, the two items for
  788.       object redefinition, the two items for object instantiation, the
  789.       two items for normalization transformation, SELECT COMPONENT, and
  790.       RECALL LIBRARY. The remaining items belong to the first update
  791.       group.
  792.  
  793.  
  794.  
  795. Aguilar                                                        [Page 14]
  796.  
  797.  
  798.  
  799. RFC 965                                                    December 1985
  800. A Format for a Graphical Communication Protocol
  801.  
  802.  
  803.       Items for Object Definition
  804.  
  805.          BEGIN DEFINITION
  806.  
  807.             | 'GKSM 120' | L |
  808.  
  809.             Indicates beginning of object definition sequence
  810.  
  811.          END DEFINITION
  812.  
  813.             | 'GKSM 121' | L | I |
  814.  
  815.             Indicates end of object definition sequence. I(Nc): object
  816.             identifier ( N preceding c, i, r means an arbitrary number
  817.             of characters, integers, or reals.) Objects defined
  818.             interactively are made visible on the screen; i.e. they are
  819.             automatically instantiated. If only the definition is to be
  820.             kept but not the image, a DISAPPEAR item must follow.
  821.  
  822.          BEGIN REDEFINITION
  823.  
  824.             | 'GKSM 122' | L | I |
  825.  
  826.             Indicates beginning of object redefinition sequence
  827.             I(Nc): object identifier
  828.  
  829.          END REDEFINITION
  830.  
  831.             | 'GKSM 123' | L |
  832.  
  833.             Indicates end of object redefinition sequence
  834.  
  835.       Items for Object Instantiation
  836.  
  837.          BEGIN INSTANTIATION
  838.  
  839.             | 'GKSM 124' | L | I |
  840.  
  841.             Indicates beginning of object instantiation sequence
  842.             I(Nc): Object identifier
  843.  
  844.          END INSTANTIATION
  845.  
  846.             | 'GKSM 125' | L |
  847.  
  848.             Indicates end of object instantiation sequence
  849.  
  850.  
  851.  
  852. Aguilar                                                        [Page 15]
  853.  
  854.  
  855.  
  856. RFC 965                                                    December 1985
  857. A Format for a Graphical Communication Protocol
  858.  
  859.  
  860.       Items for Object Manipulation
  861.  
  862.          TRANSFORM OBJECT
  863.  
  864.             | 'GKSM 126' | L | C | I | M |
  865.  
  866.             Apply transformation M to object I
  867.             C: number of characters in identifier
  868.             I(Nc): object id
  869.             M(6r): upper and center rows of a 3x3 matrix representing
  870.                    a 2D homogeneous transformation [12].
  871.                    M 11 M 12 M 13 M 21 M 22 M 23
  872.  
  873.          DELETE OBJECT
  874.  
  875.             | 'GKSM 127' | L | I |
  876.  
  877.             I(Nc): object identifier
  878.  
  879.          DISPLAY OBJECT
  880.  
  881.             | 'GKSM 128' | L | I |
  882.  
  883.             Turn on visibility of object I
  884.             I(Nc): object identifier
  885.  
  886.          DISAPPEAR OBJECT
  887.  
  888.             | 'GKSM 129' | L | I |
  889.  
  890.             Turn off visibility of object I
  891.             I(Nc): object identifier
  892.  
  893.          EXPOSE OBJECT
  894.  
  895.             | 'GKSM 130' | L | I |
  896.  
  897.             Redisplay object I on top of any overlapping objects
  898.             I(c):  object identifier
  899.  
  900.          HIDE OBJECT
  901.  
  902.             | 'GKSM 131' | L | I |
  903.  
  904.             Redisplay object I behind any overlapping objects
  905.             I(c):  object identifier
  906.  
  907.  
  908.  
  909. Aguilar                                                        [Page 16]
  910.  
  911.  
  912.  
  913. RFC 965                                                    December 1985
  914. A Format for a Graphical Communication Protocol
  915.  
  916.  
  917.          SELECT COMPONENT
  918.  
  919.             | 'GKSM 132' | L | I | P |
  920.  
  921.             Select component P of object I
  922.             I(c):  object identifier
  923.             P(i):  pick id of component
  924.             This is used to select a group of output primitives
  925.             identified by P in a segment associated with I.
  926.  
  927.          ERASE COMPONENT
  928.  
  929.             | 'GKSM 133' | L | I | P |
  930.  
  931.             Erase component P of object I
  932.             I(c):  object identifier
  933.             P(i):  pick id of component
  934.  
  935.             This erases a group of output primitives identified by P in
  936.             a segment associated with I. This element can be used only
  937.             within a REDEFINE OBJECT sequence.
  938.  
  939.       Items for Normalization Transformation
  940.  
  941.          SET WINDOW
  942.  
  943.             | 'GKSM 134' | L | W |
  944.  
  945.             Define boundaries of world window for normalization
  946.             transformation.
  947.             W(4r): limits of world window (XMIN, XMAX, YMIN, YMAX )
  948.  
  949.          SET VIEWPORT
  950.  
  951.             | 'GKSM 135' | L | V |
  952.  
  953.             Define boundaries of NDC viewport for normalization
  954.             transformation.
  955.             V(4r): limits of NDC viewport (XMIN, XMAX, YMIN, YMAX )
  956.  
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966. Aguilar                                                        [Page 17]
  967.  
  968.  
  969.  
  970. RFC 965                                                    December 1985
  971. A Format for a Graphical Communication Protocol
  972.  
  973.  
  974.       Items for Other Operations
  975.  
  976.          ABORT
  977.  
  978.             | 'GKSM 136' | L |
  979.  
  980.             Abort ongoing operation transmitted in PIGCF stream. This
  981.             provides the means to abort unwanted or erroneous
  982.             operations. Only the innermost operation of a nested
  983.             sequence is aborted; successive aborts can be used to get
  984.             out of several levels of operation nesting.
  985.  
  986.          POINTER TRACKING
  987.  
  988.             | 'GKSM 137' | L | T | P |
  989.  
  990.             Update graphical pointer position to P
  991.             T(i):  0 causes only cursor to be moved
  992.                    1 causes cursor movement to be traced with
  993.                    a line
  994.             P(p):  a point sampled from graphical pointer
  995.                    movement trace
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023. Aguilar                                                        [Page 18]
  1024.  
  1025.  
  1026.  
  1027. RFC 965                                                    December 1985
  1028. A Format for a Graphical Communication Protocol
  1029.  
  1030.  
  1031.          RUBBER BAND
  1032.  
  1033.             | 'GKSM 138' | L | T | P |
  1034.  
  1035.             Echo a rubber band of type T with given reference and
  1036.             feedback points. The first occurrence of this item in a
  1037.             sequence carries the coordinates of the echo reference
  1038.             point. Subsequent occurrences carry updates to a pointer
  1039.             position indicating an echo feedback point.
  1040.  
  1041.             T(i):  echo type
  1042.                    ( 0 echo reference point;
  1043.                    > 0 echo feedback:
  1044.                      1 = line,
  1045.                      2 = rectangle,
  1046.                      3 = circle )
  1047.             P(r):  echo reference point (T = 0),
  1048.                    or echo feedback point (T > 0)
  1049.  
  1050.                The reference and feedback points are:
  1051.                   T = 1 - reference is one end of line, feedback is
  1052.                           other end.
  1053.                   T = 2 - reference is one corner of rectangle, feedback
  1054.                           is opposite corner.
  1055.                   T = 3 - reference is center of circle, feedback is
  1056.                           perimeter point.
  1057.  
  1058.          RECALL LIBRARY
  1059.  
  1060.             | 'GKSM 139' | L | F |
  1061.  
  1062.             Recall graphical library in file F
  1063.             F(i):  name of file containing library
  1064.  
  1065.             The graphical pictures in F and all their components become
  1066.             available for use during the communication session. The
  1067.             pictures are assumed to be recorded with the PIGCF, and
  1068.             their components have to be displayed with DISPLAY OBJECT
  1069.             elements or similar actions so that the pictures become
  1070.             visible.
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080. Aguilar                                                        [Page 19]
  1081.  
  1082.  
  1083.  
  1084. RFC 965                                                    December 1985
  1085. A Format for a Graphical Communication Protocol
  1086.  
  1087.  
  1088. V.  AN ARCHITECTURE FOR PIGCF PROCESSING
  1089.  
  1090.    This section presents an example software architecture for the
  1091.    generation and interpretation of PIGCF in a multimedia conferencing
  1092.    system using GKS as the underlying programmer's graphics interface.
  1093.    This section should not be interpreted as a definitive statement of
  1094.    such an architecture, but only as an exercise to illustrate how the
  1095.    format proposed in this paper fits within the overall framework of a
  1096.    conferencing system. Choosing GKS simplifies the example
  1097.    architecture; nevertheless, other graphics packages can be used by
  1098.    adding, to the architecture, the modules to interpret and generate
  1099.    the PIGCF level L items.
  1100.  
  1101.    Figure 1 shows the major software modules charged with graphics
  1102.    interaction and display at a conferencing workstation. This is a
  1103.    familiar programmer's view of the graphics pipeline. A conferencing
  1104.    application program updates data structures and uses
  1105.    device-independent graphics services through a language binding.
  1106.    These services, in turn, use device-dependent graphics services that
  1107.    call on device drivers to accept input and to present graphic
  1108.    pictures. The application performs numerous other functions for
  1109.    conference management and control of other media streams, but we need
  1110.    not consider them in this example.
  1111.  
  1112.    In Figure 2, the basic graphics pipeline has been augmented with the
  1113.    software modules involved in the generation, transmission, reception,
  1114.    and interpretation of PIGCF streams. The application has a module for
  1115.    interpreting the lower and higher levels of PIGCF and one for
  1116.    generating the upper level U. The device-independent graphics
  1117.    services include modules for generating and interpreting the lower
  1118.    level, L. This reflects the current practice of including the
  1119.    generation and interpretation functions in the graphics package.
  1120.    There is also a module that transmits the outgoing PIGCF streams to
  1121.    remote work stations. Similarly, there is a module that receives
  1122.    incoming streams from remote stations. In actual practice, the
  1123.    transmit and receive modules are decomposed into several processes
  1124.    implementing a layered protocol architecture. A process receives both
  1125.    levels of PIGCF and writes them into a conference record metafile for
  1126.    future use. A router process receives and forwards PIGCF traffic from
  1127.    and to the modules previously referred. This router is likely to be
  1128.    replaced by independent communication interfaces between pairs of
  1129.    modules exchanging PIGCF.
  1130.  
  1131.    The thick arrows show the flow of outgoing PIGCF, whereas the thin
  1132.    arrows show the incoming PIGCF flow. We first follow the outgoing
  1133.    path, starting at the application.  The application processes local
  1134.    user actions which are transformed into data structure updates, level
  1135.  
  1136.  
  1137. Aguilar                                                        [Page 20]
  1138.  
  1139.  
  1140.  
  1141. RFC 965                                                    December 1985
  1142. A Format for a Graphical Communication Protocol
  1143.  
  1144.  
  1145.    U PIGCF elements, and executions of device independent graphics
  1146.    subroutines that, among other things, generate level L PIGCF (GKSM)
  1147.    elements.
  1148.  
  1149.    The router merges both level streams according to generation order
  1150.    and sends them to the local copy of the conference record and to the
  1151.    transmission module. The latter batches Group-2 PIGCF items until it
  1152.    receives a Group-1 item. It also timestamps the PIGCF stream to
  1153.    synchronize its play-back, at the receiver, with the play-back of
  1154.    other media information.  The PIGCF may be separated into traffic
  1155.    categories transmitted over diverse communication facilities
  1156.    according to the transport services required by the categories, for
  1157.    example, real-time service for pointer updates, highly reliable
  1158.    transmission for new object definitions, or low-priority service for
  1159.    graphical library transfers. Finally, the transmit module must
  1160.    acknowledge the reception of incoming PIGCF, and of other media
  1161.    traffic as well.
  1162.  
  1163.    The receive module is the entry point for incoming PIGCF streams that
  1164.    may come within diverse traffic categories requiring merging. It
  1165.    checks the timestamps for synchronizing PIGCF items with related data
  1166.    in other media, for example, voice. It is possible to include here a
  1167.    high-level error-correction function that validates the received
  1168.    streams using state and context information about PIGCF syntax and
  1169.    semantics. The receive module passes the streams to the router which
  1170.    forwards them to three processes: It sends level L items to the GKSM
  1171.    interpreter which produces the corresponding changes on the displayed
  1172.    picture; it sends level L and level U items to the conference record,
  1173.    as well as to the PIGCF interpretation code in the application. The
  1174.    level U items cause updates to both the data structures modeling
  1175.    object hierarchies, and the pictorial representation of the
  1176.    hierarchies, through the execution of graphics services. U items also
  1177.    update graphics cursors and may recall new graphics libraries. The
  1178.    application must process level L items because they could indicate
  1179.    updates to the data structures; this happens if, for example, the
  1180.    structures record attribute value information for the object
  1181.    hierarchies. The application coordinates these actions with other
  1182.    media effects according to the timestamps. Conference record
  1183.    play-back is done in off-line mode. Record items are received by the
  1184.    router and thereafter processed similarly to incoming PIGCF.
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194. Aguilar                                                        [Page 21]
  1195.  
  1196.  
  1197.  
  1198. RFC 965                                                    December 1985
  1199. A Format for a Graphical Communication Protocol
  1200.  
  1201.  
  1202.                  +------------+        +-------------+
  1203.                  |APPLICATION |        |    OTHER    |
  1204.                  |    DATA    |        |    MEDIA    |
  1205.                  |STRUCTURES  |        |-------------|
  1206.                  +-----|------+        |  CONFERENCE |
  1207.                        |---------->    | APPLICATION |
  1208.                                        |   GRAPHICS  |
  1209.                        |---------->    |             |
  1210.                  +-----|------+        |             |
  1211.                  |  LANGUAGE  |        +-------------+
  1212.                  |  BINDING   |                       
  1213.                  +-----|------+        +-------------+
  1214.                        |---------->    |   DEVICE-   |
  1215.                  +------------+        | INDEPENDENT |
  1216.                  |  DEVICE    |        |   GRAPHICS  |
  1217.                  |  DEPENDENT |  <---> |   SERVICES  |
  1218.                  |  GRAPHICS  |        |             |
  1219.                  |  SERVICES  |        |             |
  1220.                  +-----|------+        |             |
  1221.                        |               |             |
  1222.                        v               |             |
  1223.                  +------------+        |             |
  1224.                  |    DEVICE  |        |             |
  1225.                  |  DRIVERS   |        |             |
  1226.                  +------------+        +-------------+
  1227.  
  1228.                  FIGURE 1 - THE BASIC GRAPHICS PIPELINE
  1229.                         IN A CONFERENCING SYSTEM
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251. Aguilar                                                        [Page 22]
  1252.  
  1253.  
  1254.  
  1255. RFC 965                                                    December 1985
  1256. A Format for a Graphical Communication Protocol
  1257.  
  1258.  
  1259. +------------+    +------------+                 +------------------+
  1260. |APPLICATION |    |   OTHER    |                 |    TRANSMIT      |
  1261. |   DATA     |    |   MEDIA    |                 |       ACK        |=>
  1262. | STRUCTURES |    |------------|     +-----+     | SEPARATE TRAFFIC |=>
  1263. +-----|------+    | CONFERENCE |     |     |===> |    BATCHING      |=>
  1264.       |---------->|APPLICATION |     |     |     |   TIMESTAMPING   |
  1265.                   |  GRAPHICS  |     |     |     +------------------+
  1266.       |---------->|------------|     |     |
  1267.       |           | PIGCF L, U | <---|     |     +------------------+
  1268. +-----|------|    | INTERPRETER|     |     |     |     RECEIVE      |
  1269. | LANGUAGE   |    +------------+     |  R  |     |  MERGE TRAFFIC   |<-
  1270. | BINDING    |    | PIGCF U    |===> |  O  | <---| CHECK TIMESTAMPS |<-
  1271. +-----|------+    |  GENERATOR |     |  U  |     | ERROR CORRECTION |<-
  1272.       |           +------------+     |  T  |     |                  |
  1273.       ------------------|            |  E  |     +------------------+
  1274. +------------+    +-----V------+     |  R  |
  1275. |  DEVICE    |    |  DEVICE    |     |     |     +------------------+
  1276. | DEPENDENT  |    |INDEPENDENT |     |     |====>|                  |
  1277. | GRAPHICS   |<-->|  GRAPHICS  |     |     |---->|    CONFERENCE    |
  1278. | SERVICES   |    |  SERVICES  |     |     |     |       RECORD     |
  1279. |            |    |            |     |     |     |                  |
  1280. +-----|------+    |------------|     |     |     +------------------+
  1281.       |           |    GKSM    |     |     |
  1282.       v           | INTERPRETER|<--- |     |       <--- INCOMING PIGCF
  1283. +------------+    +------------+     |     |
  1284. |   DEVICE   |    |    GKSM    |     |     |       ===> OUTGOING PIGCF
  1285. | DRIVERS    |    | GENERATOR  |===> |     |
  1286. +------------+    +------------+     +-----+
  1287.  
  1288. FIGURE 2 - A CONFERENCING SOFTWARE ARCHITECTURE FOR PROCESSING PIGCF
  1289.  
  1290. VI.  CONCLUSIONS
  1291.  
  1292.    Teleconferencing and other multi-media applications will be part of
  1293.    the communication resources available to organizations in the near
  1294.    future. This will prompt computer graphics and computer communication
  1295.    practitioners to address the issue of application-to-application
  1296.    graphics communication. A key element of the issue is a protocol, and
  1297.    a key component of the protocol is a data format. We have presented
  1298.    the operational requirements for such a protocol and have proposed a
  1299.    format that fulfills these requirements.
  1300.  
  1301.    At present, none of the existing or emerging graphics standards can
  1302.    be used as the needed protocol or as a format for the protocol, but
  1303.    this may change as the standards evolve.  We are monitoring the
  1304.    standards development and will study the use of some of them as a
  1305.    format basis, in particular the CGI.  Nevertheless, the computer
  1306.  
  1307.  
  1308. Aguilar                                                        [Page 23]
  1309.  
  1310.  
  1311.  
  1312. RFC 965                                                    December 1985
  1313. A Format for a Graphical Communication Protocol
  1314.  
  1315.  
  1316.    communication community badly needs experience with multi-media
  1317.    conferencing implementations. In order for these applications to
  1318.    happen, one can base a graphics communication protocol on an official
  1319.    or on a de-facto standard that is likely to gain wide use thus
  1320.    assuring interoperability with a broad user base.  We believe that,
  1321.    by using the GKSM session metafile, we are moving in the proper
  1322.    direction.
  1323.  
  1324.    Planning the software architecture for generating and interpreting
  1325.    the proposed PIGCF has brought up some problems we will confront as
  1326.    we continue our work toward the development of a complete graphics
  1327.    protocol.  This is being done as part of the SRI on-going program in
  1328.    multimedia communications.  Within this program, we are implementing
  1329.    a simple multi-media conferencing prototype and will design a more
  1330.    complete one.  The experience from both exercises will be a valuable
  1331.    input to the protocol architecture design.
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365. Aguilar                                                        [Page 24]
  1366.  
  1367.  
  1368.  
  1369. RFC 965                                                    December 1985
  1370. A Format for a Graphical Communication Protocol
  1371.  
  1372.  
  1373. APPENDIX A
  1374.  
  1375.    Excerpt from "Draft Proposal: Graphical Kernel System" [14]
  1376.  
  1377.    E.2  Metafile Based on ISO DIS7942
  1378.  
  1379.       This metafile may be categorized as one which aims to provide a
  1380.       means of recording the exact sequence of function calls made to
  1381.       GKS. Its functional capability covers the entire range of GKS
  1382.       output functions, from level m to level 2. It is, therefore,
  1383.       suitable for applications where the individual graphics actions
  1384.       need to be 'played back', perhaps with selective graphical editing
  1385.       being done by the interpreter.
  1386.  
  1387.       Two encodings have been specified for this metafile. One encoding
  1388.       is inefficient for many applications. The second allows an
  1389.       unspecified binary format. The remainder of this IGCF appendix
  1390.       gives full details of these metafile structures and encodings.
  1391.  
  1392.       E.2.1 File Format and Data Format
  1393.  
  1394.          The GKS metafile is built up as a sequence of logical data
  1395.          items. The file starts with a file header in fixed format which
  1396.          describes the origin of the metafile (author, installation),
  1397.          the format of the following items, and the number
  1398.          representation. The file ends with an end item indicating the
  1399.          logical end of the file. In between these two items, the
  1400.          following information is recorded in the sense of an audit
  1401.          trail:
  1402.  
  1403.             a)      workstation control items and message items;
  1404.  
  1405.             b)      output primitive items, describing elementary
  1406.                     graphics objects;
  1407.  
  1408.             c)      attribute information, including output primitive
  1409.                     attributes; segment attributes, and workstation
  1410.                     attributes;
  1411.  
  1412.             d)      segment items, describing the segment structure and
  1413.                     dynamic segment manipulations;
  1414.  
  1415.             e)      user items.
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422. Aguilar                                                        [Page 25]
  1423.  
  1424.  
  1425.  
  1426. RFC 965                                                    December 1985
  1427. A Format for a Graphical Communication Protocol
  1428.  
  1429.  
  1430.          The overall structure of the GKS metafile is as follows:
  1431.  
  1432.             FILE:     |file  |item|---|item|---|end |
  1433.                       |header| 1  |   | i  |   |item|
  1434.  
  1435.             ITEM:     |item   |item data record|
  1436.                       |header |                |
  1437.  
  1438.             ITEM      |'GKSM'  |identification|length of item data|
  1439.  
  1440.             HEADER:   |optional|    number    |       in bytes    |
  1441.  
  1442.          All data items except the file header have an item header
  1443.          containing:
  1444.  
  1445.             a)      the character string 'GKSM' (optional) which is
  1446.                     present to improve legibility of the file and to
  1447.                     provide an error control facility;
  1448.  
  1449.             b)      the item type identification number which indicates
  1450.                     the kind of information that is contained in the
  1451.                     item;
  1452.  
  1453.             c)      the length of the item data record.
  1454.  
  1455.          The lengths of these fields of the item header are
  1456.          implementation dependent and are specified in the file header.
  1457.          The content of the item data record is fully described below
  1458.          for each item type.
  1459.  
  1460.          The metafile contains characters, integer numbers, and real
  1461.          numbers marked (c), (i), (r) in the item description.
  1462.          Characters in the metafile are represented according to ISO 646
  1463.          and ISO 2022. Numbers will be represented according to ISO 6093
  1464.          using format F1 for integers and format F2 for reals. (Remark:
  1465.          Formats F1 and F2 can be written and read via FORTRAN formats I
  1466.          and F respectively.)
  1467.  
  1468.          Real numbers describing coordinates and length units are stored
  1469.          as normalized device coordinates. The workstation
  1470.          transformation, if specified in the application program for a
  1471.          workstation writing a metafile of this format, is not performed
  1472.          but WORKSTATION WINDOW and WORKSTATION VIEWPORT are stored in
  1473.          data items for later usage. Real numbers may be stored as
  1474.          integers. In this case transformation parameters are specified
  1475.          in the file header to allow proper transformation of integers
  1476.          into normalized device coordinates.
  1477.  
  1478.  
  1479. Aguilar                                                        [Page 26]
  1480.  
  1481.  
  1482.  
  1483. RFC 965                                                    December 1985
  1484. A Format for a Graphical Communication Protocol
  1485.  
  1486.  
  1487.          For reasons of economy, numbers can be stored using an internal
  1488.          binary format. As no standard exists for binary number
  1489.          representation, this format limits the portability of the
  1490.          metafile. The specification of such a binary number
  1491.          representation is outside the scope of this document.
  1492.  
  1493.          When exchanging metafiles between different installations, the
  1494.          physical structure of data sets on specific storage media
  1495.          should be standardized. Such a definition is outside the scope
  1496.          of this standard.
  1497.  
  1498.    E.3  Generation of Metafiles
  1499.  
  1500.       Table E1 contains a list, by class, of all GKS functions which
  1501.       apply to workstations of category MO, and their effects on this
  1502.       GKSM. In the table, GKSM-OUT is a workstation identifier
  1503.       indicating a workstation writing a metafile of this format.
  1504.  
  1505.       The concepts of clipping rectangle and clipping indicator are
  1506.       encapsulated in one metafile item which specifies a clipping
  1507.       rectangle. This item is written to the metafile on activate
  1508.       workstation with the values (0, 1, 0, 1), if the clipping
  1509.       indicator is OFF, or the viewport of the current normalization
  1510.       transformation, if the clipping indicator is ON. If the viewport
  1511.       of the current normalization transformation is redefined or a
  1512.       different normalization transformation is selected when the
  1513.       clipping indicator is ON, a further clipping rectangle item is
  1514.       written. If the clipping indicator is changed to OFF, a clipping
  1515.       rectangle item (0, 1, 0, 1) is written. If the clipping indicator
  1516.       is changed to ON, an item containing the viewport of the current
  1517.       normalization transformation is written. This is analogous to the
  1518.       handling of clipping in segments (see 4.7.6 [14]).
  1519.  
  1520.       
  1521. GKS functions which apply to workstations        GKSM item created
  1522. of category MO                                   or effect
  1523. ========================================================================
  1524.  
  1525. Control functions
  1526.  
  1527. OPEN WORKSTATION (GKSM-OUT,...)                  - (file header)
  1528.                                                  1 (CONDITIONAL)
  1529. CLOSE WORKSTATION (GKSM-OUT)                     0 (end item)
  1530. ACTIVATE WORKSTATION (GKSM-OUT)                  (61, 21-44)
  1531.                                                  ensure attributes
  1532.                                                  current;
  1533.                                                  enable output
  1534.  
  1535.  
  1536. Aguilar                                                        [Page 27]
  1537.  
  1538.  
  1539.  
  1540. RFC 965                                                    December 1985
  1541. A Format for a Graphical Communication Protocol
  1542.  
  1543.  
  1544. DEACTIVATE WORKSTATION (GKSM-OUT)                disable output
  1545. CLEAR WORKSTATION (GKSM-OUT,...)                 1
  1546.                                                  2
  1547. REDRAW ALL SEGMENTS ON WORKSTATION (GKSM-OUT)
  1548. UPDATE WORKSTATION (GKSM-OUT,...)                3
  1549. SET DEFERRAL STATE (GKSM-OUT,...)                4
  1550. MESSAGE (GKSM-OUT,...)                           5 (message)
  1551. ESCAPE                                           6
  1552. ________________________________________________________________________
  1553.  
  1554. Output Primitives
  1555.  
  1556. POLYLINE                                         11
  1557. POLYMARKER                                       12
  1558. TEXT                                             13
  1559. FILL AREA                                        14
  1560. CELL ARRAY                                       15
  1561. GENERALIZED DRAWING PRIMITIVE                    16
  1562. ________________________________________________________________________
  1563.  
  1564. Output Attributes
  1565.  
  1566. SET POLYLINE INDEX                               21
  1567. SET LINETYPE                                     22
  1568. SET LINEWIDTH SCALE FACTOR                       23
  1569. SET POLYLINE COLOUR INDEX                        24
  1570. SET POLYMARKER INDEX                             25
  1571. SET MARKER TYPE                                  26
  1572. SET MARKER SIZE SCALE FACTOR                     27
  1573. SET POLYMARKER COLOUR INDEX                      28
  1574. SET TEXT INDEX                                   29
  1575. SET TEXT FONT AND PRECISION                      30
  1576. SET CHARACTER EXPANSION FACTOR                   31
  1577. SET CHARACTER SPACING                            32
  1578. SET TEXT COLOUR INDEX                            33
  1579. SET CHARACTER HEIGHT                             34
  1580. SET CHARACTER UP VECTOR                          34
  1581. SET TEXT PATH                                    35
  1582. SET TEXT ALIGNMENT                               36
  1583. SET FILL AREA INDEX                              37
  1584. SET FILL AREA INTERIOR STYLE                     38
  1585. SET FILL AREA STYLE INDEX                        39
  1586. SET FILL AREA COLOUR INDEX                       40
  1587.  
  1588. SET PATTERN SIZE                                 41
  1589. SET PATTERN REFERENCE POINT                      42
  1590.  
  1591.  
  1592.  
  1593. Aguilar                                                        [Page 28]
  1594.  
  1595.  
  1596.  
  1597. RFC 965                                                    December 1985
  1598. A Format for a Graphical Communication Protocol
  1599.  
  1600.  
  1601. SET ASPECT SOURCE FLAGS                          43
  1602. SET PICK IDENTIFIER                              44
  1603. ________________________________________________________________________
  1604.  
  1605. Workstation Attributes
  1606.  
  1607. SET POLYLINE REPRESENTATION (GKSM-OUT,...)       51
  1608. SET POLYMARKER REPRESENTATION (GKSM-OUT,...)     52
  1609. SET TEXT REPRESENTATION (GKSM-OUT,...)           53
  1610. SET FILL AREA REPRESENTATION (GKSM-OUT,...)      54
  1611. SET PATTERN REPRESENTATION (GKSM-OUT,...)        55
  1612. SET COLOUR REPRESENTATION (GKSM-OUT,...)         56
  1613. ________________________________________________________________________
  1614.  
  1615. Transformation Functions
  1616.  
  1617. SET WINDOW of current normalization              34, 41, 42
  1618. transformation
  1619. SET VIEWPOINT of current normalization           61, 34, 41, 42
  1620. transformation
  1621. SELECT NORMALIZATION TRANSFORMATION              61, 34, 41, 42
  1622. SET CLIPPING INDICATOR                           61
  1623. SET WORKSTATION WINDOW (GKSM-OUT,...)            71
  1624. SET WORKSTATION WINDOW VIEWPORT (GKSM-OUT,...)   72
  1625.  
  1626. Note:  item 61 (CLIPPING RECTANGLE) is described more fully in E.2.2.
  1627.  
  1628. Note: When the current normalization transformation is altered, items
  1629. corresponding to attributes containing coordinate information are sent
  1630. (items 34, 41, and 42).
  1631. ________________________________________________________________________
  1632.  
  1633. Segment Functions
  1634.  
  1635. CREATE SEGMENT                                   81
  1636. CLOSE SEGMENT                                    82
  1637. RENAME SEGMENT                                   83
  1638. DELETE SEGMENT                                   84
  1639.  
  1640. DELETE SEGMENT FROM WORKSTATION (GKSM-OUT,...)   84
  1641. ASSOCIATE SEGMENT WITH WORKSTATION               81, (21-44), (11-16),
  1642. (GKSM-OUT,...)                                   (61), 82
  1643. COPY SEGMENT TO WORKSTATION (GKSM-OUT,...)       (21-44), (11-16), (61)
  1644.  
  1645. INSERT SEGMENT                                   (21-44), (11-16), (61)
  1646. ________________________________________________________________________
  1647.  
  1648.  
  1649.  
  1650. Aguilar                                                        [Page 29]
  1651.  
  1652.  
  1653.  
  1654. RFC 965                                                    December 1985
  1655. A Format for a Graphical Communication Protocol
  1656.  
  1657.  
  1658. Segment Attributes
  1659.  
  1660. SET SEGMENT TRANSFORMATION                       91
  1661.  
  1662. SET VISIBILITY                                   92
  1663. SET HIGHLIGHTING                                 93
  1664. SET SEGMENT PRIORITY                             94
  1665. SET DETECTABILITY                                95
  1666. ________________________________________________________________________
  1667.  
  1668. Metafile Functions
  1669.  
  1670. WRITE ITEM TO GKSM                               > 100
  1671. ________________________________________________________________________
  1672.  
  1673.    E.4  Interpretation of Metafiles
  1674.  
  1675.       E.4.1  Introduction
  1676.  
  1677.          The interpretation of metafiles in GKS is described in 4.9
  1678.          [14]. The effects of INTERPRET ITEM for all types of metafile
  1679.          item are described in the following sections. Items are grouped
  1680.          by class of functionality.
  1681.  
  1682.       E.4.2  Control Items
  1683.  
  1684.          Interpretation of items in this class is described under the
  1685.          definitions of each item in E.5. ([14] reads "E.2.4" instead of
  1686.          "E.5" which we believe is an error).
  1687.  
  1688.       E.4.3  Output Primitives
  1689.  
  1690.          Interpretation of items in this class generates output
  1691.          corresponding to the primitive functions, except that
  1692.          coordinates of points are expressed in NDC. Primitive
  1693.          attributes bound to primitives are those which have originated
  1694.          from interpretation of primitive attribute items in this
  1695.          particular metafile (see E.4.4).
  1696.  
  1697.       E.4.4  Output Primative Attributes
  1698.  
  1699.          Interpretation of items in this class sets values for use in
  1700.          the display of primitives subsequently originating from this
  1701.          particular metafile (see E.4.3). No changes are made to entries
  1702.          in the GKS state list.
  1703.  
  1704.  
  1705.  
  1706.  
  1707. Aguilar                                                        [Page 30]
  1708.  
  1709.  
  1710.  
  1711. RFC 965                                                    December 1985
  1712. A Format for a Graphical Communication Protocol
  1713.  
  1714.  
  1715.       E.4.5  Workstation Attributes
  1716.  
  1717.          Interpretation of items in this class has the same effect as
  1718.          invocation of the corresponding GKS functions shown in Table
  1719.          E1. The GKS functions are performed on all active workstations.
  1720.  
  1721.       E.4.6  Transformations
  1722.  
  1723.          Interpretation of a clipping rectangle item sets values for use
  1724.          in clipping output primitives subsequently originating from
  1725.          this particular metafile. No changes are made to entries in the
  1726.          GKS state list. Interpretation of other items in this class
  1727.          (WORKSTATION WINDOW and WORKSTATION VIEWPORT) causes the
  1728.          invocation of the corresponding GKS functions on all active
  1729.          workstations.
  1730.  
  1731.       E.4.7   Segment Manipulation
  1732.  
  1733.          Interpretation of items in this class has the same effect as
  1734.          invocation of the corresponding GKS functions shown in Table
  1735.          E1. (Item 84 causes an invocation of DELETE SEGMENT.)
  1736.  
  1737.       E.4.8 Segment Attributes
  1738.  
  1739.          Interpretation of items in this class has the same effect as
  1740.          invocation of the corresponding GKS functions shown in Table
  1741.          E1.
  1742.  
  1743.    E.5  Control Items
  1744.  
  1745.       FILE HEADER
  1746.  
  1747.          | GKSM | N | D | V | H | T | L | I | R | F | RI | ZERO | ONE |
  1748.  
  1749. All fields in the file header item have fixed length.  Numbers are
  1750. formated according to ISO 6093 - Format F1.
  1751.  
  1752. General Information:
  1753.  
  1754. GKSM    4 bytes   containing string 'GKSM'
  1755. N       40 bytes  containing name of author/installation
  1756. D       8 bytes   date (year/month/day, e.g., 79/12/31)
  1757. V       2 bytes   version number: the metafile described here has
  1758.                   version number 1
  1759. H       2 bytes   integer specifying how many bytes of the string 'GKSM'
  1760.                   are repeated at the beginning of each record.
  1761.                   Possible values:  0, 1, 2, 3, 4
  1762.  
  1763.  
  1764. Aguilar                                                        [Page 31]
  1765.  
  1766.  
  1767.  
  1768. RFC 965                                                    December 1985
  1769. A Format for a Graphical Communication Protocol
  1770.  
  1771.  
  1772. T       2 bytes   length of item type indicator field
  1773. L       2 bytes   length of item data record length indicator field
  1774. I       2 bytes   length of field for each integer in the
  1775.                   item data record (applied to all data marked (i)
  1776.                   in the item description)
  1777. R       2 bytes   length of field for each real in the item data record
  1778.                   (applies to all data marked (r) in the item
  1779.                   description).
  1780.  
  1781. Specification of Number Representation:
  1782.  
  1783. F       2 bytes   Possible values:  1, 2.  This applies to all data
  1784.                   in the items marked (i) or (r) and to item type
  1785.                   and item data record length:
  1786.                   1:  all numbers are formatted according to ISO 6093
  1787.                   2:  all numbers (except in the file header) are
  1788.                   stored in an internal binary format
  1789. RI      2 bytes   Possible values:  1, 2.  This is the number
  1790.                   representation for data marked (r):
  1791.                   1 = real, 2 = integer
  1792. ZERO    11 bytes  integer equivalent to 0.0, if RI = 2
  1793. ONE     11 bytes  integer equivalent to 1.0, if RI = 2
  1794.  
  1795.          After the file header, which is in fixed format, all values in
  1796.          the following items are in the format defined by the file
  1797.          header. For the following description, the setting:
  1798.  
  1799.                           H = 4; T = 3; F = 1
  1800.  
  1801.          is assumed. In addition to formats (c), (i) and (r), which are
  1802.          already described, (p) denotes a point represented by a pair of
  1803.          real numbers (2r). The notation allows the single letter to be
  1804.          preceded by an expression, indicating the number of values of
  1805.          that type.
  1806.  
  1807.          {Explanatory comments have been added to some item
  1808.          specifications; these are not part of the GKS Appendix E and
  1809.          they are enclosed in braces {}. A complete definition of the
  1810.          generation and interpretation of the GKSM items is given by the
  1811.          definition of the corresponding GKS functions [14].}
  1812.  
  1813.       END ITEM
  1814.  
  1815.          | 'GKSM 0' | L |
  1816.  
  1817.          Last item of every GKS Metafile. Sets condition for the error.
  1818.  
  1819.  
  1820.  
  1821. Aguilar                                                        [Page 32]
  1822.  
  1823.  
  1824.  
  1825. RFC 965                                                    December 1985
  1826. A Format for a Graphical Communication Protocol
  1827.  
  1828.  
  1829.       CLEAR WORKSTATION
  1830.  
  1831.          | 'GKSM 1' | L | C |
  1832.  
  1833.          Requests CLEAR WORKSTATION on all active workstations.
  1834.  
  1835.          C(i):  clearing control flag
  1836.                 (0 = CONDITIONAL, 1 = ALWAYS)
  1837.  
  1838.       REDRAW ALL SEGMENTS ON WORKSTATION
  1839.  
  1840.          | 'GKSM  3' | L | R |
  1841.  
  1842.          Requests UPDATE WORKSTATION on all active workstations.
  1843.  
  1844.          R(i):  regeneration flag
  1845.                 (0 = PERFORM, 1 = SUSPEND)
  1846.  
  1847.       DEFERRAL STATE
  1848.  
  1849.          | 'GKSM  4' | L | D | R |
  1850.  
  1851.          Requests SET DEFERRAL STATE on all active workstations.
  1852.  
  1853.          D(i): deferral mode
  1854.                (0 = ASAP, 1 = BNIG, 2 = BNIL, 3 = ASTI)
  1855.  
  1856.          R(i):  implicit regeneration mode
  1857.                 (0 = ALLOWED, 1 = SUPPRESSED)
  1858.  
  1859.          {This item provides control over the occurrence of the visual
  1860.          effect of GKS functions in order to optimize the use of
  1861.          workstation capabilities according to application needs.}
  1862.  
  1863.       MESSAGE
  1864.  
  1865.          | 'GKSM  5' | L | N | T |
  1866.  
  1867.          Requests MESSAGE on all active workstations.
  1868.          N(i):   number of characters in string
  1869.          T(Nc):  string with N characters.
  1870.  
  1871.          {The message is not part of a metafile output primitives; the
  1872.          message is only for interpretation by workstation operators.}
  1873.  
  1874.  
  1875.  
  1876.  
  1877.  
  1878. Aguilar                                                        [Page 33]
  1879.  
  1880.  
  1881.  
  1882. RFC 965                                                    December 1985
  1883. A Format for a Graphical Communication Protocol
  1884.  
  1885.  
  1886.       ESCAPE
  1887.  
  1888.          | 'GKSM  6' | L | FI | L | M | I | R |
  1889.  
  1890.          Requests ESCAPE
  1891.  
  1892.          FI(i):  function identifier
  1893.          L(i):   length of integer data in data record
  1894.          M(i):   length of real data in data record
  1895.          I(Li):  integer data
  1896.          R(Mr):  real data.
  1897.  
  1898.          {This item permits the invocation of a specific non-standard
  1899.          escape function FI. The execution of the function with the
  1900.          given parameters must not alter the GKS state list nor produce
  1901.          geometrical output.}
  1902.  
  1903.    E.6  Items for Output Primitives
  1904.  
  1905.       POLYLINE
  1906.  
  1907.          | 'GKSM 11' | L | N | P |
  1908.  
  1909.          N(i):   number of points of the polyline
  1910.          P(Np):  list of points
  1911.  
  1912.       POLYMARKER
  1913.  
  1914.          | 'GKSM 12' | L | N | P |
  1915.  
  1916.          N(i):   number of points
  1917.          P(Np):  list of points.
  1918.  
  1919.       TEXT
  1920.  
  1921.          | 'GKSM 13' | L | P | N | T |
  1922.  
  1923.          P(p):   starting point of character string
  1924.          N(i):   number of characters in string T
  1925.          T(Nc):  string with N characters from the set of ISO 646
  1926.  
  1927.       FILL AREA
  1928.  
  1929.          | 'GKSM 14' | L | N | P |
  1930.  
  1931.          N(i):   number of points
  1932.          P(Np):  list of points.
  1933.  
  1934.  
  1935. Aguilar                                                        [Page 34]
  1936.  
  1937.  
  1938.  
  1939. RFC 965                                                    December 1985
  1940. A Format for a Graphical Communication Protocol
  1941.  
  1942.  
  1943.       CELL ARRAY
  1944.  
  1945.          | 'GKSM 15' | L | P | Q | R | N | M | CT |
  1946.  
  1947.          P(p),Q(p),R(p):  coordinates of corner points of pixel array
  1948.                           (P and Q are the images of the points P and
  1949.                           Q specified in the function CELL ARRAY and
  1950.                           R is another corner)
  1951.          M(i):            number of rows in array
  1952.          N(i):            number of columns in array
  1953.          CT(MNi):         array of colour indices stored row by row
  1954.  
  1955.          {This item permits passing raster images to GKS. The raster
  1956.          image is defined by the colour index matrix CT, and its World
  1957.          Coordinate position given by points P and Q.}
  1958.  
  1959.       GENERALIZED DRAWING PRIMITIVE
  1960.  
  1961.          | 'GKSM 16' | L | GI | N | P | L | M | I | R |
  1962.  
  1963.          GI(i):  GDP identifier
  1964.          N(i):   number of points
  1965.          P(Np):  list of points
  1966.          L(i):   length of integer data in data record
  1967.          M(i):   length of real data in data record
  1968.          I(Li):  integer data
  1969.          R(Mr):  real data.
  1970.  
  1971.          {This item provides a standard way for drawing additional
  1972.          non-standard output primitives. The generalized drawing
  1973.          primitive GI is drawn according to the point list P and the
  1974.          data record in I and R.}
  1975.  
  1976.    E.7  Items for Output Primitive Attributes
  1977.  
  1978.       POLYLINE INDEX
  1979.  
  1980.          | 'GKSM 21' | L | LT |
  1981.  
  1982.          LT(i):  linetype
  1983.  
  1984.  
  1985.  
  1986.  
  1987.  
  1988.  
  1989.  
  1990.  
  1991.  
  1992. Aguilar                                                        [Page 35]
  1993.  
  1994.  
  1995.  
  1996. RFC 965                                                    December 1985
  1997. A Format for a Graphical Communication Protocol
  1998.  
  1999.  
  2000.       LINEWIDTH SCALE FACTOR
  2001.  
  2002.          | 'GKSM 23' | L | LW |
  2003.  
  2004.          LW(r):  linewidth scale factor
  2005.  
  2006.          {In GKS, the line width is not affected by GKS transformations.
  2007.          However, the effective line width is calculated as the product
  2008.          of the nominal line width times the line width scale factor in
  2009.          effect when a line is drawn.}
  2010.  
  2011.       POLYLINE COLOUR INDEX
  2012.  
  2013.          | 'GKSM 24' | L | CI |
  2014.  
  2015.          CI(i):  polyline colour index
  2016.  
  2017.       POLYMARKER INDEX
  2018.  
  2019.          | 'GKSM 25' | L | I |
  2020.  
  2021.          I(i):  polymarker index
  2022.  
  2023.       MARKER TYPE
  2024.  
  2025.          | 'GKSM 26' | L | MT |
  2026.  
  2027.          MT(i):  marker type
  2028.  
  2029.       MARKER SIZE SCALE FACTOR
  2030.  
  2031.          | 'GKSM 27' | L | MS |
  2032.  
  2033.          MS(r):  marker size scale factor
  2034.  
  2035.          {In GKS, the marker size is not affected by GKS
  2036.          transformations. However, the effective marker size is
  2037.          calculated as the product of the nominal marker size times the
  2038.          marker size scale factor in effect when a marker is drawn.}
  2039.  
  2040.       POLYMARKER COLOUR INDEX
  2041.  
  2042.          | 'GKSM 28' | L | CI |
  2043.  
  2044.          CI(i):  polymarker colour index
  2045.  
  2046.  
  2047.  
  2048.  
  2049. Aguilar                                                        [Page 36]
  2050.  
  2051.  
  2052.  
  2053. RFC 965                                                    December 1985
  2054. A Format for a Graphical Communication Protocol
  2055.  
  2056.  
  2057.       TEXT INDEX
  2058.  
  2059.          | 'GKSM 29' | L | I |
  2060.  
  2061.          I(i):  text index
  2062.  
  2063.       TEXT FONT AND PRECISION
  2064.  
  2065.          | 'GKSM 30' | L | F | P |
  2066.  
  2067.          F(i):  text font
  2068.          P(i):  text precision
  2069.          (0 = STRING, 1 = CHAR, 2 = STROKE)
  2070.  
  2071.       CHARACTER EXPANSION FACTOR
  2072.  
  2073.          | 'GKSM 31' | L | CEF |
  2074.  
  2075.          CEF(r):  character expansion factor
  2076.  
  2077.          {This item allows the manipulation of the width/height of the
  2078.          character body. The width of the character body is scaled by
  2079.          the CEF factor.}
  2080.  
  2081.       CHARACTER SPACING
  2082.  
  2083.          | 'GKSM 32' | L | CS |
  2084.  
  2085.          CS(r):  character spacing
  2086.  
  2087.       TEXT COLOUR INDEX
  2088.  
  2089.          | 'GKSM 33' | L | CI |
  2090.  
  2091.          CI(i):  text colour index
  2092.  
  2093.  
  2094.  
  2095.  
  2096.  
  2097.  
  2098.  
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106. Aguilar                                                        [Page 37]
  2107.  
  2108.  
  2109.  
  2110. RFC 965                                                    December 1985
  2111. A Format for a Graphical Communication Protocol
  2112.  
  2113.  
  2114.       CHARACTER VECTORS
  2115.  
  2116.          | 'GKSM 34' | L | CH | CW |
  2117.  
  2118.          CH(2r):  character height vector
  2119.          CW(2r):  character width vector
  2120.  
  2121.          Note:  These vectors are the height and width vectors described
  2122.          in 4.4.5 of [14].
  2123.  
  2124.          {The character height vector is parallel to the character up
  2125.          vector and has a length equal to character height. The
  2126.          character height specifies the height of a capital letter. The
  2127.          character width vector is perpendicular to the height vector,
  2128.          in the direction of the character baseline, and has the same
  2129.          length.}
  2130.  
  2131.       TEXT PATH
  2132.  
  2133.          | 'GKSM 35' | L | P |
  2134.  
  2135.          P(i):  text path
  2136.          (0 = LEFT, 1 = RIGHT, 2 = UP, 3 = DOWN)
  2137.  
  2138.       TEXT ALIGNMENT
  2139.  
  2140.          | 'GKSM 36' | L | H | V |
  2141.  
  2142.          H(i):  horizontal character alignment
  2143.                 (0 = NORMAL, 1 = LEFT, 2 = CENTRE, 3 = RIGHT)
  2144.          V(i):  vertical character alignment
  2145.                 (0 = NORMAL, 1 = TOP, 2 = CAP, 3 = HALF, 4 = BASE,
  2146.                  5 = BOTTOM)
  2147.  
  2148.       FILL AREA INDEX
  2149.  
  2150.          | 'GKSM 37' | L | I |
  2151.  
  2152.          I(i):  fill area index
  2153.  
  2154.       FILL AREA INTERIOR STYLE
  2155.  
  2156.          | 'GKSM 38' | L | S |
  2157.  
  2158.          S(i):  fill area interior style
  2159.                 (0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH)
  2160.  
  2161.  
  2162.  
  2163. Aguilar                                                        [Page 38]
  2164.  
  2165.  
  2166.  
  2167. RFC 965                                                    December 1985
  2168. A Format for a Graphical Communication Protocol
  2169.  
  2170.  
  2171.       FILL AREA STYLE INDEX
  2172.  
  2173.          | 'GKSM 39' | L | SI |
  2174.  
  2175.          SI(i):  fill area style index
  2176.  
  2177.       FILL AREA COLOUR INDEX
  2178.  
  2179.          | 'GKSM 40' | L | CI |
  2180.  
  2181.          CI(i):  fill area colour index
  2182.  
  2183.       PATTERN SIZE
  2184.  
  2185.          | 'GKSM 41' | L | PW | PH |
  2186.  
  2187.          PW(2r):  pattern width vector
  2188.          PH(2r):  pattern height vector
  2189.  
  2190.          {One style for filling areas is with a pattern of color cells.
  2191.          Such a pattern is defined by an array of color indices which is
  2192.          mapped into a pattern rectangle with dimensions given by PW and
  2193.          PH.}
  2194.  
  2195.       PATTERN REFERENCE POINT
  2196.  
  2197.          | 'GKSM 42' | L | P |
  2198.  
  2199.          P(p):  reference point
  2200.  
  2201.          {One style for filling areas is with a pattern of color cells.
  2202.          Such a pattern is defined by an array of color indices which is
  2203.          mapped into a pattern rectangle whose lower left corner is
  2204.          given by P.}
  2205.  
  2206.  
  2207.  
  2208.  
  2209.  
  2210.  
  2211.  
  2212.  
  2213.  
  2214.  
  2215.  
  2216.  
  2217.  
  2218.  
  2219.  
  2220. Aguilar                                                        [Page 39]
  2221.  
  2222.  
  2223.  
  2224. RFC 965                                                    December 1985
  2225. A Format for a Graphical Communication Protocol
  2226.  
  2227.  
  2228.       ASPECT SOURCE FLAGS
  2229.  
  2230.          | 'GKSM 43' | L | F |
  2231.  
  2232.          F(13i):  aspect source flags
  2233.                   (0 = BUNDLED, 1 = INDIVIDUAL)
  2234.  
  2235.          {An application can set an output primitive attribute to either
  2236.          bundled or individual. Bundled attributes are
  2237.          workstation-dependent, their binding is delayed, and their
  2238.          values can change dynamically. Individual attributes are global
  2239.          attributes, they are bound immediately, and their value is
  2240.          static and cannot be manipulated.}
  2241.  
  2242.       PICK IDENTIFIER
  2243.  
  2244.          | 'GKSM 44' | L | P |
  2245.  
  2246.          P(i):  pick identifier
  2247.  
  2248.    E.8  Items for Workstation Attributes
  2249.  
  2250.       POLYLINE REPRESENTATION
  2251.  
  2252.          | 'GKSM 51' | L | I | LT | LW | CI |
  2253.  
  2254.          I(i):   polyline index
  2255.          LT(i):  linetype number
  2256.          LW(r):  linewidth scale factor
  2257.          CI(i):  polyline colour index
  2258.  
  2259.       POLYMARKER REPRESENTATION
  2260.  
  2261.          | 'GKSM 52' | L | I | MT | MS | CI |
  2262.  
  2263.          I(i):   polymarker index
  2264.          MT(i):  marker type
  2265.          MS(r):  marker size scale factor
  2266.          CI(i):  polymarker colour index
  2267.  
  2268.  
  2269.  
  2270.  
  2271.  
  2272.  
  2273.  
  2274.  
  2275.  
  2276.  
  2277. Aguilar                                                        [Page 40]
  2278.  
  2279.  
  2280.  
  2281. RFC 965                                                    December 1985
  2282. A Format for a Graphical Communication Protocol
  2283.  
  2284.  
  2285.       TEXT REPRESENTATION
  2286.  
  2287.          | 'GKSM 53' | L | I | F | P | CEF | CS | CI |
  2288.  
  2289.          I(i):    text index
  2290.          F(i):    text font
  2291.          P(i):    text precision
  2292.          (0 = STRING, 1 = CHAR, 2 = STROKE)
  2293.          CEF(r):  character expansion factor
  2294.          CS(r):   character spacing
  2295.          CI(i):   text colour index
  2296.  
  2297.       FILL AREA REPRESENTATION
  2298.  
  2299.          | 'GKSM 54' | L | I | S | SI | CI |
  2300.  
  2301.          I(i):   fill area index
  2302.          S(i):   fill area interior style
  2303.          (0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH) SI(i):  fill
  2304.          area style index
  2305.          CI(i):  fill area colour index
  2306.  
  2307.       PATTERN REPRESENTATION
  2308.  
  2309.          | 'GKSM 55' | L | I | N | M | CT |
  2310.  
  2311.          I(i):     pattern index
  2312.          N(i):     number of columns in array*
  2313.          M(i):     number of rows in array
  2314.          CT(MNi):  table of colour indices stores row by row
  2315.  
  2316.             {* The ANSI document reads "area" instead of "array".}
  2317.  
  2318.          {One style for filling areas is with a pattern of color cells.
  2319.          Such a pattern is defined by a pattern representation.}
  2320.  
  2321.       COLOUR REPRESENTATION
  2322.  
  2323.          | 'GKSM 56' | L | CI | RGB |
  2324.  
  2325.          CI(i):    colour index
  2326.          RGB(3r):  red, green, blue intensities
  2327.  
  2328.  
  2329.  
  2330.  
  2331.  
  2332.  
  2333.  
  2334. Aguilar                                                        [Page 41]
  2335.  
  2336.  
  2337.  
  2338. RFC 965                                                    December 1985
  2339. A Format for a Graphical Communication Protocol
  2340.  
  2341.  
  2342.    E.9  Items for Transformations
  2343.  
  2344.       CLIPPING RECTANGLE
  2345.  
  2346.          | 'GKSM 61' | L | C |
  2347.  
  2348.          C(4r):  limits of clipping rectangle (XMIN, XMAX, YMIN, YMAX)
  2349.  
  2350.       WORKSTATION WINDOW
  2351.  
  2352.          | 'GKSM 71' | L | W |
  2353.  
  2354.          W(4r):  limits of workstation window (XMIN, XMAX, YMIN, YMAX)
  2355.  
  2356.          {GKS includes a workstation transformation that maps a
  2357.          rectangle of the NDC space (a workstation window) into a
  2358.          rectangle of the device coordinate space (a workstation
  2359.          viewport).}
  2360.  
  2361.       WORKSTATION VIEWPORT
  2362.  
  2363.          | 'GKSM 72' | L | V |
  2364.  
  2365.          V(4r):  limits of workstation viewport (XMIN, XMAX, YMIN, YMAX)
  2366.  
  2367.    E.10  Items for Segment Manipulation
  2368.  
  2369.       CREATE SEGMENT
  2370.  
  2371.          | 'GKSM 81' | L | S |
  2372.  
  2373.          S(i):  segment name
  2374.  
  2375.       CLOSE SEGMENT
  2376.  
  2377.          | 'GKSM 82' | L |
  2378.  
  2379.          indicates end of segment
  2380.  
  2381.       RENAME SEGMENT
  2382.  
  2383.          | 'GKSM 83' | L | SO | SN |
  2384.  
  2385.          SO(i):  old segment name
  2386.          SN(i):  new segment name
  2387.  
  2388.  
  2389.  
  2390.  
  2391. Aguilar                                                        [Page 42]
  2392.  
  2393.  
  2394.  
  2395. RFC 965                                                    December 1985
  2396. A Format for a Graphical Communication Protocol
  2397.  
  2398.  
  2399.       DELETE SEGMENT
  2400.  
  2401.          | 'GKSM 84' | L | S |
  2402.  
  2403.          S(i):  segment name
  2404.  
  2405.    E.11  Items for Segment Attributes
  2406.  
  2407.       SET SEGMENT TRANSFORMATION
  2408.  
  2409.          | 'GKSM 91' | L | S | M |
  2410.  
  2411.          S(i):   segment name
  2412.          M(6r):  transformation matrix
  2413.                  upper and center rows of a 3x3 matrix representing
  2414.                  a 2D homogeneous transformation [9]
  2415.                  M 11  M 12  M 13  M 21  M 22  M 23
  2416.  
  2417.          {This differs from the ANSI X3.124 Jan. 5 1984 document, in the
  2418.          matrix elements indicated. We believe there is an error in such
  2419.          document.}
  2420.  
  2421.       SET VISIBILITY
  2422.  
  2423.          | 'GKSM 92' | L | S | V |
  2424.  
  2425.          S(i):  segment name
  2426.          V(i):  visibility
  2427.                 (0 = VISIBLE, 1 = INVISIBLE)
  2428.  
  2429.       SET HIGHLIGHTING
  2430.  
  2431.          | 'GKSM 93' | L | S | H |
  2432.  
  2433.          S(i):  segment name
  2434.          H(i):  highlighting
  2435.                 (0 = NORMAL, 1 = HIGHLIGHTED)
  2436.  
  2437.       SET SEGMENT PRIORITY
  2438.  
  2439.          | 'GKSM 94' | L | S | P |
  2440.  
  2441.          S(i):  segment name
  2442.          P(r):  segment priority
  2443.  
  2444.  
  2445.  
  2446.  
  2447.  
  2448. Aguilar                                                        [Page 43]
  2449.  
  2450.  
  2451.  
  2452. RFC 965                                                    December 1985
  2453. A Format for a Graphical Communication Protocol
  2454.  
  2455.  
  2456.       SET DETECTABILITY
  2457.  
  2458.          | 'GKSM 95' | L | S | D |
  2459.  
  2460.          S(i):  segment name
  2461.          D(i):  detectability
  2462.                 (0 = UNDETECTABLE, 1 = DETECTABLE)
  2463.  
  2464.    E.12  User Items
  2465.  
  2466.       USER ITEM
  2467.  
  2468.          | 'GKSMXXX' | L | D |
  2469.  
  2470.          XXX   > 100
  2471.          D:    user data (L bytes)
  2472.  
  2473.          {The PIGCF level U items are encoded as GKSM USER ITEM elements
  2474.          so that a PIGCF file will conform to the GKSM metafile
  2475.          specification.}
  2476.  
  2477.  
  2478.  
  2479.  
  2480.  
  2481.  
  2482.  
  2483.  
  2484.  
  2485.  
  2486.  
  2487.  
  2488.  
  2489.  
  2490.  
  2491.  
  2492.  
  2493.  
  2494.  
  2495.  
  2496.  
  2497.  
  2498.  
  2499.  
  2500.  
  2501.  
  2502.  
  2503.  
  2504.  
  2505. Aguilar                                                        [Page 44]
  2506.  
  2507.  
  2508.  
  2509. RFC 965                                                    December 1985
  2510. A Format for a Graphical Communication Protocol
  2511.  
  2512.  
  2513. APPENDIX B
  2514.  
  2515.    Example of PIGCF Use in Conferencing
  2516.  
  2517.    This section presents an example illustrating the proposed PIGCF
  2518.    graphical component in an audio-graphics conference exchange. We
  2519.    present only the graphical part of the conference exchange, which
  2520.    actually would be complemented with speech. For the sake of briefness
  2521.    the example does not contain all the parameter negotiation that a
  2522.    conference set-up would require.
  2523.  
  2524.    The example is about an on-line audio-graphics conference between a
  2525.    Navy command and control center and a Navy task force. The PIGCF
  2526.    items shown do not belong to a single transmission stream. The stream
  2527.    they belong to is determined by the station that transmits them, and
  2528.    the identification of the transmitter belongs to lower level
  2529.    communication protocols. We use the character encoding, rather than
  2530.    the binary one, for this PIGCF example. We illustrate just a few of
  2531.    the possible groups of items that could be batched in this example.
  2532.    The plot of the example is as follows.
  2533.  
  2534.    The command center (center) establishes a conference with some ships
  2535.    in a task force (platforms) to coordinate the interception of an
  2536.    unidentified ship that has been sighted in a conflict area. After
  2537.    recalling graphical libraries, all conference sites can see in their
  2538.    screens a map of the sighting area as well as iconic representations
  2539.    of the task force ships. Then the center interactively draws an
  2540.    iconic representation of the unidentified vessel, scales it, and
  2541.    places it in the sighting location.
  2542.  
  2543.    The platforms explain possible courses of action using graphical
  2544.    pointers. The center draws the expected trajectory of the
  2545.    unidentified ship and the platforms situate the task force icons at
  2546.    the expected points of interception. Then the center zooms into the
  2547.    interception area and the platforms use rubber bands to discuss
  2548.    interception maneuvers.
  2549.  
  2550.    Now we proceed to list the PIGCF items exchanged. The  center
  2551.    initiates  the conference graphical set-up with the FILE HEADER item
  2552.    to set basic representation parameters for  the  graphical
  2553.    information  to  be exchanged.   This item can be interpreted
  2554.    according to its definition in E.5 [14].  The most important
  2555.    parameter selections for this example are:
  2556.  
  2557.       i)   The items contain 0 characters of the "GKSM" string in the
  2558.            identification field of the item header.
  2559.       ii)  The item type indicator field containing the PIGCF
  2560.  
  2561.  
  2562. Aguilar                                                        [Page 45]
  2563.  
  2564.  
  2565.  
  2566. RFC 965                                                    December 1985
  2567. A Format for a Graphical Communication Protocol
  2568.  
  2569.  
  2570.            item number is three bytes long in each item.
  2571.       iii) The integers are 4 bytes long, and the reals 6 bytes long.
  2572.       iv)  The item data record length indicator is 2 bytes long.
  2573.  
  2574.    We will obey the PIGCF specification field lengths and the aforesaid
  2575.    field length settings. However, we will add one space before and
  2576.    after the "|" separator to improve legibility. Also, every item will
  2577.    be preceded with its name to help identification.
  2578.  
  2579.    FILE HEADER:
  2580.  
  2581.       | GKSM | center | 84/11/10 | 1 | 0 | 3 | 2 | 4 | 6 | 1 | 1
  2582.       |           |           |
  2583.  
  2584.    The center states the boundaries of the work station window for the
  2585.    conference.
  2586.  
  2587.    WORKSTATION WINDOW:  |  71 | 24 |  0.0  0.5  0.0  0.375 |
  2588.  
  2589.    In this example, we assume that the conferencing work stations  use
  2590.    world coordinates for the internal representation of positional
  2591.    information. Accordingly, the center states the boundaries of the
  2592.    world  window for the normalization transformation used in the
  2593.    conference.
  2594.  
  2595.    SET WINDOW:  | 134 | 28 |  0.0  320.0  0.0  240.0 |
  2596.  
  2597.    The center informs the location of its local NDC viewport, however,
  2598.    other conferees can choose different NDC viewports for the same
  2599.    transformation, but their work station window should include the
  2600.    conference's.  All systems record the conference: world window, NDC
  2601.    viewport, and work station widow.
  2602.  
  2603.    SET VIEWPORT:  | 135 | 28 |  0.0  0.5  0.0  0.375 |
  2604.  
  2605.    The center recalls graphical libraries containing geographical maps
  2606.    of  the  crisis  area  and icons of the task forces in the area. It
  2607.    also displays a graphical object that provides a background picture.
  2608.  
  2609.    RECALL LIBRARY:  | 139 |  9 | caribbean |
  2610.    DISPLAY OBJECT:  | 128 | 11 | coast_lines |
  2611.    RECALL LIBRARY:  | 139 | 10 | task_units |
  2612.  
  2613.    The center proceeds to instantiate one of the task forces in the
  2614.    task_units library. This is done by recalling some of the library
  2615.    objects and applying transformations to the objects, later. Since set
  2616.    window, set viewport, and recall library belong to the update
  2617.  
  2618.  
  2619. Aguilar                                                        [Page 46]
  2620.  
  2621.  
  2622.  
  2623. RFC 965                                                    December 1985
  2624. A Format for a Graphical Communication Protocol
  2625.  
  2626.  
  2627.    Group-2, they can be batched until display object, from update
  2628.    Group-1, is entered. The second recall library can be batched
  2629.    together with the following begin instantiation until display object
  2630.    is produced. The rest of the example contains more cases of item
  2631.    sequences which can be batched; however, for briefness we do not
  2632.    indicate any more of them.
  2633.  
  2634.    BEGIN INSTANTIATION:  | 124 | 15 | US_CONSTITUTION |
  2635.    DISPLAY OBJECT:       | 128 | 15 | US_CONSTITUTION |
  2636.    TRANSFORM OBJECT:     | 126 | 55 |   15 | US_CONSTITUTION |
  2637.                            0.1   0.0   0.0   0.0   0.1   0.0 |
  2638.    TRANSFORM OBJECT:     | 126 | 55 |   15 | US_CONSTITUTION |
  2639.                            0.1   0.0  0.312   0.0   0.1  0.078 |
  2640.    END INSTANTIATION:    | 125 |  0 |
  2641.  
  2642.    BEGIN INSTANTIATION:  | 124 | 13 | US_NEW_JERSEY |
  2643.    DISPLAY OBJECT:       | 128 | 13 | US_NEW_JERSEY |
  2644.    TRANSFORM OBJECT:     | 126 | 53 |   13 | US_NEW_JERSEY |
  2645.                            0.1   0.0  0.0   0.0   0.1   0.0 |
  2646.    TRANSFORM OBJECT:     | 126 | 53 |   13 | US_NEW_JERSEY |
  2647.                            0.1   0.0  0.312   0.0   0.1  0.093 |
  2648.    END INSTANTIATION:    | 125 |  0 |
  2649.  
  2650.    Next the center sets values for two output primitive attributes in
  2651.    preparation for drawing a new icon on the screens. We assume that all
  2652.    the other attributes have been assigned default values as a result of
  2653.    the conference set-up.
  2654.  
  2655.    POLYLINE INDEX:         |  21 |  4 |   20 |
  2656.    POLYLINE COLOUR INDEX:  |  24 |  4 |  200 |
  2657.  
  2658.    The following items correspond to the interactive definition of the
  2659.    unidentified vessel. Since the definition is done interactively, the
  2660.    vessel image remains visible on the screens after definition.
  2661.  
  2662.    BEGIN DEFINITION:  | 120 |  0 |
  2663.    POLYLINE:          |  11 | 64 |    5 |
  2664.    0.047  0.063  0.063  0.047  0.125  0.047  0.14  0.063  0.047  0.047 |
  2665.    POLYLINE:          |  11 | 52 |    3 |
  2666.                  0.078 0.063  0.078  0.078  0.109  0.078  0.109  0.063 |
  2667.    END DEFINITION:    | 121 |  8 | sighting |
  2668.  
  2669.    Then the unidentified vessel "sighting" is scaled and placed at the
  2670.    sighting site.
  2671.  
  2672.  
  2673.  
  2674.  
  2675.  
  2676. Aguilar                                                        [Page 47]
  2677.  
  2678.  
  2679.  
  2680. RFC 965                                                    December 1985
  2681. A Format for a Graphical Communication Protocol
  2682.  
  2683.  
  2684.    BEGIN INSTANTIATION:  | 124 |  8 | sighting |
  2685.    TRANSFORM OBJECT:     | 126 | 48 |    8 | sighting |
  2686.                            0.2   0.0   0.0
  2687.                            0.0   0.2   0.0 |
  2688.    TRANSFORM OBJECT:     | 126 | 48 |    8 | sighting |
  2689.                            0.1   0.0 0.156
  2690.                            0.0   0.1  0.016 |
  2691.    END INSTANTIATION:    | 125 |  0 |
  2692.  
  2693.    The center and the platforms use graphical pointer movements to
  2694.    discuss possible routes the unidentified vessel might follow. We only
  2695.    show a few pointer updates. In practice, there would typically be a
  2696.    large number of points transmitted to convey the movement of the
  2697.    pointers over the screens.
  2698.  
  2699.    from the center:
  2700.  
  2701.    POINTER TRACKING:  | 137 | 16 |    0 |  0.39  0.032 |
  2702.    POINTER TRACKING:  | 137 | 16 |    0 |  0.388 0.035 |
  2703.    POINTER TRACKING:  | 137 | 16 |    0 |  0.388 0.039 |
  2704.    POINTER TRACKING:  | 137 | 16 |    0 |  0.386 0.04  |
  2705.  
  2706.    from one of the platforms:
  2707.  
  2708.    POINTER TRACKING:  | 137 | 16 |    0 |  0.22  0.016 |
  2709.    POINTER TRACKING:  | 137 | 16 |    0 |  0.222 0.159 |
  2710.    POINTER TRACKING:  | 137 | 16 |    0 |  0.233 0.157 |
  2711.    POINTER TRACKING:  | 137 | 16 |    0 |  0.24  0.155 |
  2712.  
  2713.    The center now draws the expected route to be followed by the
  2714.    unidentified ship. This time the pointer trace is recorded on the
  2715.    screen by drawing a line.
  2716.  
  2717.    POINTER TRACKING:  | 137 | 16 |    1 |  0.388 0.038 |
  2718.    POINTER TRACKING:  | 137 | 16 |    1 |  0.386 0.038 |
  2719.    POINTER TRACKING:  | 137 | 16 |    1 |  0.386 0.052 |
  2720.    POINTER TRACKING:  | 137 | 16 |    1 |  0.375 0.078 |
  2721.    POINTER TRACKING:  | 137 | 16 |    1 |  0.369 0.105 |
  2722.    POINTER TRACKING:  | 137 | 16 |    1 |  0.361 0.125 |
  2723.    POINTER TRACKING:  | 137 | 16 |    1 |  0.352 0.144 |
  2724.    POINTER TRACKING:  | 137 | 16 |    1 |  0.351 0.156 |
  2725.    POINTER TRACKING:  | 137 | 16 |    1 |  0.35  0.16  |
  2726.  
  2727.    A platform moves the two US ship icons to interception positions.
  2728.  
  2729.  
  2730.  
  2731.  
  2732.  
  2733. Aguilar                                                        [Page 48]
  2734.  
  2735.  
  2736.  
  2737. RFC 965                                                    December 1985
  2738. A Format for a Graphical Communication Protocol
  2739.  
  2740.  
  2741.    TRANSFORM OBJECT:  | 126 | 55 |   15 | US_CONSTITUTION |
  2742.                         1.0   0.0 0.16
  2743.                         0.0   1.0 -0.046 |
  2744.    TRANSFORM OBJECT:  | 126 | 53 |   13 | US_NEW_JERSEY |
  2745.                         1.0   0.0 0.113
  2746.                         0.0   1.0 -0.034 |
  2747.  
  2748.    The center zooms into the interception area in order to obtain a
  2749.    larger view for further discussion.
  2750.  
  2751.    WORKSTATION WINDOW:  |  71 | 24 | 0.286 0.403 0.077 0.177 |
  2752.  
  2753.    The two platforms indicate their striking ranges using circular
  2754.    rubber bands centered at each ship. For each platform, we show first
  2755.    the echo reference point and then two echo feedback points. Typically
  2756.    there will be a large number of feedback points.
  2757.  
  2758.    RUBBER BAND:  | 138 | 10 |   0 | 0.335 0.125 |
  2759.    RUBBER BAND:  | 138 | 10 |   3 | 0.35  0.128 |
  2760.    RUBBER BAND:  | 138 | 10 |   3 | 0.37  0.128 |
  2761.  
  2762.    RUBBER BAND:  | 138 | 10 |   0 | 0.384 0.13  |
  2763.    RUBBER BAND:  | 138 | 10 |   3 | 0.367 0.128 |
  2764.    RUBBER BAND:  | 138 | 10 |   3 | 0.346 0.129 |
  2765.  
  2766.    Once the interception strategy has been agreed upon, the center zooms
  2767.    out to the original, larger picture.
  2768.  
  2769.    WORKSTATION WINDOW:  |  71 | 24 |    0.0   0.5   0.0 0.375 |
  2770.  
  2771.    The center terminates the conference
  2772.  
  2773.    END ITEM:  |   0 |  0 |
  2774.  
  2775.    At the end of a conference, the final pictures remain visible on the
  2776.    screens. In addition, the PIGCF items will be recorded in its
  2777.    entirety in order to play back the conference session if necessary.
  2778.    The conference record could also be sent to other locations as part
  2779.    of a multi-media message.
  2780.  
  2781.  
  2782.  
  2783.  
  2784.  
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790. Aguilar                                                        [Page 49]
  2791.  
  2792.  
  2793.  
  2794. RFC 965                                                    December 1985
  2795. A Format for a Graphical Communication Protocol
  2796.  
  2797.  
  2798. REFERENCES
  2799.  
  2800.    [1]   J. D. Day and H. Zimmermann, "The OSI Reference Model",
  2801.          Proceedings of the IEEE, V 71, N 12; Dec. 1983, pp 1334-1340.
  2802.  
  2803.    [2]   W. Pferd, L. A. Peralta and F. X. Prendergast, "Interactive
  2804.          Graphics Teleconferencing", IEEE Computer, V 12, N 11; Nov.
  2805.          1979, pp 62-72.
  2806.  
  2807.    [3]   K. S. Sarin, "Interactive On-Line Conferences", Ph.D. Diss.
  2808.          MIT, Dept. of EE and CS, 1984.
  2809.  
  2810.    [4]   S. Randall, "The Shared Graphic Workspace: Interactive Data
  2811.          Sharing in a Teleconference Environment", Proceedings CompCon
  2812.          82 Fall, IEEE Computer Society, pp 535-542.
  2813.  
  2814.    [5]   G. Heffron, "Teleconferencing Comes of Age", IEEE Spectrum,
  2815.          Oct. 1984, pp 61-66, pp 61-66.
  2816.  
  2817.    [6]   R. W. Hough and R. R. Panko, "Teleconferencing Systems: A
  2818.          State-of-the-Art Survey and Preliminary Analysis", SRI
  2819.          International, Menlo Park California, SRI project 3735, April
  2820.          1977.
  2821.  
  2822.    [7]   C. W. Kelly III, "An Enhanced Presence Video Teleconferencing
  2823.          System" Proc. CompCon 1982, Sept. 20-23 Washington D.C., pp
  2824.          544-551.
  2825.  
  2826.    [8]   J. Vanglian, "Private Communication", Comments on the
  2827.          suitability of videotex for on-line graphical communication.
  2828.  
  2829.    [9]   ANSI Technical Committee X3H, "Draft Proposal: Virtual Device
  2830.          Metafile", X3.122, X3 Secretariat, CBEMA, Washington, D.C.
  2831.  
  2832.    [10]  American National Standards Committee X3H3, "Virtual Device
  2833.          Interface", X3 - Information Processing Systems, Working
  2834.          Document, Jan. 2, 1985 Available from Computer and Business
  2835.          Equipment Manufacturers Association, Washington D.C.
  2836.  
  2837.    [11]  E. Van Deusen, "Graphics Standards Handbook", CC Exchange 1984,
  2838.          P.O. Box 1251, Laguna Beach, CA 92652.
  2839.  
  2840.    [12]  J. D. Foley and A. Van Dam, "Fundamentals of Interactive
  2841.          Computer Graphics", Addison-Wesley, 1982.
  2842.  
  2843.  
  2844.  
  2845.  
  2846.  
  2847. Aguilar                                                        [Page 50]
  2848.  
  2849.  
  2850.  
  2851. RFC 965                                                    December 1985
  2852. A Format for a Graphical Communication Protocol
  2853.  
  2854.  
  2855.    [13]  American National Standards Committee X3H3, "GKS -- 3D
  2856.          Extensions", X3 - Information Processing Systems, Working
  2857.          Document, Nov. 16 1984 Available from Computer and Business
  2858.          Equipment Manufacturers Association, Washington D.C.
  2859.  
  2860.    [14]  ANSI Technical Committee X3H3, "Draft Proposal: Graphical
  2861.          Kernel System", X3.124, X3 Secretariat, CBEMA, Washington, D.C.
  2862.  
  2863.    [15]  G. Enderle, K. Kansy, and G. Pfaff, "Computer Graphics
  2864.          Programming", Springer-Verlag, 1984.
  2865.  
  2866.    [16]  International Organization for Standardization "Information
  2867.          processing - Representation of numerical values in character
  2868.          strings for information interchange", ISO/DIS 6093.2, ISO/TC
  2869.          97, 1984-01-19; available from ANSI, New York, N.Y.
  2870.  
  2871.  
  2872.  
  2873.  
  2874.  
  2875.  
  2876.  
  2877.  
  2878.  
  2879.  
  2880.  
  2881.  
  2882.  
  2883.  
  2884.  
  2885.  
  2886.  
  2887.  
  2888.  
  2889.  
  2890.  
  2891.  
  2892.  
  2893.  
  2894.  
  2895.  
  2896.  
  2897.  
  2898.  
  2899.  
  2900.  
  2901.  
  2902.  
  2903.  
  2904. Aguilar                                                        [Page 51]
  2905.  
  2906.