rfc965.txt

RFC 的详细文档！

      One way to meet the aforesaid requirements is by including in an
      IGCF the means to represent object hierarchies. In such a
      hierarchy an object is a set of output primitives associated with
      a set of attribute values or a set of lower-level objects, each
      associated with a composition of transformations [12].

      Graphics segments can be used to implement objects in the lowest
      level of a hierarchy. The definition of a higher-level object can
      be represented by sequences of IGCF elements describing the
      definition process. Such a definition can be done by instantiating
      lower-level objects with specific transformation parameters. Thus
      an IGCF must incorporate brackets to mark the beginning and end of
      object definitions, object instantiations, and object
      redefinitions.


Aguilar                                                        [Page 11]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      In order to complement the mechanism for object definition, an
      IGCF must permit the use of a flexible alphabet for creating
      object identifiers that ensure the uniqueness of an identifier in
      a hierarchy. The construction of the object identifiers is not
      part of an IGCF, an IGCF only has to represent the identifiers.
      Further, an identifier has to be independent of a communication
      session and a particular graphics system so that identifiers
      created at a host during one session can be used, in other
      sessions possibly involving other hosts, to recall the objects
      they label.

      We also leave to the communicating systems the implementation of
      mechanisms to resolve duplicate identifiers when merging two
      hierarchies, created in different sessions. In this paper we shall
      limit ourselves to the warning that segment numbers do not qualify
      as identifiers because they depend on the session and state of the
      system in which they are created.

      In addition to object definition and instantiation, an IGCF should
      have elements representing operations on objects. The operations
      so far identified are: transformation, deletion, display,
      disappearance, expose, and hide. Expose is used to uncover objects
      on a screen that are hidden by other objects; hide is used to
      place an object behind others on a screen.

IV.  A PROPOSED IGCF

   A. Using the GKSM as a Basis

      An IGCF must be usable to transmit all graphical actions in a
      conference session. This suggests to base an IGCF on a standard
      session-capture graphics metafile, thus ensuring compatibility
      with a large user population. We have based the proposed IGCF,
      PIGCF, on the GKSM session-capture metafile specification because
      GKSM contains many of the elements identified for an IGCF [14]. In
      addition, the audit trail orientation of GKSM permits the
      recording of interactive communication sessions for later play
      out, and this is a feature that we anticipate will be frequently
      used.

      The GKSM is a proper subset of our PIGCF and thus any graphical
      system developed to handle the PIGCF, can read a GKSM metafile.
      Conversely, the applications using the PIGCF should have an option
      for constraining session recording only to the GKSM part, possibly
      suppressing some session events.  By doing so, we will be able to
      ship a GKSM metafile to any correspondent who has GKSM



Aguilar                                                        [Page 12]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      interpretation software.  Alternatively, an application with a
      GKSM interpreter but without an PIGCF interpreter can read a PIGCF
      file interpreting only the GKSM part and ignoring the rest.

      Whereas the GKSM was specified for the GKS system, we believe that
      the GKSM is a sound and general basis for all of our 2-D
      applications. We feel that the GKSM specification is not parochial
      to GKS systems but contains all the most useful items desired in a
      metafile. In the future, we expect to tackle applications
      requiring 3-D, like interactive repair and maintenance aids. When
      GKS be augmented with 3-D capabilities [13], we will extend the
      PIGCF with any necessary elements.

      We are aware that the GKSM specification is not part of the GKS
      standard itself but is an appendix recommending such a metafile
      format. Nevertheless, all the GKS vendor implementations that we
      know of, at the present time, support GKSM metafile output and
      interpretation. If this trend continues, as we expect, we will be
      able to exchange graphical files with a large base of GKS
      installations. There will indeed be many of them since GKS will be
      adopted as an standard by ISO and by many national standard bodies
      in the near future.

   B. Positional Information Coordinates

      Following the GKSM convention, the PIGCF positional information is
      in normalized device coordinates, NDC. Thus the originator of a
      conference must indicate the workstation window for the
      conference. This window is the sub-rectangle of the NDC space
      enclosing the area of interest for the conference. In most cases,
      the participating workstations will take this window as their own.
      However, the graphical systems should provide for the possibility
      of a workstation choosing a different workstation window, which
      may contain the conference window or just overlap it. Except for
      special cases, a conference originator should not state a
      conference workstation viewport. In this manner, each workstation
      can display its workstation viewport in the most convenient
      portion of the screen.

      There will be conferences where the participating workstations
      will maintain the positional information in world coordinates, WC.
      It might be necessary to reconstruct the world dimensions after
      transmission because such dimensions have a relevant meaning for
      the application, like sizes of components or distances. In this
      case, a workstation will have to map from WC to NDC before
      transmitting and from NDC to WC after receiving. At the outset,
      the conference originator has to specify the world window and the


Aguilar                                                        [Page 13]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      NDC viewport used in the conference in order for the conferencing
      workstations to do such mappings. These mappings could be done by
      the presentation layer, in terms of the ISO Open Systems
      Interconnection Reference Model, in a manner that is transparent
      to the communicating application programs.

      Most often all workstations will have the same world windows and
      NDC viewports. However, the graphical systems will provide for the
      possibility of a workstation choosing a different window or
      viewport, but such workstation will have to record the conference
      ones for doing the aforesaid mappings. There are graphical
      systems, like the ACM Core, that do not provide for a workstation
      transformation. In such systems, the NDC viewport is considered to
      be the workstation window for the aforesaid mappings.

   C. Layers of the PIGCF

      There are two levels in the PIGCF a lower level L and an upper one
      U. The lower level L is just the GKSM metafile specification as
      defined in Appendix E of the proposed GKS ANSI standard [14].  We
      have excerpted most of Appendix E of [14] at the end of this RFC
      as our Appendix A.  All level L elements belong to the update
      Group-1 except: SET DEFERRAL STATE, the output primitive attribute
      elements, the workstation attribute elements, CLIPPING RECTANGLE,
      CREATE SEGMENT, CLOSE SEGMENT, RENAME SEGMENT, SET SEGMENT
      PRIORITY, and SET DETECTABILITY.

      The upper level U is those elements that we believe complement the
      GKSM for general on-line graphical exchanges. This layering
      conforms to the graphics metafile level-structure described in
      Enderle et. al [15]. Under such structuring, an application
      oriented metafile can be based on graphical metafiles.

   D. PIGCF Elements in the Level U

      The level U items are encoded as GKSM user item elements so that a
      PIGCF file will conform to the GKSM metafile specification.
      Accordingly, a PIGCF file will be a GKSM metafile in its entirety.
      We use the same formatting conventions as the GKSM specification.
      Those unfamiliar with these conventions should read the beginning
      of the appendix. The following items belong to the second update
      group: the two items for object definition, the two items for
      object redefinition, the two items for object instantiation, the
      two items for normalization transformation, SELECT COMPONENT, and
      RECALL LIBRARY. The remaining items belong to the first update
      group.



Aguilar                                                        [Page 14]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      Items for Object Definition

         BEGIN DEFINITION

            | 'GKSM 120' | L |

            Indicates beginning of object definition sequence

         END DEFINITION

            | 'GKSM 121' | L | I |

            Indicates end of object definition sequence. I(Nc): object
            identifier ( N preceding c, i, r means an arbitrary number
            of characters, integers, or reals.) Objects defined
            interactively are made visible on the screen; i.e. they are
            automatically instantiated. If only the definition is to be
            kept but not the image, a DISAPPEAR item must follow.

         BEGIN REDEFINITION

            | 'GKSM 122' | L | I |

            Indicates beginning of object redefinition sequence
            I(Nc): object identifier

         END REDEFINITION

            | 'GKSM 123' | L |

            Indicates end of object redefinition sequence

      Items for Object Instantiation

         BEGIN INSTANTIATION

            | 'GKSM 124' | L | I |

            Indicates beginning of object instantiation sequence
            I(Nc): Object identifier

         END INSTANTIATION

            | 'GKSM 125' | L |

            Indicates end of object instantiation sequence



Aguilar                                                        [Page 15]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      Items for Object Manipulation

         TRANSFORM OBJECT

            | 'GKSM 126' | L | C | I | M |

            Apply transformation M to object I
            C: number of characters in identifier
            I(Nc): object id
            M(6r): upper and center rows of a 3x3 matrix representing
                   a 2D homogeneous transformation [12].
                   M 11 M 12 M 13 M 21 M 22 M 23

         DELETE OBJECT

            | 'GKSM 127' | L | I |

            I(Nc): object identifier

         DISPLAY OBJECT

            | 'GKSM 128' | L | I |

            Turn on visibility of object I
            I(Nc): object identifier

         DISAPPEAR OBJECT

            | 'GKSM 129' | L | I |

            Turn off visibility of object I
            I(Nc): object identifier

         EXPOSE OBJECT

            | 'GKSM 130' | L | I |

            Redisplay object I on top of any overlapping objects
            I(c):  object identifier

         HIDE OBJECT

            | 'GKSM 131' | L | I |

            Redisplay object I behind any overlapping objects
            I(c):  object identifier



Aguilar                                                        [Page 16]