+------------+ +-----V------+ | R |
| DEVICE | | DEVICE | | | +------------------+
| DEPENDENT | |INDEPENDENT | | |====>| |
| GRAPHICS |<-->| GRAPHICS | | |---->| CONFERENCE |
| SERVICES | | SERVICES | | | | RECORD |
| | | | | | | |
+-----|------+ |------------| | | +------------------+
| | GKSM | | |
v | INTERPRETER|<--- | | <--- INCOMING PIGCF
+------------+ +------------+ | |
| DEVICE | | GKSM | | | ===> OUTGOING PIGCF
| DRIVERS | | GENERATOR |===> | |
+------------+ +------------+ +-----+
FIGURE 2 - A CONFERENCING SOFTWARE ARCHITECTURE FOR PROCESSING PIGCF
VI. CONCLUSIONS
Teleconferencing and other multi-media applications will be part of
the communication resources available to organizations in the near
future. This will prompt computer graphics and computer communication
practitioners to address the issue of application-to-application
graphics communication. A key element of the issue is a protocol, and
a key component of the protocol is a data format. We have presented
the operational requirements for such a protocol and have proposed a
format that fulfills these requirements.
At present, none of the existing or emerging graphics standards can
be used as the needed protocol or as a format for the protocol, but
this may change as the standards evolve. We are monitoring the
standards development and will study the use of some of them as a
format basis, in particular the CGI. Nevertheless, the computer
RFC965 December 1985
A Format for a Graphical Communication Protocol
communication community badly needs experience with multi-media
conferencing implementations. In order for these applications to
happen, one can base a graphics communication protocol on an official
or on a de-facto standard that is likely to gain wide use thus
assuring interoperability with a broad user base. We believe that,
by using the GKSM session metafile, we are moving in the proper
direction.
Planning the software architecture for generating and interpreting
the proposed PIGCF has brought up some problems we will confront as
we continue our work toward the development of a complete graphics
protocol. This is being done as part of the SRI on-going program in
multimedia communications. Within this program, we are implementing
a simple multi-media conferencing prototype and will design a more
complete one. The experience from both exercises will be a valuable
input to the protocol architecture design.
RFC965 December 1985
A Format for a Graphical Communication Protocol
APPENDIX A
Excerpt from "Draft Proposal: Graphical Kernel System" [14]
E.2 Metafile Based on ISO DIS7942
This metafile may be categorized as one which aims to provide a
means of recording the exact sequence of function calls made to
GKS. Its functional capability covers the entire range of GKS
output functions, from level m to level 2. It is, therefore,
suitable for applications where the individual graphics actions
need to be 'played back', perhaps with selective graphical editing
being done by the interpreter.
Two encodings have been specified for this metafile. One encoding
is inefficient for many applications. The second allows an
unspecified binary format. The remainder of this IGCF appendix
gives full details of these metafile structures and encodings.
E.2.1 File Format and Data Format
The GKS metafile is built up as a sequence of logical data
items. The file starts with a file header in fixed format which
describes the origin of the metafile (author, installation),
the format of the following items, and the number
representation. The file ends with an end item indicating the
logical end of the file. In between these two items, the
following information is recorded in the sense of an audit
trail:
a) workstation control items and message items;
b) output primitive items, describing elementary
graphics objects;
c) attribute information, including output primitive
attributes; segment attributes, and workstation
attributes;
d) segment items, describing the segment structure and
dynamic segment manipulations;
e) user items.
RFC965 December 1985
A Format for a Graphical Communication Protocol
The overall structure of the GKS metafile is as follows:
FILE: |file |item|---|item|---|end |
|header| 1 | | i | |item|
ITEM: |item |item data record|
|header | |
ITEM |'GKSM' |identification|length of item data|
HEADER: |optional| number | in bytes |
All data items except the file header have an item header
containing:
a) the character string 'GKSM' (optional) which is
present to improve legibility of the file and to
provide an error control facility;
b) the item type identification number which indicates
the kind of information that is contained in the
item;
c) the length of the item data record.
The lengths of these fields of the item header are
implementation dependent and are specified in the file header.
The content of the item data record is fully described below
for each item type.
The metafile contains characters, integer numbers, and real
numbers marked (c), (i), (r) in the item description.
Characters in the metafile are represented according to ISO 646
and ISO 2022. Numbers will be represented according to ISO 6093
using format F1 for integers and format F2 for reals. (Remark:
Formats F1 and F2 can be written and read via FORTRAN formats I
and F respectively.)
Real numbers describing coordinates and length units are stored
as normalized device coordinates. The workstation
transformation, if specified in the application program for a
workstation writing a metafile of this format, is not performed
but WORKSTATION WINDOW and WORKSTATION VIEWPORT are stored in
data items for later usage. Real numbers may be stored as
integers. In this case transformation parameters are specified
in the file header to allow proper transformation of integers
into normalized device coordinates.
RFC965 December 1985
A Format for a Graphical Communication Protocol
For reasons of economy, numbers can be stored using an internal
binary format. As no standard exists for binary number
representation, this format limits the portability of the
metafile. The specification of such a binary number
representation is outside the scope of this document.
When exchanging metafiles between different installations, the
physical structure of data sets on specific storage media
should be standardized. Such a definition is outside the scope
of this standard.
E.3 Generation of Metafiles
Table E1 contains a list, by class, of all GKS functions which
apply to workstations of category MO, and their effects on this
GKSM. In the table, GKSM-OUT is a workstation identifier
indicating a workstation writing a metafile of this format.
The concepts of clipping rectangle and clipping indicator are
encapsulated in one metafile item which specifies a clipping
rectangle. This item is written to the metafile on activate
workstation with the values (0, 1, 0, 1), if the clipping
indicator is OFF, or the viewport of the current normalization
transformation, if the clipping indicator is ON. If the viewport
of the current normalization transformation is redefined or a
different normalization transformation is selected when the
clipping indicator is ON, a further clipping rectangle item is
written. If the clipping indicator is changed to OFF, a clipping
rectangle item (0, 1, 0, 1) is written. If the clipping indicator
is changed to ON, an item containing the viewport of the current
normalization transformation is written. This is analogous to the
handling of clipping in segments (see 4.7.6 [14]).
GKS functions which apply to workstations GKSM item created
of category MO or effect
========================================================================
Control functions
OPEN WORKSTATION (GKSM-OUT,...) - (file header)
1 (CONDITIONAL)
CLOSE WORKSTATION (GKSM-OUT) 0 (end item)
ACTIVATE WORKSTATION (GKSM-OUT) (61, 21-44)
ensure attributes
current;
enable output
RFC965 December 1985
A Format for a Graphical Communication Protocol
DEACTIVATE WORKSTATION (GKSM-OUT) disable output
CLEAR WORKSTATION (GKSM-OUT,...) 1
2
REDRAW ALL SEGMENTS ON WORKSTATION (GKSM-OUT)
UPDATE WORKSTATION (GKSM-OUT,...) 3
SET DEFERRAL STATE (GKSM-OUT,...) 4
MESSAGE (GKSM-OUT,...) 5 (message)
ESCAPE 6
________________________________________________________________________
Output Primitives
POLYLINE 11
POLYMARKER 12
TEXT 13
FILL AREA 14
CELL ARRAY 15
GENERALIZED DRAWING PRIMITIVE 16
________________________________________________________________________
Output Attributes
SET POLYLINE INDEX 21
SET LINETYPE 22
SET LINEWIDTH SCALE FACTOR 23
SET POLYLINE COLOUR INDEX 24
SET POLYMARKER INDEX 25
SET MARKER TYPE 26
SET MARKER SIZE SCALE FACTOR 27
SET POLYMARKER COLOUR INDEX 28
SET TEXT INDEX 29
SET TEXT FONT AND PRECISION 30
SET CHARACTER EXPANSION FACTOR 31
SET CHARACTER SPACING 32
SET TEXT COLOUR INDEX 33
SET CHARACTER HEIGHT 34
SET CHARACTER UP VECTOR 34
SET TEXT PATH 35
SET TEXT ALIGNMENT 36
SET FILL AREA INDEX 37
SET FILL AREA INTERIOR STYLE 38
SET FILL AREA STYLE INDEX 39
SET FILL AREA COLOUR INDEX 40
SET PATTERN SIZE 41
SET PATTERN REFERENCE POINT 42
RFC965 December 1985
A Format for a Graphical Communication Protocol
SET ASPECT SOURCE FLAGS 43
SET PICK IDENTIFIER 44
________________________________________________________________________
Workstation Attributes
SET POLYLINE REPRESENTATION (GKSM-OUT,...) 51
SET POLYMARKER REPRESENTATION (GKSM-OUT,...) 52
SET TEXT REPRESENTATION (GKSM-OUT,...) 53
SET FILL AREA REPRESENTATION (GKSM-OUT,...) 54
SET PATTERN REPRESENTATION (GKSM-OUT,...) 55
SET COLOUR REPRESENTATION (GKSM-OUT,...) 56
________________________________________________________________________
Transformation Functions
SET WINDOW of current normalization 34, 41, 42
transformation
SET VIEWPOINT of current normalization 61, 34, 41, 42
transformation
SELECT NORMALIZATION TRANSFORMATION 61, 34, 41, 42
SET CLIPPING INDICATOR 61
SET WORKSTATION WINDOW (GKSM-OUT,...) 71
SET WORKSTATION WINDOW VIEWPORT (GKSM-OUT,...) 72
Note: item 61 (CLIPPING RECTANGLE) is described more fully in E.2.2.
Note: When the current normalization transformation is altered, items
corresponding to attributes containing coordinate information are sent
(items 34, 41, and 42).
________________________________________________________________________
Segment Functions
CREATE SEGMENT 81
CLOSE SEGMENT 82
RENAME SEGMENT 83
DELETE SEGMENT 84
DELETE SEGMENT FROM WORKSTATION (GKSM-OUT,...) 84
ASSOCIATE SEGMENT WITH WORKSTATION 81, (21-44), (11-16),
(GKSM-OUT,...) (61), 82
COPY SEGMENT TO WORKSTATION (GKSM-OUT,...) (21-44), (11-16), (61)
INSERT SEGMENT (21-44), (11-16), (61)
________________________________________________________________________
RFC965 December 1985
A Format for a Graphical Communication Protocol
Segment Attributes
SET SEGMENT TRANSFORMATION 91
SET VISIBILITY 92
SET HIGHLIGHTING 93
SET SEGMENT PRIORITY 94
SET DETECTABILITY 95
________________________________________________________________________
Metafile Functions
WRITE ITEM TO GKSM > 100
________________________________________________________________________
E.4 Interpretation of Metafiles
E.4.1 Introduction
The interpretation of metafiles in GKS is described in 4.9
[14]. The effects of INTERPRET ITEM for all types of metafile
item are described in the following sections. Items are grouped
by class of functionality.
E.4.2 Control Items
Interpretation of items in this class is described under the
definitions of each item in E.5. ([14] reads "E.2.4" instead of
"E.5" which we believe is an error).
E.4.3 Output Primitives
Interpretation of items in this class generates output
corresponding to the primitive functions, except that
coordinates of points are expressed in NDC. Primitive
attributes bound to primitives are those which have originated
from interpretation of primitive attribute items in this
particular metafile (see E.4.4).
E.4.4 Output Primative Attributes
Interpretation of items in this class sets values for use in
the display of primitives subsequently originating from this
particular metafile (see E.4.3). No changes are made to entries
in the GKS state list.
RFC965 December 1985
A Format for a Graphical Communication Protocol
E.4.5 Workstation Attributes
Interpretation of items in this class has the same effect as
invocation of the corresponding GKS functions shown in Table
E1. The GKS functions are performed on all active workstations.
E.4.6 Transformations
Interpretation of a clipping rectangle item sets values for use
in clipping output primitives subsequently originating from
this particular metafile. No changes are made to entries in the
GKS state list. Interpretation of other items in this class
(WORKSTATION WINDOW and WORKSTATION VIEWPORT) causes the
invocation of the corresponding GKS functions on all active
workstations.
E.4.7 Segment Manipulation
Interpretation of items in this class has the same effect as
invocation of the corresponding GKS functions shown in Table
E1. (Item 84 causes an invocation of DELETE SEGMENT.)
E.4.8 Segment Attributes
Interpretation of items in this class has the same effect as
invocation of the corresponding GKS functions shown in Table
E1.
E.5 Control Items
FILE HEADER
| GKSM | N | D | V | H | T | L | I | R | F | RI | ZERO | ONE |
All fields in the file header item have fixed length. Numbers are
formated according to ISO 6093 - Format F1.
General Information:
GKSM 4 bytes containing string 'GKSM'
N 40 bytes containing name of author/installation
D 8 bytes date (year/month/day, e.g., 79/12/31)
V 2 bytes version number: the metafile described here has
version number 1
H 2 bytes integer specifying how many bytes of the string 'GKSM'
are repeated at the beginning of each record.
Possible values: 0, 1, 2, 3, 4
RFC965 December 1985
A Format for a Graphical Communication Protocol
T 2 bytes length of item type indicator field
L 2 bytes length of item data record length indicator field
I 2 bytes length of field for each integer in the
item data record (applied to all data marked (i)
in the item description)
R 2 bytes length of field for each real in the item data record
(applies to all data marked (r) in the item
description).
Specification of Number Representation:
F 2 bytes Possible values: 1, 2. This applies to all data
in the items marked (i) or (r) and to item type
and item data record length:
1: all numbers are formatted according to ISO 6093
2: all numbers (except in the file header) are
stored in an internal binary format
RI 2 bytes Possible values: 1, 2. This is the number
representation for data marked (r):
1 = real, 2 = integer
ZERO 11 bytes integer equivalent to 0.0, if RI = 2
ONE 11 bytes integer equivalent to 1.0, if RI = 2
After the file header, which is in fixed format, all values in
the following items are in the format defined by the file
header. For the following description, the setting:
H = 4; T = 3; F = 1
is assumed. In addition to formats (c), (i) and (r), which are
already described, (p) denotes a point represented by a pair of
real numbers (2r). The notation allows the single letter to be
preceded by an expression, indicating the number of values of
that type.
{Explanatory comments have been added to some item
specifications; these are not part of the GKS Appendix E and
they are enclosed in braces {}. A complete definition of the
generation and interpretation of the GKSM items is given by the
definition of the corresponding GKS functions [14].}
END ITEM
| 'GKSM 0' | L |
Last item of every GKS Metafile. Sets condition for the error.
RFC965 December 1985
A Format for a Graphical Communication Protocol
CLEAR WORKSTATION
| 'GKSM 1' | L | C |
Requests CLEAR WORKSTATION on all active workstations.
C(i): clearing control flag
(0 = CONDITIONAL, 1 = ALWAYS)
REDRAW ALL SEGMENTS ON WORKSTATION
| 'GKSM 3' | L | R |
Requests UPDATE WORKSTATION on all active workstations.
R(i): regeneration flag
(0 = PERFORM, 1 = SUSPEND)
DEFERRAL STATE
| 'GKSM 4' | L | D | R |
Requests SET DEFERRAL STATE on all active workstations.
D(i): deferral mode
(0 = ASAP, 1 = BNIG, 2 = BNIL, 3 = ASTI)
R(i): implicit regeneration mode
(0 = ALLOWED, 1 = SUPPRESSED)
{This item provides control over the occurrence of the visual
effect of GKS functions in order to optimize the use of
workstation capabilities according to application needs.}
MESSAGE
| 'GKSM 5' | L | N | T |
Requests MESSAGE on all active workstations.
N(i): number of characters in string
T(Nc): string with N characters.
{The message is not part of a metafile output primitives; the
message is only for interpretation by workstation operators.}
RFC965 December 1985
A Format for a Graphical Communication Protocol
ESCAPE
| 'GKSM 6' | L | FI | L | M | I | R |
Requests ESCAPE
FI(i): function identifier
L(i): length of integer data in data record
M(i): length of real data in data record
I(Li): integer data
R(Mr): real data.
{This item permits the invocation of a specific non-standard
escape function FI. The execution of the function with the
given parameters must not alter the GKS state list nor produce
geometrical output.}
E.6 Items for Output Primitives
POLYLINE
| 'GKSM 11' | L | N | P |
N(i): number of points of the polyline
P(Np): list of points
POLYMARKER
| 'GKSM 12' | L | N | P |
N(i): number of points
P(Np): list of points.
TEXT
| 'GKSM 13' | L | P | N | T |
P(p): starting point of character string
N(i): number of characters in string T
T(Nc): string with N characters from the set of ISO 646
FILL AREA
| 'GKSM 14' | L | N | P |
N(i): number of points
P(Np): list of points.
RFC965 December 1985
A Format for a Graphical Communication Protocol
CELL ARRAY
| 'GKSM 15' | L | P | Q | R | N | M | CT |
P(p),Q(p),R(p): coordinates of corner points of pixel array
(P and Q are the images of the points P and
Q specified in the function CELL ARRAY and
R is another corner)
M(i): number of rows in array
N(i): number of columns in array
CT(MNi): array of colour indices stored row by row
{This item permits passing raster images to GKS. The raster
image is defined by the colour index matrix CT, and its World
Coordinate position given by points P and Q.}
GENERALIZED DRAWING PRIMITIVE
| 'GKSM 16' | L | GI | N | P | L | M | I | R |
GI(i): GDP identifier
N(i): number of points
P(Np): list of points
L(i): length of integer data in data record
M(i): length of real data in data record
I(Li): integer data
R(Mr): real data.
{This item provides a standard way for drawing additional
non-standard output primitives. The generalized drawing
primitive GI is drawn according to the point list P and the
data record in I and R.}
E.7 Items for Output Primitive Attributes
POLYLINE INDEX
| 'GKSM 21' | L | LT |
LT(i): linetype
RFC965 December 1985
A Format for a Graphical Communication Protocol
LINEWIDTH SCALE FACTOR
| 'GKSM 23' | L | LW |
LW(r): linewidth scale factor
{In GKS, the line width is not affected by GKS transformations.
However, the effective line width is calculated as the product
of the nominal line width times the line width scale factor in
effect when a line is drawn.}
POLYLINE COLOUR INDEX
| 'GKSM 24' | L | CI |
CI(i): polyline colour index
POLYMARKER INDEX
| 'GKSM 25' | L | I |
I(i): polymarker index
MARKER TYPE
| 'GKSM 26' | L | MT |
MT(i): marker type
MARKER SIZE SCALE FACTOR
| 'GKSM 27' | L | MS |
MS(r): marker size scale factor
{In GKS, the marker size is not affected by GKS
transformations. However, the effective marker size is
calculated as the product of the nominal marker size times the
marker size scale factor in effect when a marker is drawn.}
POLYMARKER COLOUR INDEX
| 'GKSM 28' | L | CI |
CI(i): polymarker colour index
RFC965 December 1985
A Format for a Graphical Communication Protocol
TEXT INDEX
| 'GKSM 29' | L | I |
I(i): text index
TEXT FONT AND PRECISION
| 'GKSM 30' | L | F | P |
F(i): text font
P(i): text precision
(0 = STRING, 1 = CHAR, 2 = STROKE)
CHARACTER EXPANSION FACTOR
| 'GKSM 31' | L | CEF |
CEF(r): character expansion factor
{This item allows the manipulation of the width/height of the
character body. The width of the character body is scaled by
the CEF factor.}
CHARACTER SPACING
| 'GKSM 32' | L | CS |
CS(r): character spacing
TEXT COLOUR INDEX
| 'GKSM 33' | L | CI |
CI(i): text colour index
RFC965 December 1985
A Format for a Graphical Communication Protocol
CHARACTER VECTORS
| 'GKSM 34' | L | CH | CW |
CH(2r): character height vector
CW(2r): character width vector
Note: These vectors are the height and width vectors described
in 4.4.5 of [14].
{The character height vector is parallel to the character up
vector and has a length equal to character height. The
character height specifies the height of a capital letter. The
character width vector is perpendicular to the height vector,
in the direction of the character baseline, and has the same
length.}
TEXT PATH
| 'GKSM 35' | L | P |
P(i): text path
(0 = LEFT, 1 = RIGHT, 2 = UP, 3 = DOWN)
TEXT ALIGNMENT
| 'GKSM 36' | L | H | V |
H(i): horizontal character alignment
(0 = NORMAL, 1 = LEFT, 2 = CENTRE, 3 = RIGHT)
V(i): vertical character alignment
(0 = NORMAL, 1 = TOP, 2 = CAP, 3 = HALF, 4 = BASE,
5 = BOTTOM)
FILL AREA INDEX
| 'GKSM 37' | L | I |
I(i): fill area index
FILL AREA INTERIOR STYLE
| 'GKSM 38' | L | S |
S(i): fill area interior style
(0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH)
RFC965 December 1985
A Format for a Graphical Communication Protocol
FILL AREA STYLE INDEX
| 'GKSM 39' | L | SI |
SI(i): fill area style index
FILL AREA COLOUR INDEX
| 'GKSM 40' | L | CI |
CI(i): fill area colour index
PATTERN SIZE
| 'GKSM 41' | L | PW | PH |
PW(2r): pattern width vector
PH(2r): pattern height vector
{One style for filling areas is with a pattern of color cells.
Such a pattern is defined by an array of color indices which is
mapped into a pattern rectangle with dimensions given by PW and
PH.}
PATTERN REFERENCE POINT
| 'GKSM 42' | L | P |
P(p): reference point
{One style for filling areas is with a pattern of color cells.
Such a pattern is defined by an array of color indices which is
mapped into a pattern rectangle whose lower left corner is
given by P.}
RFC965 December 1985
A Format for a Graphical Communication Protocol
ASPECT SOURCE FLAGS
| 'GKSM 43' | L | F |
F(13i): aspect source flags
(0 = BUNDLED, 1 = INDIVIDUAL)
{An application can set an output primitive attribute to either
bundled or individual. Bundled attributes are
workstation-dependent, their binding is delayed, and their
values can change dynamically. Individual attributes are global
attributes, they are bound immediately, and their value is
static and cannot be manipulated.}
PICK IDENTIFIER
| 'GKSM 44' | L | P |
P(i): pick identifier
E.8 Items for Workstation Attributes
POLYLINE REPRESENTATION
| 'GKSM 51' | L | I | LT | LW | CI |
I(i): polyline index
LT(i): linetype number
LW(r): linewidth scale factor
CI(i): polyline colour index
POLYMARKER REPRESENTATION
| 'GKSM 52' | L | I | MT | MS | CI |
I(i): polymarker index
MT(i): marker type
MS(r): marker size scale factor
CI(i): polymarker colour index
RFC965 December 1985
A Format for a Graphical Communication Protocol
TEXT REPRESENTATION
| 'GKSM 53' | L | I | F | P | CEF | CS | CI |
I(i): text index
F(i): text font
P(i): text precision
(0 = STRING, 1 = CHAR, 2 = STROKE)
CEF(r): character expansion factor
CS(r): character spacing
CI(i): text colour index
FILL AREA REPRESENTATION
| 'GKSM 54' | L | I | S | SI | CI |
I(i): fill area index
S(i): fill area interior style
(0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH) SI(i): fill
area style index
CI(i): fill area colour index
PATTERN REPRESENTATION
| 'GKSM 55' | L | I | N | M | CT |
I(i): pattern index
N(i): number of columns in array*
M(i): number of rows in array
CT(MNi): table of colour indices stores row by row
{* The ANSI document reads "area" instead of "array".}
{One style for filling areas is with a pattern of color cells.
Such a pattern is defined by a pattern representation.}
COLOUR REPRESENTATION
| 'GKSM 56' | L | CI | RGB |
CI(i): colour index
RGB(3r): red, green, blue intensities
RFC965 December 1985
A Format for a Graphical Communication Protocol
E.9 Items for Transformations
CLIPPING RECTANGLE
| 'GKSM 61' | L | C |
C(4r): limits of clipping rectangle (XMIN, XMAX, YMIN, YMAX)
WORKSTATION WINDOW
| 'GKSM 71' | L | W |
W(4r): limits of workstation window (XMIN, XMAX, YMIN, YMAX)
{GKS includes a workstation transformation that maps a
rectangle of the NDC space (a workstation window) into a
rectangle of the device coordinate space (a workstation
viewport).}
WORKSTATION VIEWPORT
| 'GKSM 72' | L | V |
V(4r): limits of workstation viewport (XMIN, XMAX, YMIN, YMAX)
E.10 Items for Segment Manipulation
CREATE SEGMENT
| 'GKSM 81' | L | S |
S(i): segment name
CLOSE SEGMENT
| 'GKSM 82' | L |
indicates end of segment
RENAME SEGMENT
| 'GKSM 83' | L | SO | SN |
SO(i): old segment name
SN(i): new segment name
RFC965 December 1985
A Format for a Graphical Communication Protocol
DELETE SEGMENT
| 'GKSM 84' | L | S |
S(i): segment name
E.11 Items for Segment Attributes
SET SEGMENT TRANSFORMATION
| 'GKSM 91' | L | S | M |
S(i): segment name
M(6r): transformation matrix
upper and center rows of a 3x3 matrix representing
a 2D homogeneous transformation [9]
M 11 M 12 M 13 M 21 M 22 M 23
{This differs from the ANSI X3.124 Jan. 5 1984 document, in the
matrix elements indicated. We believe there is an error in such
document.}
SET VISIBILITY
| 'GKSM 92' | L | S | V |
S(i): segment name
V(i): visibility
(0 = VISIBLE, 1 = INVISIBLE)
SET HIGHLIGHTING
| 'GKSM 93' | L | S | H |
S(i): segment name
H(i): highlighting
(0 = NORMAL, 1 = HIGHLIGHTED)
SET SEGMENT PRIORITY
| 'GKSM 94' | L | S | P |
S(i): segment name
P(r): segment priority
RFC965 December 1985
A Format for a Graphical Communication Protocol
SET DETECTABILITY
| 'GKSM 95' | L | S | D |
S(i): segment name
D(i): detectability
(0 = UNDETECTABLE, 1 = DETECTABLE)
E.12 User Items
USER ITEM
| 'GKSMXXX' | L | D |
XXX > 100
D: user data (L bytes)
{The PIGCF level U items are encoded as GKSM USER ITEM elements
so that a PIGCF file will conform to the GKSM metafile
specification.}
RFC965 December 1985
A Format for a Graphical Communication Protocol
APPENDIX B
Example of PIGCF Use in Conferencing
This section presents an example illustrating the proposed PIGCF
graphical component in an audio-graphics conference exchange. We
present only the graphical part of the conference exchange, which
actually would be complemented with speech. For the sake of briefness
the example does not contain all the parameter negotiation that a
conference set-up would require.
The example is about an on-line audio-graphics conference between a
Navy command and control center and a Navy task force. The PIGCF
items shown do not belong to a single transmission stream. The stream
they belong to is determined by the station that transmits them, and
the identification of the transmitter belongs to lower level
communication protocols. We use the character encoding, rather than
the binary one, for this PIGCF example. We illustrate just a few of
the possible groups of items that could be batched in this example.
The plot of the example is as follows.
The command center (center) establishes a conference with some ships
in a task force (platforms) to coordinate the interception of an
unidentified ship that has been sighted in a conflict area. After
recalling graphical libraries, all conference sites can see in their
screens a map of the sighting area as well as iconic representations
of the task force ships. Then the center interactively draws an
iconic representation of the unidentified vessel, scales it, and
places it in the sighting location.
The platforms explain possible courses of action using graphical
pointers. The center draws the expected trajectory of the
unidentified ship and the platforms situate the task force icons at
the expected points of interception. Then the center zooms into the
interception area and the platforms use rubber bands to discuss
interception maneuvers.
Now we proceed to list the PIGCF items exchanged. The center
initiates the conference graphical set-up with the FILE HEADER item
to set basic representation parameters for the graphical
information to be exchanged. This item can be interpreted
according to its definition in E.5 [14]. The most important
parameter selections for this example are:
i) The items contain 0 characters of the "GKSM" string in the
identification field of the item header.
ii) The item type indicator field containing the PIGCF
RFC965 December 1985
A Format for a Graphical Communication Protocol
item number is three bytes long in each item.
iii) The integers are 4 bytes long, and the reals 6 bytes long.
iv) The item data record length indicator is 2 bytes long.
We will obey the PIGCF specification field lengths and the aforesaid
field length settings. However, we will add one space before and
after the "|" separator to improve legibility. Also, every item will
be preceded with its name to help identification.
FILE HEADER:
| GKSM | center | 84/11/10 | 1 | 0 | 3 | 2 | 4 | 6 | 1 | 1
| | |
The center states the boundaries of the work station window for the
conference.
WORKSTATION WINDOW: | 71 | 24 | 0.0 0.5 0.0 0.375 |
In this example, we assume that the conferencing work stations use
world coordinates for the internal representation of positional
information. Accordingly, the center states the boundaries of the
world window for the normalization transformation used in the
conference.
SET WINDOW: | 134 | 28 | 0.0 320.0 0.0 240.0 |
The center informs the location of its local NDC viewport, however,
other conferees can choose different NDC viewports for the same
transformation, but their work station window should include the
conference's. All systems record the conference: world window, NDC
viewport, and work station widow.
SET VIEWPORT: | 135 | 28 | 0.0 0.5 0.0 0.375 |
The center recalls graphical libraries containing geographical maps
of the crisis area and icons of the task forces in the area. It
also displays a graphical object that provides a background picture.
RECALL LIBRARY: | 139 | 9 | caribbean |
DISPLAY OBJECT: | 128 | 11 | coast_lines |
RECALL LIBRARY: | 139 | 10 | task_units |
The center proceeds to instantiate one of the task forces in the
task_units library. This is done by recalling some of the library
objects and applying transformations to the objects, later. Since set
window, set viewport, and recall library belong to the update
RFC965 December 1985
A Format for a Graphical Communication Protocol
Group-2, they can be batched until display object, from update
Group-1, is entered. The second recall library can be batched
together with the following begin instantiation until display object
is produced. The rest of the example contains more cases of item
sequences which can be batched; however, for briefness we do not
indicate any more of them.
BEGIN INSTANTIATION: | 124 | 15 | US_CONSTITUTION |
DISPLAY OBJECT: | 128 | 15 | US_CONSTITUTION |
TRANSFORM OBJECT: | 126 | 55 | 15 | US_CONSTITUTION |
0.1 0.0 0.0 0.0 0.1 0.0 |
TRANSFORM OBJECT: | 126 | 55 | 15 | US_CONSTITUTION |
0.1 0.0 0.312 0.0 0.1 0.078 |
END INSTANTIATION: | 125 | 0 |
BEGIN INSTANTIATION: | 124 | 13 | US_NEW_JERSEY |
DISPLAY OBJECT: | 128 | 13 | US_NEW_JERSEY |
TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY |
0.1 0.0 0.0 0.0 0.1 0.0 |
TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY |
0.1 0.0 0.312 0.0 0.1 0.093 |
END INSTANTIATION: | 125 | 0 |
Next the center sets values for two output primitive attributes in
preparation for drawing a new icon on the screens. We assume that all
the other attributes have been assigned default values as a result of
the conference set-up.
POLYLINE INDEX: | 21 | 4 | 20 |
POLYLINE COLOUR INDEX: | 24 | 4 | 200 |
The following items correspond to the interactive definition of the
unidentified vessel. Since the definition is done interactively, the
vessel image remains visible on the screens after definition.
BEGIN DEFINITION: | 120 | 0 |
POLYLINE: | 11 | 64 | 5 |
0.047 0.063 0.063 0.047 0.125 0.047 0.14 0.063 0.047 0.047 |
POLYLINE: | 11 | 52 | 3 |
0.078 0.063 0.078 0.078 0.109 0.078 0.109 0.063 |
END DEFINITION: | 121 | 8 | sighting |
Then the unidentified vessel "sighting" is scaled and placed at the
sighting site.
RFC965 December 1985
A Format for a Graphical Communication Protocol
BEGIN INSTANTIATION: | 124 | 8 | sighting |
TRANSFORM OBJECT: | 126 | 48 | 8 | sighting |
0.2 0.0 0.0
0.0 0.2 0.0 |
TRANSFORM OBJECT: | 126 | 48 | 8 | sighting |
0.1 0.0 0.156
0.0 0.1 0.016 |
END INSTANTIATION: | 125 | 0 |
The center and the platforms use graphical pointer movements to
discuss possible routes the unidentified vessel might follow. We only
show a few pointer updates. In practice, there would typically be a
large number of points transmitted to convey the movement of the
pointers over the screens.
from the center:
POINTER TRACKING: | 137 | 16 | 0 | 0.39 0.032 |
POINTER TRACKING: | 137 | 16 | 0 | 0.388 0.035 |
POINTER TRACKING: | 137 | 16 | 0 | 0.388 0.039 |
POINTER TRACKING: | 137 | 16 | 0 | 0.386 0.04 |
from one of the platforms:
POINTER TRACKING: | 137 | 16 | 0 | 0.22 0.016 |
POINTER TRACKING: | 137 | 16 | 0 | 0.222 0.159 |
POINTER TRACKING: | 137 | 16 | 0 | 0.233 0.157 |
POINTER TRACKING: | 137 | 16 | 0 | 0.24 0.155 |
The center now draws the expected route to be followed by the
unidentified ship. This time the pointer trace is recorded on the
screen by drawing a line.
POINTER TRACKING: | 137 | 16 | 1 | 0.388 0.038 |
POINTER TRACKING: | 137 | 16 | 1 | 0.386 0.038 |
POINTER TRACKING: | 137 | 16 | 1 | 0.386 0.052 |
POINTER TRACKING: | 137 | 16 | 1 | 0.375 0.078 |
POINTER TRACKING: | 137 | 16 | 1 | 0.369 0.105 |
POINTER TRACKING: | 137 | 16 | 1 | 0.361 0.125 |
POINTER TRACKING: | 137 | 16 | 1 | 0.352 0.144 |
POINTER TRACKING: | 137 | 16 | 1 | 0.351 0.156 |
POINTER TRACKING: | 137 | 16 | 1 | 0.35 0.16 |
A platform moves the two US ship icons to interception positions.
RFC965 December 1985
A Format for a Graphical Communication Protocol
TRANSFORM OBJECT: | 126 | 55 | 15 | US_CONSTITUTION |
1.0 0.0 0.16
0.0 1.0 -0.046 |
TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY |
1.0 0.0 0.113
0.0 1.0 -0.034 |
The center zooms into the interception area in order to obtain a
larger view for further discussion.
WORKSTATION WINDOW: | 71 | 24 | 0.286 0.403 0.077 0.177 |
The two platforms indicate their striking ranges using circular
rubber bands centered at each ship. For each platform, we show first
the echo reference point and then two echo feedback points. Typically
there will be a large number of feedback points.
RUBBER BAND: | 138 | 10 | 0 | 0.335 0.125 |
RUBBER BAND: | 138 | 10 | 3 | 0.35 0.128 |
RUBBER BAND: | 138 | 10 | 3 | 0.37 0.128 |
RUBBER BAND: | 138 | 10 | 0 | 0.384 0.13 |
RUBBER BAND: | 138 | 10 | 3 | 0.367 0.128 |
RUBBER BAND: | 138 | 10 | 3 | 0.346 0.129 |
Once the interception strategy has been agreed upon, the center zooms
out to the original, larger picture.
WORKSTATION WINDOW: | 71 | 24 | 0.0 0.5 0.0 0.375 |
The center terminates the conference
END ITEM: | 0 | 0 |
At the end of a conference, the final pictures remain visible on the
screens. In addition, the PIGCF items will be recorded in its
entirety in order to play back the conference session if necessary.
The conference record could also be sent to other locations as part
of a multi-media message.
RFC965 December 1985
A Format for a Graphical Communication Protocol
REFERENCES
[1] J. D. Day and H. Zimmermann, "The OSI Reference Model",
Proceedings of the IEEE, V 71, N 12; Dec. 1983, pp 1334-1340.
[2] W. Pferd, L. A. Peralta and F. X. Prendergast, "Interactive
Graphics Teleconferencing", IEEE Computer, V 12, N 11; Nov.
1979, pp 62-72.
[3] K. S. Sarin, "Interactive On-Line Conferences", Ph.D. Diss.
MIT, Dept. of EE and CS, 1984.
[4] S. Randall, "The Shared Graphic Workspace: Interactive Data
Sharing in a Teleconference Environment", Proceedings CompCon
82 Fall, IEEE Computer Society, pp 535-542.
[5] G. Heffron, "Teleconferencing Comes of Age", IEEE Spectrum,
Oct. 1984, pp 61-66, pp 61-66.
[6] R. W. Hough and R. R. Panko, "Teleconferencing Systems: A
State-of-the-Art Survey and Preliminary Analysis", SRI
International, Menlo Park California, SRI project 3735, April
1977.
[7] C. W. Kelly III, "An Enhanced Presence Video Teleconferencing
System" Proc. CompCon 1982, Sept. 20-23 Washington D.C., pp
544-551.
[8] J. Vanglian, "Private Communication", Comments on the
suitability of videotex for on-line graphical communication.
[9] ANSI Technical Committee X3H, "Draft Proposal: Virtual Device
Metafile", X3.122, X3 Secretariat, CBEMA, Washington, D.C.
[10] American National Standards Committee X3H3, "Virtual Device
Interface", X3 - Information Processing Systems, Working
Document, Jan. 2, 1985 Available from Computer and Business
Equipment Manufacturers Association, Washington D.C.
[11] E. Van Deusen, "Graphics Standards Handbook", CC Exchange 1984,
P.O. Box 1251, Laguna Beach, CA 92652.
[12] J. D. Foley and A. Van Dam, "Fundamentals of Interactive
Computer Graphics", Addison-Wesley, 1982.
RFC965 December 1985
A Format for a Graphical Communication Protocol
[13] American National Standards Committee X3H3, "GKS -- 3D
Extensions", X3 - Information Processing Systems, Working
Document, Nov. 16 1984 Available from Computer and Business
Equipment Manufacturers Association, Washington D.C.
[14] ANSI Technical Committee X3H3, "Draft Proposal: Graphical
Kernel System", X3.124, X3 Secretariat, CBEMA, Washington, D.C.
[15] G. Enderle, K. Kansy, and G. Pfaff, "Computer Graphics
Programming", Springer-Verlag, 1984.
[16] International Organization for Standardization "Information
processing - Representation of numerical values in character
strings for information interchange", ISO/DIS 6093.2, ISO/TC
97, 1984-01-19; available from ANSI, New York, N.Y.