RFC 965
Format for a graphical communication protocol
RFC 965 ✨
Part 1 of 11 🎀
Okay bestie, so RFC 965 is a December 1985 doc from the Network Working Group, written by Lorenzo Aguilar at SRI International. It's called "A Format for a Graphical Communication Protocol" 🦋 The header doesn't list a category or say what it obsoletes or updates, so there's nothing to report on that front 💅
Status of This Memo 🌸
This paper lays out the requirements for a graphical format that could be the base of a graphical on-line communication protocol. The proposal is an Interactive Graphical Communication Format built on the GKSM session metafile. Distribution of this memo is unlimited 💖
ABSTRACT 🔥
This paper lays out the requirements for a graphical format that could be the base of a graphical on-line communication protocol. The argument is that on-line graphical communication is basically like graphical session capture, which is why we propose an Interactive Graphical Communication Format using the GKSM session metafile 🧚
We go through the things we think complement the GKSM metafile as a format for on-line interactive exchanges. One big application area is multi-media on-line conferencing, so we also present a conferencing software architecture for processing the proposed format. We're making this format spec available to anyone planning multi-media conferencing systems, as a contribution toward a graphical communication protocol that lets these systems interoperate 🫶
We hope this encourages discussion of multimedia data exchange and proposals for solutions. At SRI, we stay open to exploring alternatives, and we'll keep up our research and development work in this problem area ✨
ACKNOWLEDGEMENTS 🎀
The author wants to thank Andy Poggio of SRI, who made lots of insightful, valuable suggestions that trimmed and improved level U. His expertise in multi-media communication systems and his encouragement were a seriously positive input to the creation of this IGCF 👑 Dave Worthington of SRI also joined the project discussions about this IGCF. Thanks are also due to Tom Powers, chairman of ANSI X3H33, who opened the forum for presenting an earlier version of this paper, which gave us the invaluable feedback of the X3H33 members 🙌 Jon Postel of ISI recommended a bunch of changes that made this paper more coherent and accessible 📚
Most of the work in this paper was sponsored by the U.S. Navy, Naval Electronic Systems Command, Washington D.C., under Contract No. N00039-83-K-0623 💼
I. INTRODUCTION 🦋
A. Use of a Graphical Communication Protocol 💜
In computer communications, a protocol is a procedure run by two cooperating processes so they can reach a meaningful exchange of information. A graphical communication protocol is needed to exchange interactive vector graphics information, possibly alongside other media like voice, text, and video 🎬 In this multi-media environment, computer vector graphics is a key player, because it takes full advantage of the processing power of communicating computers and human users. That makes it way more compact than digital images, which aren't generated from data structures containing positional information. Vector graphical communication trades heavy storage and processing at the communicating ends for a low volume of exchanged data, since workstations with graphical hardware swap graphics commands along with large data structures at the transmitter and receivers. So one command can cause huge changes in the data displayed at both the sending and receiving ends 🤯
It helps to place this protocol at one of the functional levels of the ISO Open Systems Interconnection Reference Model [1]. In that model, graphical protocol functionality mainly belongs in the application level, though some of it fits in the presentation level. We can tell apart these components of a communication protocol:
- a) a data format
- b) rules to interpret transmitted data
- c) state information tables
- d) message exchange rules
A format for a graphical protocol should provide the layout of the transmitted data and show how the formatted data are tied to interpretation rules. The format you pick shapes the state tables you need to keep for correctly processing the data stream. The graphical format has only a minor influence on the exchange rules, which should provide for efficient use of transmission capacity to carry data in that format 📦 Besides the graphical format, other parts of a graphical protocol also decide the state tables and exchange rules. This paper focuses on the data format and doesn't discuss message exchange. Still, we do talk about a simple software architecture for generating and interpreting data streams written in our proposed format. We also give an example of applying the proposed format (in Appendix B), which shows the kinds of message exchanges needed to set up a communication session and trade graphical information 🧩
People in the computer communication field know how important widely accepted protocols are for meaningful communication. Those who need interactive graphical communication today are stuck with no standard for computer graphics communication among application programs 😤 Still, we can build on work the computer graphics standard bodies have already done. In fact, ISO and ANSI have already appended the GKSM session metafile specification to the Graphical Kernel System (GKS) standard, and it has lots of the features an on-line graphical protocol needs 🌈
Here's an example of graphical communication that shows how real-time the interaction is and how graphics can be used alongside other media. With audio-graphics conferencing, a group of people at two or more locations can hold an electronic meeting. They can talk over voice channels while sharing a graphics space where they display, point at, and manipulate vector graphics pictures [2, 3, 4, 5, 6, 7] 🎤
The conference voice channels can come from a variety of transmission technologies. The shared graphics space can run on workstations that display the pictures and allow graphical interaction and communication with other locations. Operations on pictures involve changes to the underlying data structures, but we only care about graphical database updating to the extent that it supports the communication 🖼️
To play back a recorded graphical session, we need to know the rate at which graphical elements must be shown and graphical operations recreated. We don't include a way to indicate session timing in a format, because our main goal is mixed-media communication environments. There, play-out timing has to match across media so they stay coordinated, so we leave timing mechanisms to conference-control modules 🕰️ We also leave it to conference control processes to decide how a conferee station emulates a graphical capability it lacks. One example is showing color on monochrome displays 🖤
B. Relationship to Other Work 🧠
There are a bunch of actual and proposed standards for graphics information exchange. Below, we explain why, right now, none of them can be the basis of an on-line protocol. Some may become suitable as they evolve, though. Plus, experience from early on-line graphics communication systems will show what standard extensions are needed to support more advanced systems. That insight could also be used to modify the format proposed here, which we see as an initial approach to the problem. Down the road, the format in this paper could be replaced by one of those extended standards 🔮
The North American Presentation Level Protocol Syntax, NAPLPS, specifies a data syntax and application semantics for one-way teletext information dissemination and two-way videotex database access and transaction services. The two-way videotex operational model is built on the idea of a consumer and an information provider or service operator. Because of that asymmetry, almost all graphical information is assumed to flow from the provider toward the consumer. In the other direction, the consumer mostly manipulates and sends alphanumeric information. Even though this standard includes geometric drawing primitives, a user can't directly modify shapes drawn with those primitives 😭
Right now NAPLPS doesn't include interaction concepts like picture transformations or detectability, which are basic to a shared graphical workspace. It also doesn't support key graphics input devices like mice, joysticks, stylus, rotating balls, or light pens, which are needed for simple, efficient editing of the shared workspace 🖱️
We want user-to-user graphical communication with the sophistication and ease of interaction you get from today's interactive graphics packages. Computer vector graphics can deliver both, because its paradigm includes an application program that keeps track of a huge number of possible state changes in the displayed picture. On top of that, the application drives a powerful graphics package, like GKS or ACM Core. In the videotex paradigm, the provider application only allows limited changes to the displayed image, mostly database retrieval requests. And that paradigm has no separate graphics package. Both the graphics functionality and the data format get squished into a coding specification, like NAPLPS 🙄
Here we're mainly interested in business and industrial applications where vector graphics information flows two ways, or multi-way, among users. Those users will have workstations with serious processing and storage capacity and high-resolution monitors. Plus, the communication will run on a distributed architecture that doesn't depend on a central server host, unlike the provider application host in videotex 🏢💅
Okay bestie, so the consumer end of videotex right now is basically cheap microprocessor decoders or personal computer boards, usually hooked up to low-res standard TV sets and PC displays 📺 It's giving budget setup 💀 But sophisticated decoders and high-resolution graphics devices are already affordable, so the videotex standards need some big revisions to keep up ✨ Especially, they should treat the receiving devices as able to host a programmable customer-application process 🧚 Once that happens, videotex protocols will be applicable to our intended problem areas [8]. Iconic glow-up 💅
The Computer Graphics Metafile [9] is about to become an international and North American standard for graphics picture interchange 🎀 Obsessed for it, but here's the tea: the CGM, also referred as VDM, is a picture-capture metafile. It only records the final result of a graphics session 🙈 It is not meant to record the picture-creation process, and that process is the whole point for the interactive applications we're going after. Plus, the CGM is currently aimed at a minimum support of GKS functionality, so it'll be some time before it has some of the elements needed for on-line interaction 🫠 If, after those additions, the CGM gets augmented for session capture, it would become a logical candidate for a protocol format 🦋
Next up is the Computer Graphics Interface, CGI also referred as VDI [10] 🌈 The CGI is a standard functional and syntactical specification of the control and data exchange between device-independent graphics software and one or more device-dependent graphics device drivers. Its major use is communication between an application host and a graphics device, but the asymmetry between its intended communicating ends makes it hard to use CGI for our purposes 😭
Now, we want to take advantage of intelligence and storage at the communicating ends so we can get powerful information-conveying effects over narrow-bandwidth channels 💜 That means the format we want has to include items for communication between two applications. The CGI streams, on the other hand, are processed by device-dependent drivers rather than by applications. The CGI spec does include application data elements, but only so they can be stored in a metafile. The drivers don't interpret them. Applications that read the metafile do, some time after the metafile was created ⭐
The CGI also has elements for obtaining graphical input, plus elements for inquiring graphics device capabilities, characteristics, and states. Later, in Section III, we explain why those two classes of elements are unnecessary for the communication protocol we need 🍓 As the CGI evolves it will undergo significant changes, and in the future it may become a very suitable kernel for the graphics protocol we seek. Honestly, the CGI will be the communication protocol between graphical application hosts and graphics terminals 👑 At SRI we're tracking its evolution, and we're interested in defining a format based on the CGI 🫶
Last but not least, the Initial Graphics Exchange Specification [11] isn't aimed at our primary area of interest 🙈 IGES defines standard file and language formats for storing and transmitting product-definition data. That data can be used, in part, to generate engineering drawings and other graphical representations of engineering products. Besides the CAD orientation of IGES, the graphical output function may be secondary to other goals, like transmitting numerical-control machine instructions 🔧
2. OPERATIONAL REQUIREMENTS AND USABILITY ✨
okay so this part is where the authors get real about what an IGCF (interactive graphical communication format) actually NEEDS to do to be useful. the main goal is laying the groundwork for a vector graphics format that can be the basis for an on-line graphical communication protocol 🎀 bestie, they call it an "interactive graphical communication format," or IGCF, and we're going to see what it has to be like. let's gooo 💅
A. Interoperation of Heterogeneous Systems 🌈
okay first up, an IGCF MUST let systems talk to each other even when they're totally different, like different hardware AND different graphics software interfaces. this is literally the foundation 😭 it's what lets similar graphics apps on dissimilar machines actually vibe together. examples they give are graphics editors, CAD systems, and graphical database retrieval programs, talking to other editors, CAD programs, and graphical databases respectively. main character energy for interoperability 👑
B. Picture Capture 📸
an IGCF MUST be usable for exchanging static pictures (aka picture capture), but it MUST NOT be limited to only recording the final picture 🙈 there's gonna be picture swapping during the convo, and people will want to save the state of a picture at different points during a live graphics session. they also foresee IGCF libraries full of object definitions and pictures you can drop into new pictures, which is so iconic 🧚
metafiles have been the go-to for capturing pictures for ages, so there's a strong reason to base an IGCF on a metafile standard. that way it stays compatible with a big pile of metafile sources and consumers 🫶
C. Prompt Transmission ⏩
in stuff like audiographics conferencing, the real-time feel is everything 😭 so object creations and manipulations MUST be sent as they happen, not just as a final result. a lot of the info can go out while something's still being built or moved, maybe alongside voice. but since both building AND moving have to be sent, you can't send infinite in-between states, that's just not economical 💀
so the third requirement is that IGCF elements give fine "granularity" to show the dynamics of building and moving stuff ✨ they think basic building blocks like polygons, markers, polylines, and text strings are enough, and those MUST... well, transmitted only when they're completed. partial constructions do NOT need to be sent 🦋
wait the hard part is manipulations. an IGCF should have segment transformations, segment highlighting, and segment visibility on/off, but the transmitter has to decide how often to sample an ongoing transformation and send its current state. that choice depends on how much bandwidth is available 🌸
D. Low Traffic Volume 📉
in a lot of the apps they're imagining, graphics go over narrow bandwidth channels, so minimizing traffic is essential 🍓 a bunch of requirements get placed on an IGCF to take advantage of how graphics communication works, all to keep traffic low.
an IGCF can cut traffic by including the basic geometric objects that so many other objects are built from ✨ and it SHOULD... no wait, the text says an IGCF "should permit" reusing objects to create more complex ones, so: an IGCF SHOULD allow objects to be used to build more complex objects. reuse is super common, so this saves traffic AND storage 💜
E. Preservation of Application Semantic Units 🏆
an IGCF MUST include elements that represent graphical objects matching real-world entities in the target application. for example, in a Navy app the things that matter are carriers, submarines, planes, and so on 🚢 they want to send these semantic units across systems and treat them as single objects, because lots of apps are built around creating and operating units like that.
if an IGCF has elements for these units, traffic drops, because the entity definitions only get sent once and then get reused, and the entities get manipulated as whole units instead of piece by piece 🫶
there's a small set of main operations you can apply to a graphical object, and an IGCF MUST have elements that represent those operations 💅 unlike dumb terminals that just get screen refresh info from a host, the authors picture intelligent workstations that swap encoded operations, interpret them, and apply them to objects stored locally. the smart-device glow-up is real 🌈
F. Transmission Batching 📦
okay so we already said it's good to show users the real-time tempo of graphics exchanges. the good news is you don't have to send every IGCF element right away to do that 🦋 IGCF elements should be split into two groups: those that change what's shown on screen, and those that don't. both can change the stored graphical data, though.
only the elements that change the displayed picture need to go out immediately, because those are the ones a human actually sees and reacts to ✨ the second group can be batched and queued until an element from the first group gets submitted. the authors call the first class update Group-1, and the second update Group-2 💜
this split is a big deal for packet communications, since every packet carries a hefty load of overhead control traffic 😭 so it is mandatory... well, the text says batching client data into a packet MUST be done as much as possible to cut total traffic. the batch size can change based on network traffic and how fast conference hosts respond 🌸 during congestion the units may need to grow, so there are fewer messages, and when things calm down they can shrink again, so there are more messages 🎀
G. Simple Translation Between IGCF and User Interface 🔄
remember requirement one? an IGCF MUST let related heterogeneous graphics apps interoperate 🌷 the goal is communication between human users, or between a human and a database. so there has to be a mapping between user interface commands and IGCF elements. using the commands themselves as the IGCF elements is a no-go, ngl, because then the exchange would depend on the systems talking, and every pair would need its own ad-hoc protocol 💀
there's another usability thing: there MUST be a simple mapping between IGCF elements and the actions behind the UI commands used for graphical communication 💖 this has to be simple because every communicating system needs a translator, and ideally that translator is super simple. including command sequence delimiters in the IGCF apparently helps, since they let you keep less state info while processing an IGCF stream 🧚
they've checked the mapping from one set of audiographics conferencing commands to the IGCF in this paper ✅ going from UI commands to IGCF is direct and efficient 🦋 going the other way, IGCF to UI commands, is harder. they expect that to speed things up, they'll have to map IGCF elements to calls to lower-level subroutines that carry out the UI actions. it's conceptually no more complex than translating to the commands themselves, but it's gonna take a lot more programming 😭🔥
III. ELEMENTS OF AN IGCF ✨
IGCF Element Classes
okay so, here's the lineup 💅 we think an IGCF should have these classes of elements so it can swap vector graphics under the requirements from the last section. The classes match the usual function classes in computer graphics interfaces, and each one holds elements for interface primitives and attributes. We're not listing every element in each class 🫶 because the proposed IGCF already shows them all off.
heads up, two categories are missing from the list: functions for querying the status of a graphics system, and input functions 👀. The reason is that an IGCF only needs elements for actions that change the state of the communicating graphics systems, and inquire functions obviously don't change anything. Input functions do cause a local change at the sending end, but the input command itself doesn't need to be sent. The receivers just need the input data, in IGCF representation, and they can process it however they want, maybe even simulating the local input action 🧚
Control
Elements for workstation: initialization, control and transformation; and elements for normalization transformation. (The normalization and workstation transformations can be used to implement zooming.) 🔍
Primitive attributes
Elements for primitive, segment, and workstation attributes. 🎀
Output primitives
Elements for output primitives. 🌸
Segmentation
Elements for basic segmentation and workstation independent segment storage. 🧩
Object manipulations can be implemented with segment transformations. Object insertion can be implemented using segment recall and segment visibility. Object deletion can be implemented using segment deletion and segment visibility. Object selection can use segment highlighting as feedback to the user. It's giving organized 💜
Dynamics
A considerable part of the graphical information exchanged through an IGCF will be in the form of pointer movements over a background picture, so this one is a big deal 😭 Pointer tracking is used to transmit points sampled from a graphical pointer trace, so the movement of the pointer at the sender site can be reproduced at the receivers. This can be done either by just moving the cursor or by tracing its movement with a line. Rubber band echoes are used to signal areas, routes, and scopes in a highly dynamic way. These are indicated by an echo reference point and a feedback point. ✨
Hierarchical object definitions
The requirement for preserving application semantics meant an IGCF needs a way to represent objects that stand for application entities, and to manipulate those entities as graphical units 🦋 Plus, the low-traffic-volume requirement called for reusing already existing objects to create new ones. Iconic efficiency 👑
One way to meet these requirements is to include object hierarchies in an IGCF. 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 at 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. That definition can be made by instantiating lower-level objects with specific transformation parameters. So an IGCF must incorporate brackets to mark the beginning and end of object definitions, object instantiations, and object redefinitions. Structured, no cap 📦
To go with the object definition mechanism, an IGCF must permit the use of a flexible alphabet for creating object identifiers, which ensures an identifier is unique within a hierarchy. Building the object identifiers isn't part of an IGCF; an IGCF only has to represent them. An identifier also has to be independent of a communication session and of a particular graphics system, so identifiers created at a host during one session can be used in other sessions, possibly involving other hosts, to recall the objects they label. Main character identifiers 🌈
We also leave it to the communicating systems to implement mechanisms for resolving duplicate identifiers when merging two hierarchies created in different sessions. In this paper we'll only give a warning: segment numbers do not qualify as identifiers, because they depend on the session and on the state of the system where they were created. Don't be that person 🙈
In addition to object definition and instantiation, an IGCF should have elements representing operations on objects. The operations identified so far are: transformation, deletion, display, disappearance, expose, and hide. Expose is used to uncover objects on a screen that are hidden by other objects, and 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 basing an IGCF on a standard session-capture graphics metafile, which ensures compatibility with a large user population 🤝 We based the proposed IGCF, PIGCF, on the GKSM session-capture metafile specification, because GKSM contains many of the elements identified for an IGCF [14]. On top of that, the audit trail orientation of GKSM lets you record interactive communication sessions for later play out, and we expect that to be a feature people use a lot 🎬
The GKSM is a proper subset of our PIGCF, so any graphical system built to handle the PIGCF can read a GKSM metafile. Going the other way, applications using the PIGCF should have an option to constrain session recording to just the GKSM part, possibly suppressing some session events. Doing this means we can ship a GKSM metafile to any correspondent who has GKSM interpretation software. Or, an application with a GKSM interpreter but without a PIGCF interpreter can read a PIGCF file by interpreting only the GKSM part and ignoring the rest. Compatibility is everything 💖
Even though the GKSM was specified for the GKS system, we believe it's a sound and general basis for all of our 2-D applications. We don't think the GKSM specification is parochial to GKS systems. It contains all the most useful items you'd want in a metafile 🍓 In the future we expect to tackle applications that need 3-D, like interactive repair and maintenance aids. When GKS is augmented with 3-D capabilities [13], we will extend the PIGCF with any necessary elements. Future-proof era 🚀
We know the GKSM specification isn't part of the GKS standard itself. It's an appendix recommending such a metafile format. Still, all the GKS vendor implementations we know of, at this time, support GKSM metafile output and interpretation. If this trend continues, as we expect, we'll be able to exchange graphical files with a large base of GKS installations. There will be a lot 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. So the originator of a conference must indicate the workstation window for the conference. This window is the sub-rectangle of the NDC space that encloses 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. This way, each workstation can display its workstation viewport in the most convenient portion of the screen 🪟✨
There will be conferences where the participating workstations maintain positional information in world coordinates, WC. It might be necessary to reconstruct the world dimensions after transmission, because those 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 start, the conference originator has to specify the world window and the NDC viewport used in the conference, so the conferencing workstations can do those mappings. The presentation layer could handle these mappings, in terms of the ISO Open Systems Interconnection Reference Model, in a way that's transparent to the communicating application programs 🧠
Most of the time, 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. Such a workstation will have to record the conference ones, though, so it can do the mappings we just talked about. Some graphical systems, like the ACM Core, don't provide for a workstation transformation. In those systems, the NDC viewport is considered to be the workstation window for those 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've 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 for the following: 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 made up of the elements we believe complement the GKSM for general on-line graphical exchanges. This layering follows the graphics metafile level-structure described in Enderle et. al [15]. Under this structure, an application oriented metafile can be based on graphical metafiles. Layers on layers 🧁
D. PIGCF Elements in the Level U
The level U items are encoded as GKSM user item elements, so a PIGCF file still counts as a GKSM metafile from start to finish 🎀 We use the same formatting conventions as the GKSM spec, so if those feel unfamiliar, read the beginning of the appendix first, bestie 📖 The items in the second update group are the two for object definition, the two for object redefinition, the two for object instantiation, the two for normalization transformation, SELECT COMPONENT, and RECALL LIBRARY. Everything else is in the first update group 💖
Items for Object Definition ✨
BEGIN DEFINITION 🌸
| 'GKSM 120' | L |Marks the start of an object definition sequence.
END DEFINITION 🦋
| 'GKSM 121' | L | I |Marks the end of an object definition sequence.
I(Nc): object identifier
( N preceding c, i, r means an arbitrary number
of characters, integers, or reals.)Objects defined interactively get shown on the screen, so they're automatically instantiated, no cap 👀 If you only want to keep the definition and not the image, a DISAPPEAR item has to follow it 🙈
BEGIN REDEFINITION 🧚
| 'GKSM 122' | L | I |Marks the start of an object redefinition sequence.
I(Nc): object identifierEND REDEFINITION 💜
| 'GKSM 123' | L |Marks the end of an object redefinition sequence.
Items for Object Instantiation 🫶
BEGIN INSTANTIATION ⭐
| 'GKSM 124' | L | I |Marks the start of an object instantiation sequence.
I(Nc): Object identifierEND INSTANTIATION 🍓
| 'GKSM 125' | L |Marks the end of an object instantiation sequence.
Items for Object Manipulation 💅
TRANSFORM OBJECT 🔥
| 'GKSM 126' | L | C | I | M |Applies transformation M to object I. The whole vibe is giving matrix math 🧮
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 23DELETE OBJECT 🗑️
| 'GKSM 127' | L | I |I(Nc): object identifierDISPLAY OBJECT 👑
| 'GKSM 128' | L | I |Turns on visibility of object I, so it shows up ✨
I(Nc): object identifierDISAPPEAR OBJECT 🌈
| 'GKSM 129' | L | I |Turns off visibility of object I, so it goes poof 💀
I(Nc): object identifierEXPOSE OBJECT 🎀
| 'GKSM 130' | L | I |Redisplays object I on top of any objects it overlaps 🦋
I(c): object identifierHIDE OBJECT 🙈
| 'GKSM 131' | L | I |Redisplays object I behind any objects it overlaps. Main character energy for the background, ngl 🌸
I(c): object identifierSELECT COMPONENT 💖
| 'GKSM 132' | L | I | P |Selects component P of object I.
I(c): object identifier
P(i): pick id of componentThis is used to select a group of output primitives identified by P in a segment associated with I. It's a whole group energy moment 🫶
ERASE COMPONENT 🧹
| 'GKSM 133' | L | I | P |Erases component P of object I.
I(c): object identifier
P(i): pick id of componentThis erases a group of output primitives identified by P in a segment associated with I. This element can be used only within a REDEFINE OBJECT sequence. Not me trying to erase outside a REDEFINE OBJECT sequence 💀
Items for Normalization Transformation 🔮
SET WINDOW 🪟
| 'GKSM 134' | L | W |Defines the boundaries of the world window for the normalization transformation.
W(4r): limits of world window (XMIN, XMAX, YMIN, YMAX )SET VIEWPORT 🖼️
| 'GKSM 135' | L | V |Defines the boundaries of the NDC viewport for the normalization transformation.
V(4r): limits of NDC viewport (XMIN, XMAX, YMIN, YMAX )Items for Other Operations 🌟
ABORT 🛑
| 'GKSM 136' | L |Aborts the ongoing operation sent in the PIGCF stream. This gives you a way out of unwanted or erroneous operations 🙅♀️ Only the innermost operation of a nested sequence gets aborted. If you need to escape several levels of nesting, send successive aborts, iykyk 😭
POINTER TRACKING 🖱️
| 'GKSM 137' | L | T | P |Updates the graphical pointer position to P.
T(i): 0 causes only cursor to be moved
1 causes cursor movement to be traced with
a line
P(p): a point sampled from graphical pointer
movement traceRUBBER BAND 🎈
| 'GKSM 138' | L | T | P |Echoes a rubber band of type T with given reference and feedback points. The first occurrence of this item in a sequence carries the coordinates of the echo reference point. Later occurrences carry updates to a pointer position that indicates an echo feedback point, so it's literally a whole storyline ✨
T(i): echo type
( 0 echo reference point;
> 0 echo feedback:
1 = line,
2 = rectangle,
3 = circle )
P(r): echo reference point (T = 0),
or echo feedback point (T > 0)The reference and feedback points work like this:
T = 1 - reference is one end of line, feedback is
other end.
T = 2 - reference is one corner of rectangle, feedback
is opposite corner.
T = 3 - reference is center of circle, feedback is
perimeter point.RECALL LIBRARY 📚
| 'GKSM 139' | L | F |Recalls the graphical library in file F.
F(i): name of file containing libraryThe graphical pictures in F, along with all their components, become available for use during the communication session. The pictures are assumed to be recorded with the PIGCF, and their components have to be displayed with DISPLAY OBJECT elements or similar actions so that the pictures become visible 🌷
V. AN ARCHITECTURE FOR PIGCF PROCESSING ✨
okay so this section is a little architecture daydream 🧚 It shows one example of how PIGCF gets made and read inside a multimedia conferencing system, using GKS as the graphics interface. Please don't treat this as the official, only-way-to-do-it blueprint 🙈 It's just an exercise to show how the format fits into the bigger conferencing picture. Picking GKS keeps the example simple 💅 but other graphics packages work too, you'd just add modules that can read and write the PIGCF level L items.
Figure 1 is the programmer's-eye view of the graphics pipeline 🎀 The conferencing app updates its data structures and calls device-independent graphics services through a language binding. Those services call device-dependent graphics services, which talk to device drivers to take input and put pictures on the screen. The app also handles a bunch of other stuff, like conference management and the other media streams, but we don't need to dig into that for this example 🫶
Figure 2 is the glow-up 🦋 The basic pipeline now has the modules for making, sending, receiving, and reading PIGCF streams. The app has one module that reads the lower and higher levels of PIGCF, and another that generates the upper level U. The device-independent graphics services hold the modules that generate and read the lower level, L. This mirrors what people already do, which is putting the generate and interpret functions inside the graphics package. There's also a transmit module that sends outgoing PIGCF streams to remote workstations, and a receive module that takes incoming streams from remote stations. In real life the transmit and receive modules get split into several processes that make up a layered protocol architecture 🌈 One process grabs both levels of PIGCF and writes them into a conference record metafile so you can look back later 📼 A router process takes PIGCF traffic and forwards it to and from the modules we just talked about. The router will probably get swapped out for separate communication interfaces between each pair of modules that trade PIGCF 💜
Thick arrows = outgoing PIGCF, thin arrows = incoming PIGCF. Let's follow the outgoing path, starting at the app ✨ The app handles local user actions and turns them into data structure updates, level U PIGCF elements, and calls to device-independent graphics subroutines. Those calls, among other things, generate level L PIGCF (GKSM) elements 💖
The router merges both level streams in the order they were generated 🍓 It sends the result to the local copy of the conference record and to the transmission module. The transmission module batches Group-2 PIGCF items until a Group-1 item shows up 🧁 It also timestamps the PIGCF stream so the receiver can line up its playback with the playback of other media 🕰️ PIGCF can be split into traffic categories and sent over different communication facilities, depending on what each category needs. For example, real-time service for pointer updates, highly reliable transmission for new object definitions, or low-priority service for graphical library transfers 🚀 Last but not least, the transmit module has to acknowledge incoming PIGCF, and any other media traffic too 🫶
The receive module is the entry point for incoming PIGCF streams. Those streams can come in different traffic categories that need merging 🔀 It checks the timestamps so PIGCF items can sync up with related data in other media, like voice 🎙️ It's also possible to add a high-level error-correction function here, one that validates the streams using state and context info about PIGCF syntax and semantics 🧠 The receive module passes streams to the router, and the router forwards them to three processes. One sends level L items to the GKSM interpreter, which makes the matching changes to the displayed picture 🖼️ Another sends level L and level U items to the conference record, plus to the PIGCF interpretation code in the app. The level U items update both the data structures that model object hierarchies and the picture of those hierarchies, by running graphics services. U items also update graphics cursors and may recall new graphics libraries 📚 The app has to process level L items too, because they can signal updates to the data structures. That happens if, say, the structures store attribute values for the object hierarchies 💅 The app lines these actions up with other media effects using the timestamps. Conference record playback happens offline 📼 Record items come in through the router and then get processed just like incoming PIGCF 🦋
+------------+ +-------------+
|APPLICATION | | OTHER |
| DATA | | MEDIA |
|STRUCTURES | |-------------|
+-----|------+ | CONFERENCE |
|----------> | APPLICATION |
| GRAPHICS |
|----------> | |
+-----|------+ | |
| LANGUAGE | +-------------+
| BINDING |
+-----|------+ +-------------+
|----------> | DEVICE- |
+------------+ | INDEPENDENT |
| DEVICE | | GRAPHICS |
| DEPENDENT | <---> | SERVICES |
| GRAPHICS | | |
| SERVICES | | |
+-----|------+ | |
| | |
v | |
+------------+ | |
| DEVICE | | |
| DRIVERS | | |
+------------+ +-------------+
FIGURE 1 - THE BASIC GRAPHICS PIPELINE
IN A CONFERENCING SYSTEM+------------+ +------------+ +------------------+
|APPLICATION | | OTHER | | TRANSMIT |
| DATA | | MEDIA | | ACK |=>
| STRUCTURES | |------------| +-----+ | SEPARATE TRAFFIC |=>
+-----|------+ | CONFERENCE | | |===> | BATCHING |=>
|---------->|APPLICATION | | | | TIMESTAMPING |
| GRAPHICS | | | +------------------+
|---------->|------------| | |
| | PIGCF L, U | <---| | +------------------+
+-----|------| | INTERPRETER| | | | RECEIVE |
| LANGUAGE | +------------+ | R | | MERGE TRAFFIC |<-
| BINDING | | PIGCF U |===> | O | <---| CHECK TIMESTAMPS |<-
+-----|------+ | GENERATOR | | U | | ERROR CORRECTION |<-
| +------------+ | T | | |
------------------| | E | +------------------+
+------------+ +-----V------+ | R |
| DEVICE | | DEVICE | | | +------------------+
| DEPENDENT | |INDEPENDENT | | |====>| |
| GRAPHICS |<-->| GRAPHICS | | |---->| CONFERENCE |
| SERVICES | | SERVICES | | | | RECORD |
| | | | | | | |
+-----|------+ |------------| | | +------------------+
| | GKSM | | |
v | INTERPRETER|<--- | | <--- INCOMING PIGCF
+------------+ +------------+ | |
| DEVICE | | GKSM | | | ===> OUTGOING PIGCF
| DRIVERS | | GENERATOR |===> | |
+------------+ +------------+ +-----+
FIGURE 2 - A CONFERENCING SOFTWARE ARCHITECTURE FOR PROCESSING PIGCFVI. CONCLUSIONS 🎀
okay bestie, the big takeaway: teleconferencing and other multi-media apps are going to be part of the communication toolkit organizations have in the near future 📞 That's going to push graphics and computer communication folks to tackle application-to-application graphics communication 🌐 The heart of that is a protocol, and the heart of the protocol is a data format 💜 We laid out the operational requirements for that kind of protocol and proposed a format that meets them ✨
Right now, none of the existing or emerging graphics standards can serve as the protocol, or as the format for it 😭 But that could change as the standards evolve 🌸 We're keeping an eye on standards development and we'll look into using some of them as a format basis, especially the CGI 👀 Still, the computer communication community really needs experience with multi-media conferencing implementations 🔥 For these apps to actually happen, a graphics communication protocol can be built on either an official standard or a de-facto standard that's likely to get wide use, which helps assure interoperability with a broad user base 🫶 We think that using the GKSM session metafile is moving us in the right direction 🧚
Designing the software architecture for generating and reading the proposed PIGCF surfaced some problems we'll have to face as we keep working toward a complete graphics protocol 🙈 This work is part of SRI's ongoing multimedia communications program 🦋 Within that program we're building a simple multi-media conferencing prototype and we'll design a more complete one later 💅 Experience from both efforts will be super valuable input for the protocol architecture design 👑
APPENDIX A ✨
Okay bestie, this is an excerpt from a draft proposal called "Draft Proposal: Graphical Kernel System" [14], and it is giving graphics history 🎀
E.2 Metafile Based on ISO DIS7942 💖
Okay so this metafile is basically a log of the exact sequence of function calls made to GKS 📼 It covers the entire range of GKS output functions, from level m all the way up to level 2, which is so complete it's iconic 👑 It's perfect for apps where you want to 'play back' the graphics actions, maybe with some selective editing done by the interpreter 🎬
There are two encodings specified for this metafile. One is inefficient for lots of apps, so ngl, it's a little bit of a vibe check 💀 The second one allows an unspecified binary format. The rest of this IGCF appendix gives the 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 a fixed format, and it describes the origin of the metafile (author and installation), the format of the items that follow, and the number representation 🌸 The file ends with an end item that marks the logical end of the file. In between those two items, the following information is recorded, sort of like 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.
The overall structure of the GKS metafile is laid out like this, and it's giving diagram energy 🔥
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, and that item header contains:
- 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 contained in the item;
- c) the length of the item data record.
The lengths of these fields in the item header are implementation dependent, and they 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 are 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 it's specified in the application program for a workstation writing a metafile of this format, is not performed. Instead, WORKSTATION WINDOW and WORKSTATION VIEWPORT are stored in data items for later usage 📦 Real numbers may also be stored as integers. In that case, the transformation parameters are specified in the file header so that integers can be properly transformed into normalized device coordinates ✨
For reasons of economy, numbers can be stored using an internal binary format. Since 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 is a list, sorted by class, of all GKS functions that apply to workstations of category MO, and it shows their effects on this GKSM. In the table, GKSM-OUT is a workstation identifier for a workstation writing a metafile of this format 🍓
The concepts of clipping rectangle and clipping indicator are wrapped up in one metafile item that 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 with 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 while 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]) 🦋
Here's Table E1, and honestly it's the whole vibe of this appendix 🌈
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
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
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)
________________________________________________________________________
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 > 100E.4. Interpretation of Metafiles ✨
E.4.1. Introduction 🦋
okay so the way GKS explains metafile interpretation is in 4.9 [14] 💅. The effects of INTERPRET ITEM for every kind of metafile item are covered in the sections below, and the items are grouped by what class of functionality they belong to 🫶.
E.4.2. Control Items 🎀
Interpreting items in this class is explained under the definition of each item in E.5. ([14] says "E.2.4" instead of "E.5", which we think is an error 🙈).
E.4.3. Output Primitives 💖
Interpreting these items makes output that matches the primitive functions, with one twist: point coordinates are expressed in NDC 🧚. The primitive attributes bound to a primitive are the ones that came from interpreting primitive attribute items in this same metafile (see E.4.4) ✨.
E.4.4. Output Primative Attributes 🌸
Interpreting these items sets values that get used when displaying primitives that come later from this same metafile (see E.4.3) 💜. No changes are made to entries in the GKS state list, so the state list stays exactly as it was 🍓.
E.4.5. Workstation Attributes 💅
Interpreting these items does the same thing as calling the matching GKS functions in Table E1 🔥. Those GKS functions run on all active workstations 🌈.
E.4.6. Transformations 🦋
Interpreting a clipping rectangle item sets the values used for clipping output primitives that come later from this metafile 💖. No changes are made to entries in the GKS state list 🫶. Interpreting the other items in this class (WORKSTATION WINDOW and WORKSTATION VIEWPORT) invokes the matching GKS functions on all active workstations ⭐.
E.4.7. Segment Manipulation 👑
Interpreting these items does the same thing as calling the matching GKS functions in Table E1. (Item 84 causes an invocation of DELETE SEGMENT 💀.)
E.4.8. Segment Attributes ✨
Interpreting these items does the same thing as calling the matching GKS functions in Table E1 🎀.
E.5. Control Items 💖
FILE HEADER 📜
| GKSM | N | D | V | H | T | L | I | R | F | RI | ZERO | ONE |Okay bestie, every field in the file header item has a fixed length 🔒. Numbers get formatted 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
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 = 2After the file header, which is fixed format, every value in the items that follow is in the format the file header defines ✨. For the descriptions below, we assume this setting:
H = 4; T = 3; F = 1Besides formats (c), (i) and (r), which were already described, (p) stands for a point made of a pair of real numbers (2r) 🌟. You can put an expression in front of the single letter to say how many values of that type there are 🔢.
{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 |This is the last item of every GKS Metafile. It sets the condition for the error 🚨.
CLEAR WORKSTATION 🧹
| 'GKSM 1' | L | C |This asks for CLEAR WORKSTATION on all active workstations 🫧.
C(i): clearing control flag
(0 = CONDITIONAL, 1 = ALWAYS)REDRAW ALL SEGMENTS ON WORKSTATION 🔁
| 'GKSM 3' | L | R |This asks for UPDATE WORKSTATION on all active workstations 💫.
R(i): regeneration flag
(0 = PERFORM, 1 = SUSPEND)DEFERRAL STATE ⏳
| 'GKSM 4' | L | D | R |This asks for 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 |This asks for 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.}
ESCAPE 🚀
| 'GKSM 6' | L | FI | L | M | I | R |This asks for 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.}
⚠️ Heads up: the escape function has to leave the GKS state list alone and must not produce geometrical output. That rule matters a lot 🫠.
E.6. Items for Output Primitives 🎨
POLYLINE 📈
| 'GKSM 11' | L | N | P |N(i): number of points of the polyline
P(Np): list of pointsPOLYMARKER 📍
| '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 646FILL AREA 🎨
| 'GKSM 14' | L | N | P |N(i): number of points
P(Np): list of points.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): linetypeLINEWIDTH 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 indexPOLYMARKER INDEX 🔷
| 'GKSM 25' | L | I |I(i): polymarker indexMARKER TYPE ⭐
| 'GKSM 26' | L | MT |MT(i): marker typeMARKER 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 indexTEXT INDEX 📝
| 'GKSM 29' | L | I |I(i): text indexTEXT 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 spacingTEXT COLOUR INDEX 🎀
| 'GKSM 33' | L | CI |CI(i): text colour indexCHARACTER VECTORS 🧭
| 'GKSM 34' | L | CH | CW |CH(2r): character height vector
CW(2r): character width vectorNote: 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 |Okay so we're mid-item for TEXT ALIGNMENT, and the alignment settings are giving main character energy 💅🎀
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 indexFILL AREA INTERIOR STYLE 🦋
| 'GKSM 38' | L | S |
S(i): fill area interior style
(0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH)FILL AREA STYLE INDEX 💖
| 'GKSM 39' | L | SI |
SI(i): fill area style indexFILL AREA COLOUR INDEX 🌈
| 'GKSM 40' | L | CI |
CI(i): fill area colour indexPATTERN SIZE 🧚
| 'GKSM 41' | L | PW | PH |
PW(2r): pattern width vector
PH(2r): pattern height vectorOkay so one style for filling areas is a pattern made of color cells 🎨 The pattern is an array of color indices, and that array gets mapped into a pattern rectangle sized by PW and PH. Iconic ✨
PATTERN REFERENCE POINT 📍
| 'GKSM 42' | L | P |
P(p): reference pointSame pattern-of-color-cells energy again 🫶 This time the pattern rectangle is anchored by its lower left corner, and that corner is given by P.
ASPECT SOURCE FLAGS 🚩
| 'GKSM 43' | L | F |
F(13i): aspect source flags
(0 = BUNDLED, 1 = INDIVIDUAL)Ngl this one is so deep 🙈 An application can set an output primitive attribute to either bundled or individual. Bundled attributes depend on the workstation, their binding is delayed, and their values can change dynamically. Individual attributes are global, they get bound immediately, and their value is static and can't be manipulated. Not me being like "okay this is a whole personality" 💀
PICK IDENTIFIER 🎀
| 'GKSM 44' | L | P |
P(i): pick identifierE.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 indexPOLYMARKER 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 indexTEXT 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 indexFILL 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 indexPATTERN 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".}Okay so this is the pattern one again, and that "one style for filling areas" line keeps popping up 😭 A pattern is defined by a pattern representation, full stop. The table of colour indices gets stored row by row, and the footnote says the ANSI document actually says "area" where this says "array" 🙈
COLOUR REPRESENTATION 🩷
| 'GKSM 56' | L | CI | RGB |
CI(i): colour index
RGB(3r): red, green, blue intensitiesE.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 has a workstation transformation that takes a rectangle of the NDC space (that's the workstation window) and maps it onto a rectangle of the device coordinate space (that's the workstation viewport) 🗺️ Literally so satisfying.
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 nameCLOSE SEGMENT 🚪
| 'GKSM 82' | L |
indicates end of segmentRENAME SEGMENT ✏️
| 'GKSM 83' | L | SO | SN |
SO(i): old segment name
SN(i): new segment nameDELETE SEGMENT 🗑️
| 'GKSM 84' | L | S |
S(i): segment nameE.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 23Lowkey the matrix is the star of this one 🤩 Here's the tea: this differs from the ANSI X3.124 Jan. 5 1984 document, in the matrix elements indicated. The authors believe there is an error in that document, so be careful 🙃
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 prioritySET 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)Okay so the PIGCF level U items get encoded as GKSM USER ITEM elements, which means a PIGCF file still conforms to the GKSM metafile spec. Bestie, that's a whole glow-up 🌈✨
Segment Functions 🧚
Segment Attributes 🎀
Metafile Functions 🌸
All fields in the file header item have fixed length. Numbers are formated according to ISO 6093 - Format F1. 🔢
General Information: 📚
Specification of Number Representation: 🔢
Appendix B. Example of PIGCF Use in Conferencing 🎀
okay so this section shows off the PIGCF graphical component in an audio-graphics conference 🦋 we only show the graphics side of the convo (speech would go alongside it), and we skip most of the parameter negotiation a real conference set-up needs, just for brevity 💅
picture an on-line audio-graphics conference between a Navy command and control center and a Navy task force 🫶 the PIGCF items below don't all belong to one transmission stream. the stream is decided by whichever station transmits them, and identifying that station is the job of the lower-level communication protocols 🧚 we use the character encoding instead of the binary one for this example, and we only show a few of the groups of items that could get batched together ✨
the command center (center) sets up a conference with some ships in a task force (platforms) to coordinate intercepting an unidentified ship that got sighted in a conflict area 😭 after recalling graphical libraries, every site can see a map of the sighting area on their screens, plus iconic representations of the task force ships 🗺️ then the center draws an iconic representation of the unidentified vessel, scales it, and places it at the sighting location, all interactively 🔥
the platforms explain possible courses of action with graphical pointers 👑 the center draws the expected trajectory of the unidentified ship, and the platforms place the task force icons at the expected interception points. then the center zooms into the interception area, and the platforms use rubber bands to talk through interception maneuvers 💀
now for the PIGCF items exchanged 🌈 the center kicks off the conference graphical set-up with the FILE HEADER item, which sets the basic representation parameters for the graphical info being exchanged. this item gets 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 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 stick to the PIGCF specification field lengths and the settings above 💖 but we add one space before and after each "|" separator to make it more legible, and every item gets preceded by its name so it's easy to identify 🍓
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, the conferencing work stations use world coordinates for the internal representation of positional information 🌸 so 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 shares the location of its local NDC viewport. other conferees can pick 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 window 📝
SET VIEWPORT: | 135 | 28 | 0.0 0.5 0.0 0.375 |
the center recalls graphical libraries with geographical maps of the crisis area and icons of the task forces in the area. it also displays a graphical object that gives a background picture 🦋
RECALL LIBRARY: | 139 | 9 | caribbean | DISPLAY OBJECT: | 128 | 11 | coast_lines | RECALL LIBRARY: | 139 | 10 | task_units |
the center goes on to instantiate one of the task forces in the task_units library. this means recalling some of the library objects and applying transformations to them afterward 💅 since set window, set viewport, and recall library belong to the update 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 has more item sequences that could be batched, but for brevity we don't point out 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 up, the center sets values for two output primitive attributes to get ready for drawing a new icon on the screens 🎀 we assume all the other attributes got default values during the conference set-up.
POLYLINE INDEX: | 21 | 4 | 20 | POLYLINE COLOUR INDEX: | 24 | 4 | 200 |
the following items cover the interactive definition of the unidentified vessel. since it's defined interactively, the vessel image stays visible on the screens after the definition is done 👀
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" gets scaled and placed at the sighting site 🧚
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 the unidentified ship would follow 🌈 this time the pointer trace gets 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 into interception positions 🚢
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 to get a bigger view for further discussion 🔍
WORKSTATION WINDOW: | 71 | 24 | 0.286 0.403 0.077 0.177 |
the two platforms show their striking ranges using circular rubber bands centered at each ship 💫 for each platform, we first show 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 is agreed on, the center zooms back 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 stay visible on the screens. the PIGCF items also get recorded in their entirety, so the conference session can be played back if needed 🎬
the conference record could also be sent to other locations as part of a multi-media message 💜
References ✨
okay bestie, here's the reading list 📚 every single source, with all its details, so you can go deep on whatever you want 🤓
- [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. 👑
- [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. 💖
📦 where this page comes from
- ietf: rfc965 1985-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms