RFC965 日本語訳
0965 Format for a graphical communication protocol. L. Aguilar. December 1985. (Format: TXT=105456 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Lorenzo Aguilar
Request for Comments: 965 SRI International
December 1985
コメントを求めるワーキンググループロレンツォアギラルRequestをネットワークでつないでください: 965 SRIインターナショナル1985年12月
A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための形式
STATUS OF THIS MEMO
このメモの状態
This paper describes the requirements for a graphical format on which to base a graphical on-line communication protocol. The proposal is an Interactive Graphical Communication Format using the GKSM session metafile. Distribution of this memo is unlimited.
この論文はグラフィカルなオンライン通信プロトコルを基礎づけるグラフィカルな形式のための要件について説明します。 提案はGKSMセッションメタファイルを使用するInteractive Graphical Communication Formatです。 このメモの分配は無制限です。
ABSTRACT
要約
This paper describes the requirements for a graphical format on which to base a graphical on-line communication protocol. It is argued that on-line graphical communication is similar to graphical session capture, and thus we propose an Interactive Graphical Communication Format using the GKSM session metafile.
この論文はグラフィカルなオンライン通信プロトコルを基礎づけるグラフィカルな形式のための要件について説明します。 オンライングラフィカルなコミュニケーションがグラフィカルなセッション捕獲と同様であると主張されて、その結果、私たちは、GKSMセッションメタファイルを使用することでInteractive Graphical Communication Formatを提案します。
We discuss the items that we believe complement the GKSM metafile as a format for on-line interactive exchanges. One key application area of such a format is multi-media on-line conferencing; therefore, we present a conferencing software architecture for processing the proposed format. We make this format specification available to those planning multi-media conferencing systems as a contribution toward the development of a graphical communication protocol that will permit the interoperation of these systems.
私たちはオンライン対話的な交換のための形式としてGKSMメタファイルの補足となると信じている項目について議論します。 そのような形式の1つの主要なアプリケーション部がマルチメディアのオンライン会議です。 したがって、私たちは処理のための会議ソフトウェア・アーキテクチャに提案された形式を提示します。 私たちはこの書式仕様をこれらのシステムのinteroperationを可能にするグラフィカルな通信プロトコルの開発に向かった貢献としてそれらの計画マルチメディア会議システムに利用可能にします。
We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions. At SRI, we stay open to the exploration of alternatives and we will continue our research and development work in this problem area.
この貢献がマルチメディアデータ交換の議論とソリューションの提案を奨励することを願っています。 SRIでは、私たちは代替手段の探検に開かれていた状態で滞在します、そして、この問題領域で私たちの研究開発仕事を続けるつもりです。
ACKNOWLEDGEMENTS
承認
The author wants to thank Andy Poggio of SRI who made many insightful and valuable suggestions that trimmed and improved level U. His expertise in multi-media communication systems and his encouragement were a most positive input to the creation of this IGCF. Dave Worthington of SRI also participated in the project discussions involving this IGCF. Thanks are also due to Tom Powers, chairman of ANSI X3H33, who opened this forum to the presentation of an earlier version of this paper, thereby providing an opportunity for the invaluable feedback of the X3H33 members. Jon Postel of ISI recommended a number of changes that made this paper more coherent and accessible.
作者は、だれがレベルU.を整えて、改良した多くの洞察に満ちたで貴重な提案をマルチメディア通信系における彼の専門的技術にしたか、そして、彼の奨励がこのIGCFの作成への最も積極的な入力であったのをSRIのアンディPoggioに感謝したがっています。 また、SRIのデーヴ・ワーシントンはこのIGCFにかかわるプロジェクト議論に参加しました。 感謝はトム・パワーズ、ANSI X3H33の議長のもためです、その結果、X3H33メンバーの非常に貴重なフィードバックに機会を与えます。その議長は、この紙の以前のバージョンのプレゼンテーションにこのフォーラムを開きました。 ISIのジョン・ポステルは、より一貫性を持っていてこの紙がアクセスしやすかった多くの変化を、推薦しました。
Aguilar [Page 1]
アギラル[1ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
Most of the work reported in this paper was sponsored by the U.S. Navy, Naval Electronic Systems Command, Washington D.C., under Contract No. N00039-83-K-0623.
この紙で報告された仕事の大部分は合衆国海軍、Naval Electronic Systems Command、ワシントンDCによって後援されました、Contract No.の下で N00039 83K0623。
I. INTRODUCTION
I. 序論
A. Use of a Graphical Communication Protocol
グラフィカルな通信プロトコルのA.使用
In the field of computer communications, a protocol is a procedure
executed by two cooperating processes in order to attain a
meaningful exchange of information. A graphical communication
protocol is needed to exchange interactive vector graphics
information, possibly in conjunction with other information media
like voice, text, and video. Within this multi-media communication
environment, computer vector graphics plays a key role because it
takes full advantage of the processing capabilities of
communicating computers and human users, and thus it is far more
compact than digital images which are not generated from data
structures containing positional information. Vector graphical
communication trades intensive use of storage and processing, at
the communicating ends, in return for a low volume of exchanged
data, because workstations with graphical hardware exchange
graphics commands in conjunction with large data structures at the
transmitter and receivers. In this manner, the transmission of a
single command can produce extensive changes in the data displayed
at the sending and receiving ends.
コンピュータコミュニケーションの分野では、プロトコルが重要な情報交換に達するように2つの協調処理で実行された手順です。 グラフィカルな通信プロトコルが、ことによると声、テキスト、およびビデオのような他の情報媒体に関連して対話的なベクタグラフィックス情報を交換するのに必要です。 コンピュータと人間のユーザを交信させて、その結果、それを交信させる処理能力を最大限に利用するので、このマルチメディア通信環境、コンピュータベクタグラフィックス劇の中に重要な役割は位置の情報を含むデータ構造から生成されないディジタル画像よりはるかにコンパクトです。 ベクトルのグラフィカルなコミュニケーションはストレージと処理の徹底的な使用を交えます、交信終わりに、交換されたデータの低ボリュームのお返しに、グラフィカルなハードウェアがあるワークステーションが送信機と受信機の大きいデータ構造に関連してグラフィックスコマンドを交換するので。 この様に、ただ一つのコマンドの送信は発信と犠牲者に表示されたデータにおける幅広い変更を発生させることができます。
It is helpful to situate the aforesaid protocol at one of the
functional levels of the ISO Open Systems Interconnection
Reference Model [1]. Within such a model, a graphical protocol
functionality belongs primarily in the application level, though
some of it fits in the presentation level. We can distinguish the
following components of a communication protocol:
ISOオープン・システム・インターコネクションReference Model[1]の機能的なレベルの1つで前述のプロトコルを位置させるのは役立っています。 そのようなモデルの中に、主としてアプリケーションレベルにはグラフィカルなプロトコルの機能性があります、それのいくつかがプレゼンテーションレベルをうまくはめ込みますが。 私たちは通信プロトコルの以下の成分を区別できます:
a) a data format
b) rules to interpret transmitted data
c) state information tables
d) message exchange rules
a) データの形式b) 解釈する規則はデータc)州の情報テーブルd) 交換処理規則を伝えました。
A format for a graphical protocol should provide the layout of the
transmitted data, and indicate how the formated data are
associated with interpretation rules. The choice of format
influences the state tables to be maintained for the correct
processing of the transmitted data stream. The graphical format
has a minor influence on the exchange rules, which should provide
for the efficient use of transmission capacity to transport the
data under such a format. Besides the graphical format, there are
グラフィカルなプロトコルのための形式は、伝えられたデータのレイアウトを提供して、formatedデータがどう解釈規則に関連しているかを示すべきです。 形式の選択は、ステートテーブルが伝えられたデータ・ストリームの正しい処理のために維持されるのに影響を及ぼします。 グラフィカルな形式は小さい方の影響を交換規則に与えます。(交換規則はそのような形式の下でデータを輸送する送信能力の効率的な使用に備えるべきです)。 グラフィカルな形式以外に、あります。
Aguilar [Page 2]
アギラル[2ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
other aspects of a graphical protocol that determine state tables
and exchange rules. This paper concentrates in the data format,
and it does not discuss the message exchange. Nevertheless, we
discuss a simple software architecture for generating and
interpreting data streams written in our proposed format. Further,
we give an example of an application of a proposed format (in
Appendix B), and it illustrates the type of message exchanges that
are needed for establishing a communication session and exchanging
graphical information.
ステートテーブルと交換規則を決定するグラフィカルなプロトコルの他の局面。 この紙はデータの形式で集中します、そして、それは交換処理について議論しません。 それにもかかわらず、私たちは、私たちの提案された形式で書かれたデータ・ストリームを生成して、解釈するために簡単なソフトウェア・アーキテクチャについて議論します。 さらに、私たちは提案された形式(Appendix Bの)の適用に関する例を出します、そして、それはコミュニケーションセッションを確立して、グラフィカルな情報を交換するのに必要である交換処理のタイプを例証します。
Those in the computer communication field are well aware of the
importance of widely accepted protocols in order to achieve
meaningful communication. Those who need to implement interactive
graphical communications today are confronted with the lack of an
standard for computer graphics communication among application
programs. Nevertheless, we can use some of the work already done
by the computer graphics standard bodies. As a matter of fact, ISO
and ANSI have already appended, to the Graphical Kernel System
(GKS) standard, the GKSM session metafile specification that has
many of the features needed for an on-line graphical protocol.
コンピュータコミュニケーション分野のそれらは、重要なコミュニケーションを達成するために広く受け入れられたプロトコルの重要性をよく意識しています。 今日インタラクティブがグラフィカルなコミュニケーションであると実装する必要がある人がアプリケーション・プログラムの中のコンピュータグラフィックスコミュニケーションの規格の不足に直面しています。それにもかかわらず、私たちはコンピュータ・グラフィックス・スタンダード本体によって既に行われたいくらかの仕事を使用できます。 実は、ISOとANSIは既にオンライングラフィカルなプロトコルに必要である特徴の多くを持っているGKSMセッションメタファイル仕様をGraphical Kernel System(GKS)規格に追加しました。
It is pertinent to mention an example of graphical communication
that illustrates the real-time nature of the interaction and also
illustrates the use of graphics in conjunction with other
information media. With audio-graphics conferencing, a group of
individuals at two or more locations can carry on an electronic
meeting. They can converse over voice channels and concurrently
share a graphics space on which they can display, point at, and
manipulate vector graphics pictures [2, 3, 4, 5, 6, 7].
相互作用の瞬時性を例証して、また他の情報媒体に関連してグラフィックスの使用を例証するグラフィカルなコミュニケーションに関する例について言及するのは適切です。 オーディオのグラフィックス会議で、2つ以上の位置の個体群はテレビ会議まで運ばれることができます。 彼らは、音声チャンネルの上に話して、同時にそれらがベクタグラフィックス画像を表示して、指し示して、操ることができるグラフィックススペース[2、3、4、5、6、7]を共有できます。
The conference voice channels can be provided by a variety of
transmission technologies. The shared graphics space can be
implemented on workstations that display the pictures and permit
graphical interaction and communication with other locations. The
communication of operations upon pictures involves modifications
to the underlying data structures, but we are concerned with
graphical database updating only to the extent that such updating
supports the communication.
さまざまなトランスミッション技術で会議音声チャンネルを提供できます。 他の位置で画像を表示して、グラフィカルな相互作用とコミュニケーションを可能にするワークステーションの上で共有されたグラフィックススペースを実装することができます。 画像での操作に関するコミュニケーションは基本的なデータ構造への変更にかかわりますが、そのようなアップデートがコミュニケーションをサポートすることを範囲だけへのグラフィカルなデータベースアップデートに私たちを心配させます。
In order to play out a recorded graphical session, we will need
indications of the rate at which the graphical elements must be
shown and the graphical operations recreated. We do not include
the means for indicating the timing of a session in a format
because our main purpose is to use it in mixed-media communication
environments. In these environments, the play-out timing must be
compatible across information media in order to coordinate them.
Therefore, we leave the timing mechanisms to conference-control
記録されたグラフィカルなセッションを終えるために、私たちは、グラフィカルな要素を見せなければならないレートのしるしとグラフィカルな操作を休養させる必要があるつもりです。 私たちは私たちの主な目的が混合媒体通信環境にそれを使用することであるので形式のセッションのタイミングを示すための手段を入れません。 これらの環境で、外でプレーするタイミングは、それらを調整するために情報媒体の向こう側に互換性がなければなりません。 したがって、私たちは会議コントロールへのメカニズムにタイミングを残します。
Aguilar [Page 3]
アギラル[3ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
modules. We also leave to conference control processes the manner
in which a conferee station emulates a graphical capability that
it lacks. One example is the representation of color in monochrome
displays.
モジュール。 また、私たちは相談相手ステーションがそれが欠いているグラフィカルな能力を見習う方法を会議コントロールプロセスに残します。 1つの例がモノクロ表示で、色の表現です。
B. Relationship to Other Work
他の仕事とのB.関係
There are a number of actual, and proposed, standards for graphics
information exchange. In the following, we explain the reasons
why, at present, none of them can be used as the basis of an
on-line protocol. As some of these standards evolve, however, some
may become suitable. Moreover, the experience gained with early
on-line graphics communication systems will provide insight into
the proper standard extensions to support more advanced systems.
Such insight could also be used to modify the format proposed in
this paper, which we consider an initial approach to the problem.
In the future, the format proposed in this paper could be replaced
by one of the aforesaid extended standards.
グラフィックス情報交換の多くの実際の、そして、提案された規格があります。 以下では、私たちは現在のところオンラインプロトコルの基礎としてそれらのいずれも使用できない理由について説明します。 しかしながら、これらの規格のいくつかが発展するのに従って、或るものは適当になるかもしれません。 通信系は、より高度なシステムをサポートするために適切な標準の拡大に関する洞察を提供するでしょう。そのうえ、経験が獲得した、-早くから、グラフィックスを裏打ちしてください、また、私たちが問題への初期のアプローチであると考えるこの紙で提案された形式を変更するのにそのような洞察は使用できました。 将来、この紙で提案された形式は前述の拡張規格の1つに取り替えることができました。
The North American Presentation Level Protocol Syntax, NAPLPS,
specifies a data syntax and application semantics for one-way
teletext information dissemination and two-way videotex database
access and transaction services. The two-way videotex operational
model is based on the concept of a consumer and an information
provider or service operator. Because of this asymmetry, it is
assumed that almost all graphical information will flow from the
provider toward the consumer. In the reverse direction, the
consumer is expected to manipulate and transmit alphanumeric
information, for the most part. Although this standard includes
geometric drawing primitives, a user cannot directly modify shapes
drawn with the primitives.
北米プレゼンテーションレベル・プロトコルシンタックス(NAPLPS)は一方向文字放送情報普及、両用ビデオテックスデータベースアクセス、およびトランザクションサービスにデータ構文とアプリケーション意味論を指定します。 両用ビデオテックスオペレーショナル・モデルは消費者の概念と情報提供者かサービスオペレータに基づいています。 この非対称のために、ほとんどすべてのグラフィカルな情報がプロバイダーから消費者に向かって流れると思われます。 反対の方向に、消費者は、英数字の情報をだいたい操って、伝えると予想されます。 この規格は幾何学上描いている基関数を含んでいますが、ユーザは直接基関数で描かれた形を変更できません。
At present, NAPLPS does not include interaction concepts like
picture transformations or detectability, which are fundamental
for attaining a shared graphical workspace. Neither does it allow
key graphics input devices like mice, joysticks, stylus, rotating
balls, or light pens, which are needed for simple and efficient
editing of the shared workspace.
現在のところ、NAPLPSは画像変換や検出度のような相互作用概念を含んでいません。(共有されたグラフィカルなワークスペースに達するのに、概念は基本的です)。 どちらも、それは共有されたワークスペースの簡単で効率的な編集に必要であるネズミ、ジョイスティック、スタイラス、回転するボール、またはライトペンのような主要なグラフィックス入力装置を許容しません。
We want to have user-to-user graphical communication that features
the level of sophistication and ease of interaction provided by
today's interactive graphics packages. Computer vector graphics
can provide both because its paradigm includes an application
program that keeps track of a very large number of possible
changes of state of the displayed picture. In addition, the
application drives a powerful graphics package, like GKS or ACM
Core. In the videotex paradigm, the provider application only
今日のインタラクティブグラフィックスパッケージでユーザからユーザへの洗練のレベルを特徴とするグラフィカルなコミュニケーションと相互作用の容易さを提供して頂きたいと思います。 ともにパラダイムが表示された画像の状態の非常に多くの可能な変化の動向をおさえるアプリケーション・プログラムを含んでいるので、コンピュータベクタグラフィックスは提供されることができます。 さらに、アプリケーションはGKSやACM Coreのような強力なグラフィックスパッケージを運転します。 ビデオテックスパラダイム、プロバイダーアプリケーションだけで
Aguilar [Page 4]
アギラル[4ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
allows limited changes to the displayed image, primarily database
retrieval requests. Also, the paradigm does not include a separate
graphics package. Both the graphics functionality and the data
format are collapsed into a coding specification, like NAPLPS.
表示されたイメージへの限られた変化、主としてデータベース利用要求を許します。 また、パラダイムは別々のグラフィックスパッケージを含んでいません。 グラフィックスの機能性とデータの形式の両方がNAPLPSのようなコード化仕様まで潰されています。
In this paper we are interested primarily in business and
industrial applications where there is a two-way, or multi-way,
flow of vector graphics information among the users. The users
will have workstations with substantial processing and storage
capacities, and high-resolution monitors; moreover, the
communication will be on a distributed architecture not depending
on a central server host, like the provider application host of
videotex.
この紙では、私たちは主としてツーウェイ、またはマルチ道があるビジネスと産業応用に興味を持っています、ユーザの中のベクタグラフィックス情報の流れ。 ユーザはかなりの処理、記憶容量、および高解像度モニタがいるワークステーションを持つでしょう。 そのうえ、セントラルサーバーホストに頼っていなくて、コミュニケーションが分配されたアーキテクチャにあるでしょう、ビデオテックスのプロバイダーアプリケーションホストのように。
Currently, the videotex equipment at the consumer end consists of
inexpensive microprocessor-based decoders or personal computer
boards driving, in most cases, low-resolution standard TV sets and
personal computer displays. There is already affordable technology
to produce sophisticated decoders and high-resolution graphics
devices. The videotex standards need extensive revisions to take
advantage of these advances; in particular, they should consider
the receiving devices as capable of hosting a programmable
customer-application process. When this happens, videotex
protocols will be applicable to our intended problem areas [8].
現在、消費者終わりのビデオテックス設備は安価なマイクロプロセッサベースのデコーダか多くの場合、低い解像度の標準のテレビを動かすパーソナルコンピュータボードとパーソナルコンピュータディスプレイから成ります。 既に、精巧なデコーダと高画質グラフィックスデバイスを生産する手頃な技術があります。 ビデオテックス規格はこれらの進歩を利用するために大規模な改正を必要とします。 特に、彼らは、受信デバイスがプログラマブル顧客アプリケーション・プロセスをホスティングできるとみなすべきです。 これが起こるとき、ビデオテックスプロトコルは私たちの意図している問題領域[8]に適切になるでしょう。
The Computer Graphics Metafile [9] will become an international
and North American standard for graphics picture interchange in
the near future. However, the CGM, also referred as VDM, is a
picture-capture metafile that only records the final result of a
graphics session. It is not intended to record the
picture-creation process, which is fundamental for the interactive
applications that we are addressing. Moreover, the CGM is
presently aimed at a minimum support of GKS functionality. It will
be some time before the CGM will have some of the elements needed
for on-line interaction. If, after these additions, the CGM is
augmented for session capture, it would become a logical candidate
for a protocol format.
コンピュータGraphics Metafile[9]は近い将来、グラフィックス画像置き換えの国際的で北米の規格になるでしょう。 しかしながら、また、VDMとして参照されたCGMはグラフィックスセッションの最終的な結果を記録するだけである画像捕獲メタファイルです。 私たちがアドレシングであることは画像作成プロセスを記録しないつもりです。(対話型アプリケーションに、プロセスは基本的です)。 そのうえ、CGMは現在、GKSの機能性の最小のサポートを目的とされます。 CGMにはオンライン相互作用に必要である要素のいくつかがあるまで、いくらかの時間がかかるでしょう。 CGMがこれらの追加の後にセッション捕獲のために増大するなら、それはプロトコル形式の論理的な候補になるでしょう。
Another future standard is the Computer Graphics Interface, CGI
also referred as VDI [10]. The CGI is a standard functional and
syntactical specification of the control and data exchange between
device-independent graphics software and one or more
device-dependent graphics device drivers. A major use of the CGI
is for the communication between an application host and a
graphics device, but the asymmetry between its intended
communicating ends hinders the use of CGI for our purposes.
別の将来の規格がコンピューター図形処理インターフェイスである、また、CGIはVDI[10]として参照されました。 CGIはデバイスから独立しているグラフィックス・ソフトと1つ以上のデバイス依存するグラフィックスデバイスドライバの間のコントロールとデータ交換の標準の機能的で構文の仕様です。 CGIの主用途はアプリケーションホストとグラフィックスデバイスとのコミュニケーションのためのものですが、意図している交信終わりの間の非対称はCGIの私たちの目的の使用を妨げます。
Aguilar [Page 5]
アギラル[5ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
As previously stated, we want to take advantage of intelligence
and storage at the communicating ends in order to achieve powerful
information-conveying effects using narrow-bandwidth channels.
This requires that the format we seek must have items for
communication between two applications. In contrast, the CGI
streams are processed by device-dependent drivers, rather than by
applications. The CGI specification does include application data
elements, but only to be stored in a metafile. These application
data elements are not interpreted by the drivers, but by
applications that read the metafile, some time after metafile
creation.
前述のように、知性を利用したいと思います、そして、交信におけるストレージは、狭い帯域幅チャンネルを使用することで強力な情報を伝える効果を達成するために終わります。 これは、私たちが求める形式が2つのアプリケーションのコミュニケーションのための項目を持たなければならないのを必要とします。 対照的に、CGIストリームはアプリケーションでというよりむしろデバイス依存するドライバーによって処理されます。 しかし、CGI仕様はアプリケーションデータ要素を含んでいますが、メタファイルでは、保存されます。 ドライバーによって解釈されるのではなく、これらのアプリケーションデータ要素はメタファイルを読むアプリケーション、メタファイル作成の後のいつかの時間までに解釈されます。
Furthermore, the CGI has elements for obtaining graphical input,
as well as elements for inquiring graphics device capabilities,
characteristics, and states. Later, in Section III, we explain why
these two classes of elements are unnecessary for the
communication protocol we need. As the CGI evolves, it will
undergo significant changes, and, in the future, it may become a
very suitable kernel for the graphics protocol we seek. As a
matter of fact, the CGI will be the communication protocol between
graphical application hosts and graphics terminals. At SRI we are
tracking its evolution, and we are interested in defining a format
based on the CGI.
その上、CGIには、グラフィカルな入力を得るための要素があります、グラフィックスデバイス能力、特性、および州について問い合わせるための要素と同様に。 その後、セクションIIIでは、私たちは、私たちが必要とする通信プロトコルには、これらの2つのクラスの要素がなぜ不要であるかを説明します。 CGIが発展するのに従って、著しい変化を受けるでしょう、そして、将来、私たちが求めるグラフィックスプロトコルのための非常に適当なカーネルになるかもしれません。 実は、CGIはグラフィカルなアプリケーションホストとグラフィックス端末の間で通信プロトコルになるでしょう。 SRIでは、私たちは発展を追跡しています、そして、CGIに基づく書式を定義したいと思います。
Finally, the Initial Graphics Exchange Specification [11] is not
aimed at our primary area of interest. The IGES defines standard
file and language formats for storing and transmitting
product-definition data that can be used, in part, to generate
engineering drawings and other graphical representations of
engineering products. Besides the CAD orientation of IGES, the
graphical output function may be secondary to other goals like
transmitting numerical-control machine instructions.
最終的に、相異なるCAD間のデータ交換規格[11]は私たちの興味がある一次領域を向けられません。 IGESは、工学が図面と工学品の他のグラフ表示であると生成するのに一部使用できる製品定義データを保存して、送るために標準ファイルと言語書式を定義します。 IGESのCADオリエンテーション以外に、グラフィカルな出力機能は数値制御機械語命令を伝えるような他の目標に次ぐかもしれません。
II. OPERATIONAL REQUIREMENTS AND USABILITY
II。 操作上の要件とユーザビリティ
The main goal of this paper is to lay the groundwork for the development of a vector graphics format to be used as a basis for an on-line graphical communication protocol. We call such a format an "interactive graphical communication format," or IGCF. In this section we describe some operational requirements and usable characteristics for an IGCF.
この紙の第一目的は、ベクタグラフィックス形式の開発がオンライングラフィカルな通信プロトコルの基礎として使用される土台を作ることになっています。 私たちは、そのような形式を「対話的なグラフィカルなコミュニケーション形式」、またはIGCFと呼びます。 このセクションで、私たちはIGCFのためにいくつかの操作上の要件と使用可能な特性について説明します。
A. Interoperation of Heterogeneous Systems
多相系のA.Interoperation
A first functional requirement is that an IGCF must permit
communication among heterogeneous graphical systems differing both
in the hardware used and in the software of their graphics
最初の機能条件書はIGCFがハードウェアにおける、相違の両方が使用した異種のグラフィカルなシステムとそれらのグラフィックスのソフトウェアのコミュニケーションを可能にしなければならないということです。
Aguilar [Page 6]
アギラル[6ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
application interfaces. This is a fundamental for attaining
communication among similar graphical application programs running
on dissimilar hardware and using dissimilar graphics interface
packages. Some examples of such application programs are graphics
editors, CAD systems, and graphical database retrieval programs
communicating with other editors, CAD programs, and graphical
databases, respectively.
アプリケーションは連結します。 これは、異なったハードウェアで動いて、異なった図形インターフェースパッケージを使用することで同様のグラフィカルなアプリケーション・プログラムの中でコミュニケーションに達するための基本的です。 そのようなアプリケーション・プログラムに関するいくつかの例が、それぞれグラフィックスエディタと、CADシステムと、他のエディタとコミュニケートするグラフィカルなデータベース利用プログラムと、CADプログラムと、グラフィカルなデータベースです。
B. Picture Capture
B.画像捕獲
A required characteristic of an IGCF is that it must be usable for
the exchange of static graphic pictures, i.e. for picture capture;
yet, it must not be restricted to final picture recording only.
There will be picture exchanges as part of the interactive
communication, and we anticipate the need to record the state of a
picture at some points during the on-line graphics engagement. We
foresee the creation of graphical IGCF libraries containing object
definitions and pictures for inclusion in new pictures. Since
metafiles have been used for a long time to capture pictures,
there is a strong motivation to base an IGCF on a metafile
standard in order to secure compatibility with a large number of
metafile sources and consumers.
IGCFの必要な特性は静的なグラフィック画像の交換に、それが使用可能であるに違いないということです、すなわち、画像捕獲のために。 しかし、それを最終的な録画だけに制限してはいけません。 対話的なコミュニケーションの一部として画像交換があるでしょう、そして、私たちはオンライングラフィックス約束の間諸点で画像の状態を記録する必要性を予期します。 私たちは新しい画像での包含のためにオブジェクト定義と画像を含むグラフィカルなIGCFライブラリの創設について見通します。 メタファイルが画像を得るのに長い間使用されているので、多くのメタファイルソースと消費者との互換性を保証するためにIGCFをメタファイル規格に基礎づける強い動機があります。
C. Prompt Transmission
C.の迅速なトランスミッション
In some forms of interactive graphical communication, like
audiographics conferencing, it is critical to convey across users
the real-time nature of the interaction. This dictates that object
creations and manipulations be transmitted as they happen rather
than as a final result since a substantial part of the information
may be transmitted concurrently with the construction or operation
of an object, possibly through associated media like voice. Since
both construction and manipulation processes have to be
transmitted, there is a limit to the number of intermediate states
that can be economically transmitted.
いくつかのフォームの対話的なグラフィカルなコミュニケーションでは、audiographics会議のように、ユーザの向こう側に相互作用の瞬時性を伝えるのは重要です。 これは、情報のかなりの部分以来の最終的な結果が同時にオブジェクトの工事か操作によって伝えられるかもしれないよりむしろ起こるのに従ってオブジェクト作成と操作が伝えられると決めます、ことによると声のような関連メディアで。 工事と操作プロセスの両方が伝えられなければならないので、経済的に伝えることができる中間的州の数への限界があります。
A third requirement is, therefore, that the IGCF elements provide
fine "granularity" to convey the dynamics of the constructions and
manipulations. We believe that it is sufficient that the IGCF have
basic construction elements like polygons, markers, polylines, and
text strings and that it transmit them only when they are
completed; i.e., it is not necessary to transmit partial
constructions of such elements.
したがって、3番目の要件があります。IGCF要素は構造と操作の力学を伝えるすばらしい「粒状」を提供します。 私たちは、IGCFには多角形、マーカー、polylines、およびテキスト文字列のような基本的な工事要素があって、完成するときだけそれらを伝えるのが、十分であると信じています。 すなわち、そのような要素の部分的な構造を伝えるのは必要ではありません。
The problem for manipulations extends beyond an IGCF. Whereas we
know that an IGCF should include segment transformations, segment
highlighting and segment visibility on/off, the transmitter must
操作のための問題はIGCFを超えて広がっています。 私たちは、IGCFが/でオフなセグメント変換、セグメントハイライト、およびセグメント目に見えることを含んでいるはずであるのを知っていますが、送信機は知らなければなりません。
Aguilar [Page 7]
アギラル[7ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
decide how often to sample an on-going transformation and transmit
its current state. The choice of a sampling frequency will depend
on the available transmission bandwidth.
どのようにしばしば継続している変換を抽出して、現状を伝えるか決めてください。 サンプリング周波数のこの選択は利用可能なトランスミッション帯域幅次第でしょう。
D. Low Traffic Volume
D.の低交通量
In many of the applications we envision, coordinate graphics will
be transmitted over narrow bandwidth channels, and thus it is
essential to minimize traffic. Accordingly, several requirements
are imposed on an IGCF to take advantage of the characteristics of
the graphics communication intercourse and architecture in order
to minimize traffic.
私たちが思い描くアプリケーションの多くでは、座標図形は細長い帯域幅チャンネルの上に伝えられるでしょう、そして、その結果、トラフィックを最小にするのは不可欠です。 それに従って、いくつかの要件が、トラフィックを最小にするのにグラフィックスコミュニケーション交流とアーキテクチャの特性を利用するためにIGCFに課されます。
An IGCF can help reduce traffic by including the basic geometric
objects from which so many other objects are built. Moreover, an
IGCF should permit the use of objects for the creation of more
complex objects; since reuse is very common, the result is a
reduction of traffic and storage cost.
IGCFは、他のとても多くのオブジェクトが組立している基本的な幾何オブジェクトを含んでいることによってトラフィックを減少させるのを助けることができます。 そのうえ、IGCFはオブジェクトの、より複雑なオブジェクトの創案の使用を可能にするはずです。 再利用が非常に一般的であるので、結果はトラフィックと倉庫保管料の減少です。
E. Preservation of Application Semantic Units
アプリケーションの意味ユニットのE.保存
A related requirement is that an IGCF must include elements to
represent graphical objects corresponding to real world entities
of the intended applications. For example, in a Navy application,
the entities of interest are carriers, submarines, planes, and the
like. We want to communicate such semantic units across systems
and to treat them as unitary objects because, in many
applications, communication is based on creating and operating
such units. If an IGCF has elements to represent such semantic
units, the communication traffic decreases because the entity
definitions can be transmitted only once and then reused, and
because the entities are manipulated as units rather than
separately manipulating their components.
関連する要件はIGCFが意図しているアプリケーションの本当の世界実体に対応するグラフィカルなオブジェクトを表すために要素を含まなければならないということです。 例えば、海軍アプリケーションでは、興味がある実体は、キャリヤーと、潜水艦と、飛行機と、同様のものです。 システムの向こう側にそのような意味ユニットを伝えて、コミュニケーションが多くのアプリケーションでそのようなユニットを作成して、操作するのに基づいているので、単一のオブジェクトとしてそれらを扱いたいと思います。 IGCFにそのような意味ユニットを表す要素があるなら、実体定義を一度だけ伝えて、次に、再利用できて、実体が別々にそれらのコンポーネントを操るよりユニットとしてむしろ操られるので、コミュニケーショントラフィックは減少します。
It turns out that there is a small set of primary operations that
can be applied to a graphical object, and an IGCF must have
elements representing such operations. In contrast to dumb
graphics terminals receiving screen refresh information from a
host, we foresee graphical communication taking place among
intelligent workstations that can exchange encoded operations,
interpret them, and apply them to objects stored locally.
グラフィカルなオブジェクトに適用できる小さいプライマリ操作があると判明して、IGCFは要素にそのような操作を表させなければなりません。 私たちはコード化された操作を交換できるインテリジェントワークステーションの中で行われるグラフィカルなコミュニケーションについて見通します、そして、受信がスクリーニングする馬鹿なグラフィックス端末と対照して、ホストからの情報をリフレッシュしてください、そして、それらを解釈してください、そして、局所的に保存されたオブジェクトにそれらを適用してください。
F. Transmission Batching
F.トランスミッションバッチング
We previously indicated the desirability of conveying to the human
users the real-time tempo of interactive graphics exchanges.
However, it is possible to do so without having to transmit
私たちは以前に、インタラクティブグラフィックス交換のリアルタイムの速度を人間のユーザに伝える願わしさを示しました。 しかしながら、そう伝わる必要はなくてするのは可能です。
Aguilar [Page 8]
アギラル[8ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
immediately all IGCF elements. As a matter of fact, IGCF elements
should be divided into those causing a change on a displayed
picture and those that do not, although both classes may cause
changes to the stored graphical data structures.
すぐに、すべてのIGCF要素。 実は、IGCF要素は表示された画像で変化を引き起こすものとそうしないそれらに分割されるべきです、両方のクラスは保存されたグラフィカルなデータ構造への変化を引き起こすかもしれませんが。
It is only necessary to transmit immediately those elements
causing a visible change on a displayed picture because they are
the ones whose reception and interpretation delivers information
to a human user. The second class of elements can be batched and
queued for transmission until one element of the first class is
submitted. We call the first class update Group-1, and the second,
update Group-2.
すぐに単にそれらがレセプションと解釈が人間のユーザに情報を配布するものであるので表示された画像で明らかな変化を引き起こすそれらの要素を伝えるのが必要です。 トランスミッションのために一流の1つの要素を提出するまで要素の二等をbatchedして、列に並ばせることができます。 アップデートGroup-2、私たちは一流をアップデートGroup-1、および2番目と呼びます。
The aforesaid division is quite important for packet
communications because each packet contains a hefty amount of
overhead control traffic. It is therefore mandatory to batch, into
a packet, as much client data as possible in order to reduce total
traffic. The batching units can be varied in size according to the
network traffic and response time of conference hosts. During
congested periods, the units may have to be increased, thus
lowering the number of messages, and then reduced when congestion
eases, thus increasing the number of messages.
各パケットが重い量の頭上のコントロールトラフィックを含んでいるので、パケットコミュニケーションに、前述の分割はかなり重要です。 したがって、それは、総トラフィックを減少させるためにパケット、できるだけ多くのクライアントデータへのバッチに義務的です。 会議のホストのネットワークトラフィックと応答時間に従ったサイズで計量装置を変えることができます。 混雑している期間、ユニットは増強されなければならないかもしれません、その結果、メッセージについてメッセージと、次に、混雑が軽くなるとき減少して、その結果、数を増やす数を下げます。
G. Simple Translation Between IGCF and User Interface
IGCFとユーザーインタフェースの間のG.の簡単な翻訳
According to the first requirement, an IGCF must permit the
interoperation of related heterogeneous graphics applications.
Such interoperation has, as an objective, the communication
between human users or between a human and a database.
Correspondingly, the interoperation involves a mapping between the
user interface commands and the IGCF elements. It is not advisable
to use the commands themselves as the IGCF elements; otherwise the
exchange would depend on the communicating systems, and every pair
of communicating systems would require an ad-hoc protocol.
最初の要件によると、IGCFは関連する異種のグラフィックスアプリケーションのinteroperationを可能にしなければなりません。 そのようなinteroperationには、目的として人間のユーザか人間とデータベースとのコミュニケーションがあります。 interoperationはユーザーインタフェースコマンドとIGCF要素の間のマッピングに対応する、かかわります。 IGCF要素としてコマンド自体を使用するのは賢明ではありません。 さもなければ、交換は交信システムによるでしょう、そして、すべての組の交信システムは臨時のプロトコルを必要とするでしょう。
An additional usability characteristic is that there must be a
simple mapping between IGCF elements and the actions represented
by the user interface commands employed for graphical
communications. This simplicity is a must because every
communicating graphical system must have a translator that ideally
should be very simple. It seems that the inclusion of command
sequence delimiters in the IGCF helps the simplicity since the
delimiters permit keeping a smaller amount of state information
for processing an IGCF stream.
追加ユーザビリティの特性はグラフィカルなコミュニケーションに使われたユーザーインタフェースコマンドで表されたIGCF要素と動作の間には、簡単なマッピングがあるに違いないということです。 あらゆる交信しているグラフィカルなシステムには理想的に非常に純真であるべき翻訳者がいなければならないので、この簡単さは絶対に必要なものです。 デリミタが、処理のための、よりわずかな量の州の情報がIGCFストリームであることを保つことを許可するのでIGCFでのコマンド・シーケンスデリミタの包含が簡単さを助けるように思えます。
We have verified the mapping from one set of commands for
audiographics conferencing to the IGCF proposed in this paper. The
私たちはaudiographics会議のための1セットのコマンドからこの紙で提案されたIGCFまでマッピングについて確かめました。 The
Aguilar [Page 9]
アギラル[9ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
mapping from user interface commands to IGCF can be done in a
direct and efficient manner; on the other hand, the reverse
mapping, from IGCF to user interface commands, is a more difficult
task. We anticipate that, in order to improve performance, we will
have to map the IGCF elements to calls to lower level subroutines
implementing the user interface actions. Whereas such mapping is
conceptually no more complex than translating IGCF to the commands
themselves, it will require considerably more programming.
コマンドをユーザーインタフェースからIGCFにダイレクトで効率的な方法で写像できます。 他方では、IGCFからユーザーインタフェースまでコマンドを写像する逆は、より難しいタスクです。 私たちは、性能を向上させるためにユーザーインタフェース動作を実装する下のレベルサブルーチンへの呼び出しにIGCF要素を写像しなければならないと予期します。 そのようなマッピングはいいえ、概念的に、コマンド自体への翻訳するより複雑なIGCFということですが、それは、かなりさらにプログラムを作るのを必要とするでしょう。
III. ELEMENTS OF AN IGCF
III。 IGCFの要素
IGCF Element Classes
IGCF要素のクラス
In this section we list the classes of elements that we believe an
IGCF should have in order to exchange vector graphics under the
requirements of the previous section. The classes correspond to
the common function classes in computer graphics interfaces, and
each contains elements corresponding to interface primitives and
attributes. We do not list the elements for each class because
they are exemplified by the elements in the proposed IGCF.
このセクションで、私たちは私たちが、IGCFが前項の要件の下でベクタグラフィックスを交換するために持っているはずであると信じている要素のクラスを記載します。 クラスはコンピュータ・グラフィックス・インタフェースの一般的な機能のクラスに対応します、そして、それぞれが基関数と属性を連結するように対応する要素を含んでいます。 それらが提案されたIGCFの要素によって例示されるので、私たちは各クラスのために要素を記載しません。
In the following list, two categories of functions are missing:
functions used to query the status of a graphics system, and input
functions. As a matter of fact, an IGCF only needs to have
elements representing actions that cause a change in the state of
the communicating graphical systems, and the inquire functions
obviously do not change their state. Even though an input function
executed at the transmitting end causes a local change, it is not
necessary to transmit the input command itself. The receivers only
need to get the data input, in IGCF representation, and they can
process the data in any manner, maybe simulating local input
actions.
以下のリストでは、機能の2つのカテゴリがなくなっています: 機能は以前はよくグラフィックスシステム、および入力機能の状態について質問していました。 機能について問い合わせてください。そして、実は、IGCFが、要素に交信グラフィカルなシステムの事情の変化を引き起こす動作を表させる必要があるだけである、明らかに、それらの状態を変えません。 入力機能は送信側の原因で地域変化を実行しましたが、入力コマンド自体を伝えるのは必要ではありません。 受信機は、IGCF表現におけるデータの入力を得る必要があるだけです、そして、どんな方法でもデータを処理できます、多分現場の声動作をシミュレートして。
Control
コントロール
Elements for workstation: initialization, control and
transformation; and elements for normalization transformation.
(The normalization and workstation transformations can be used
to implement zooming.)
ワークステーションのためのElements: 初期化、コントロール、および変換。 そして、正常化変換のための要素。 (ズームを実装するのに正常化とワークステーション変換を使用できます。)
Primitive attributes
原始の属性
Elements for primitive, segment, and workstation attributes.
原始のセグメント、およびワークステーション属性のためのElements。
Output primitives
出力基関数
Elements for output primitives.
出力基関数のためのElements。
Aguilar [Page 10]
アギラル[10ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
Segmentation
分割
Elements for basic segmentation and workstation independent
segment storage.
基本的な分割とワークステーション独立区分ストレージのためのElements。
Object manipulations can be implemented with segment
transformations. Object insertion can be implemented using
segment recall and segment visibility. Object deletion can be
implemented using segment deletion and segment visibility.
Object selection can use segment highlighting as feedback to
the user.
セグメント変換でオブジェクト操作を実装することができます。 セグメントリコールを使用して、セグメント目に見えることであるとオブジェクト挿入を実装することができます。 セグメント削除を使用して、セグメント目に見えることであると目的語削除を実装することができます。 オブジェクト選択はフィードバックとしてのセグメントハイライトをユーザに使用できます。
Dynamics
力学
A considerable part of the graphical information exchanged
through an IGCF will be in the form of pointer movements over a
background picture. Pointer tracking is used to transmit points
sampled from a graphical pointer trace in order to reproduce,
at the receivers, the movement of the pointer at the sender
site. This can be done either by just moving the cursor or by
tracing its movement with a line. Rubber band echoes are used
to signal areas, routes, and scopes in a highly dynamic way.
These are indicated by an echo reference point and a feedback
point.
IGCFを通して交換されたグラフィカルな情報のかなりの部分が背景画の上の指針運動の形にあるでしょう。 指針トラッキングは使用されて、再生するためにグラフィカルな指針跡から抽出されて、伝わるのが指します、受信機でことです、送付者サイトの指針の動き。 ただカーソルを動かすか、または系列で動きをたどることによって、これができます。 輪ゴムエコーは、非常にダイナミックな方法で領域、ルート、および範囲に合図するのに使用されます。 これらはエコー基準点とフィードバックポイントによって示されます。
Hierarchical object definitions
階層的なオブジェクト定義
The requirement for preserving application semantics dictated that
an IGCF include the means to represent objects that stand for
application entities, and to manipulate such entities as graphical
units. Furthermore, the low-traffic-volume requirement called for
the use of already existing objects for the creation of new ones.
アプリケーション意味論を保存するための要件は、IGCFがアプリケーション実体、グラフィカルなユニットのような実体を操るのに耐えるオブジェクトを表す手段を含んでいると決めました。 その上、低交通量要件は既に既存のオブジェクトの新しいものの作成の使用を求めました。
One way to meet the aforesaid requirements is by including in an
IGCF the means to represent object hierarchies. In such a
hierarchy an object is a set of output primitives associated with
a set of attribute values or a set of lower-level objects, each
associated with a composition of transformations [12].
前述の必要条件を満たす1つの方法はIGCFにオブジェクト階層構造を表す手段を含んでいることです。 そのような階層構造では、オブジェクトは1セットの属性値か1セットの低レベルオブジェクトに関連している出力基関数のセットです、それぞれ変換[12]の構成に関連しています。
Graphics segments can be used to implement objects in the lowest
level of a hierarchy. The definition of a higher-level object can
be represented by sequences of IGCF elements describing the
definition process. Such a definition can be done by instantiating
lower-level objects with specific transformation parameters. Thus
an IGCF must incorporate brackets to mark the beginning and end of
object definitions, object instantiations, and object
redefinitions.
階層構造の最も低いレベルでオブジェクトを実装するのにグラフィックスセグメントを使用できます。 定義プロセスについて説明するIGCF要素の系列は、よりハイレベルのオブジェクトの定義を表すことができます。 特定の変換パラメタがある低レベルオブジェクトを例示することによって、そのような定義ができます。 したがって、IGCFは、オブジェクト定義、オブジェクト具体化、およびオブジェクト再定義の首尾をマークするために括弧を取り入れなければなりません。
Aguilar [Page 11]
アギラル[11ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
In order to complement the mechanism for object definition, an
IGCF must permit the use of a flexible alphabet for creating
object identifiers that ensure the uniqueness of an identifier in
a hierarchy. The construction of the object identifiers is not
part of an IGCF, an IGCF only has to represent the identifiers.
Further, an identifier has to be independent of a communication
session and a particular graphics system so that identifiers
created at a host during one session can be used, in other
sessions possibly involving other hosts, to recall the objects
they label.
オブジェクト定義のためのメカニズムの補足となるように、IGCFはフレキシブルなアルファベットの階層構造の識別子のユニークさを確実にするオブジェクト識別子を作成する使用を可能にしなければなりません。 オブジェクト識別子の工事がIGCFの一部でない、IGCFだけが識別子を表さなければなりません。 さらに、識別子は1つのセッションの間にホストで作成された識別子を使用できるようにコミュニケーションセッションと特定のグラフィックスシステムから独立していなければなりません、それらがラベルするオブジェクトを思い出すためにことによると他のホストにかかわる他のセッションのときに。
We also leave to the communicating systems the implementation of
mechanisms to resolve duplicate identifiers when merging two
hierarchies, created in different sessions. In this paper we shall
limit ourselves to the warning that segment numbers do not qualify
as identifiers because they depend on the session and state of the
system in which they are created.
また、異なったセッションのときに作成された2つの階層構造を合併するとき、私たちはメカニズムの実装に写し識別子を交信システムに決議させます。 この紙では、私たちは自分達をセグメント番号がセッションのときによるので識別子の資格を得ないという警告とそれらが作成されるシステムの事情に制限するつもりです。
In addition to object definition and instantiation, an IGCF should
have elements representing operations on objects. The operations
so far identified are: transformation, deletion, display,
disappearance, expose, and hide. Expose is used to uncover objects
on a screen that are hidden by other objects; hide is used to
place an object behind others on a screen.
オブジェクト定義と具体化に加えて、IGCFは要素にオブジェクトの上に操作を表させるはずです。 今までのところ特定されている操作は以下の通りです。 変換、削除、ディスプレイ、消滅、露出、および獣皮。 露出はスクリーンの上の他のオブジェクトに隠れているオブジェクトの覆いを取るのに使用されます。 獣皮は、スクリーンの上の他のものの後ろにオブジェクトを置くのに使用されます。
IV. A PROPOSED IGCF
IV。 提案されたIGCF
A. Using the GKSM as a Basis
A. 基礎としてGKSMを使用すること。
An IGCF must be usable to transmit all graphical actions in a
conference session. This suggests to base an IGCF on a standard
session-capture graphics metafile, thus ensuring compatibility
with a large user population. We have based the proposed IGCF,
PIGCF, on the GKSM session-capture metafile specification because
GKSM contains many of the elements identified for an IGCF [14]. In
addition, the audit trail orientation of GKSM permits the
recording of interactive communication sessions for later play
out, and this is a feature that we anticipate will be frequently
used.
IGCFは会議の話し合いにおけるすべてのグラフィカルな動作を伝えるのにおいて使用可能であるに違いありません。 これはIGCFを標準のセッション捕獲グラフィックスメタファイルに基礎づけるために示されて、その結果、大きいユーザ人口との互換性を確実にします。 GKSMがIGCF[14]のために特定された要素の多くを含むので、私たちは提案されたIGCF、GKSMセッション捕獲メタファイル仕様のPIGCFを基礎づけました。 さらに、GKSMの監査証跡オリエンテーションは、後で終えてください。そうすれば、これが私たちが頻繁に使用されると予期する特徴であるので、対話的なコミュニケーションセッションの録音を可能にします。
The GKSM is a proper subset of our PIGCF and thus any graphical
system developed to handle the PIGCF, can read a GKSM metafile.
Conversely, the applications using the PIGCF should have an option
for constraining session recording only to the GKSM part, possibly
suppressing some session events. By doing so, we will be able to
ship a GKSM metafile to any correspondent who has GKSM
GKSMはPIGCFを扱うために開発された、私たちのPIGCFとその結果、どんなグラフィカルなシステムの真部分集合でありも、GKSMメタファイルを読むことができます。 逆に、PIGCFを使用するアプリケーションはGKSM部分だけにセッション録音を抑制するためのオプションを持つべきです、ことによるといくつかのセッションイベントを抑圧して。 そうすることによって、私たちはGKSMを持っているどんな通信員にもGKSMメタファイルを出荷できるでしょう。
Aguilar [Page 12]
アギラル[12ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
interpretation software. Alternatively, an application with a
GKSM interpreter but without an PIGCF interpreter can read a PIGCF
file interpreting only the GKSM part and ignoring the rest.
解釈ソフトウェア。 あるいはまた、GKSMインタプリタにもかかわらず、PIGCFインタプリタのないアプリケーションは、GKSM部分だけを解釈して、残りを無視しながら、PIGCFファイルを読むことができます。
Whereas the GKSM was specified for the GKS system, we believe that
the GKSM is a sound and general basis for all of our 2-D
applications. We feel that the GKSM specification is not parochial
to GKS systems but contains all the most useful items desired in a
metafile. In the future, we expect to tackle applications
requiring 3-D, like interactive repair and maintenance aids. When
GKS be augmented with 3-D capabilities [13], we will extend the
PIGCF with any necessary elements.
GKSMはGKSシステムに指定されましたが、私たちは、GKSMが私たちの2-Dアプリケーションのすべての健全で一般的な基礎であると信じています。 私たちは、GKSM仕様がGKSシステムに教区ではありませんが、メタファイルで必要なすべての最も役に立つ項目を含むと感じます。 将来、私たちは、対話的な修理とメインテナンス援助のように3Dを必要とするアプリケーションに取り組むと予想します。 GKSであるときには立体能力[13]で増大してください、そして、私たちはどんな必要な要素でもPIGCFを広げるつもりです。
We are aware that the GKSM specification is not part of the GKS
standard itself but is an appendix recommending such a metafile
format. Nevertheless, all the GKS vendor implementations that we
know of, at the present time, support GKSM metafile output and
interpretation. If this trend continues, as we expect, we will be
able to exchange graphical files with a large base of GKS
installations. There will indeed be many of them since GKS will be
adopted as an standard by ISO and by many national standard bodies
in the near future.
私たちはGKSM仕様がGKS規格自体の一部ではありませんが、そのようなメタファイル書式を推薦する付録であることを意識しています。 それにもかかわらず、私たちが知っているすべてのGKSベンダー実装が、現在でGKSMがメタファイル出力と解釈であるとサポートします。 私たちが予想するようにこの傾向が続くと、私たちはGKSインストールの大きいベースとグラフィカルなファイルを交換できるでしょう。 GKSが規格としてISOと近い将来の多くの国家規格本体によって採用されるので、本当に、それらの多くがあるでしょう。
B. Positional Information Coordinates
B.の位置の情報座標
Following the GKSM convention, the PIGCF positional information is
in normalized device coordinates, NDC. Thus the originator of a
conference must indicate the workstation window for the
conference. This window is the sub-rectangle of the NDC space
enclosing the area of interest for the conference. In most cases,
the participating workstations will take this window as their own.
However, the graphical systems should provide for the possibility
of a workstation choosing a different workstation window, which
may contain the conference window or just overlap it. Except for
special cases, a conference originator should not state a
conference workstation viewport. In this manner, each workstation
can display its workstation viewport in the most convenient
portion of the screen.
NDC、GKSMコンベンションに続いて、正常にされたデバイス座標にはPIGCFの位置の情報があります。 したがって、会議の創始者は会議のためにワークステーションの窓を示さなければなりません。 この窓は会議のために関心領域を囲むNDCスペースのサブ長方形です。 多くの場合、参加ワークステーションはそれら自身のとしてこの窓をみなすでしょう。 しかしながら、グラフィカルなシステムはワークステーションが会議ウィンドウを含んでいるか、またはただそれを重ね合わせるかもしれない異なったワークステーションの窓を選ぶ可能性に備えるはずです。 特別なケース以外に、会議の創始者は会議ワークステーションビューポートを述べるべきではありません。 この様に、各ワークステーションはスクリーンの最も便利な部分にワークステーションビューポートを表示できます。
There will be conferences where the participating workstations
will maintain the positional information in world coordinates, WC.
It might be necessary to reconstruct the world dimensions after
transmission because such dimensions have a relevant meaning for
the application, like sizes of components or distances. In this
case, a workstation will have to map from WC to NDC before
transmitting and from NDC to WC after receiving. At the outset,
the conference originator has to specify the world window and the
会議が参加ワークステーションがワールド座標系、トイレで位置の情報を保守するところにあるでしょう。 そのような寸法にはアプリケーションのための関連意味があるので、トランスミッションの後に世界寸法を再建するのが必要であるかもしれません、コンポーネントか距離のサイズのように。 この場合、ワークステーションは受信した後に、トイレからNDCまで伝わる前とNDCからトイレまで写像しなければならないでしょう。 そして最初に会議の創始者が世界ウィンドウを指定しなければならない。
Aguilar [Page 13]
アギラル[13ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
NDC viewport used in the conference in order for the conferencing
workstations to do such mappings. These mappings could be done by
the presentation layer, in terms of the ISO Open Systems
Interconnection Reference Model, in a manner that is transparent
to the communicating application programs.
NDCビューポートは、そのようなマッピングをするのに会議において、整然としている会議にワークステーションを使用しました。 プレゼンテーション層でこれらのマッピングができました、ISOオープン・システム・インターコネクションReference Modelに関して、交信アプリケーション・プログラムに見え透いた方法で。
Most often all workstations will have the same world windows and
NDC viewports. However, the graphical systems will provide for the
possibility of a workstation choosing a different window or
viewport, but such workstation will have to record the conference
ones for doing the aforesaid mappings. There are graphical
systems, like the ACM Core, that do not provide for a workstation
transformation. In such systems, the NDC viewport is considered to
be the workstation window for the aforesaid mappings.
たいていすべてのワークステーションには、同じ世界ウィンドウとNDCビューポートがあるでしょう。 しかしながら、グラフィカルなシステムはワークステーションが異なった窓かビューポートを選ぶ可能性に備えるでしょうが、そのようなワークステーションは、前述のマッピングをするために会議ものを記録しなければならないでしょう。 ACM Coreのようなワークステーション変換に備えないグラフィカルなシステムがあります。 そのようなシステムでは、NDCビューポートは前述のマッピングのためのワークステーションの窓であると考えられます。
C. Layers of the PIGCF
PIGCFのC.層
There are two levels in the PIGCF a lower level L and an upper one
U. The lower level L is just the GKSM metafile specification as
defined in Appendix E of the proposed GKS ANSI standard [14]. We
have excerpted most of Appendix E of [14] at the end of this RFC
as our Appendix A. All level L elements belong to the update
Group-1 except: SET DEFERRAL STATE, the output primitive attribute
elements, the workstation attribute elements, CLIPPING RECTANGLE,
CREATE SEGMENT, CLOSE SEGMENT, RENAME SEGMENT, SET SEGMENT
PRIORITY, and SET DETECTABILITY.
PIGCF a下のレベルLと上側のものU.には2つのレベルがあります。下のレベルLは提案されたGKS ANSI規格[14]のAppendix Eで定義されるようにただGKSMメタファイル仕様です。 以下を除いて、私たちのAppendixのA.のAllの平らなL要素がアップデートGroup-1に属して、私たちはこのRFCの端で[14]のAppendix Eの大部分を抜粋しました。 出力のSET DEFERRAL STATE、原始の属性要素、ワークステーション属性要素、CLIPPING RECTANGLE、CREATE SEGMENT、CLOSE SEGMENT、RENAME SEGMENT、SET SEGMENT PRIORITY、およびSET DETECTABILITY。
The upper level U is those elements that we believe complement the
GKSM for general on-line graphical exchanges. This layering
conforms to the graphics metafile level-structure described in
Enderle et. al [15]. Under such structuring, an application
oriented metafile can be based on graphical metafiles.
上側のレベルUは私たちが一般的なオンライングラフィカルな交換のためのGKSMの補足となると信じているそれらの要素です。 このレイヤリングはEnderle etアル[15]で説明されたグラフィックスのメタファイルの平らな構造に従います。 そのような構造で、アプリケーション指向のメタファイルはグラフィカルなメタファイルに基づくことができます。
D. PIGCF Elements in the Level U
レベルUのD.PIGCF Elements
The level U items are encoded as GKSM user item elements so that a
PIGCF file will conform to the GKSM metafile specification.
Accordingly, a PIGCF file will be a GKSM metafile in its entirety.
We use the same formatting conventions as the GKSM specification.
Those unfamiliar with these conventions should read the beginning
of the appendix. The following items belong to the second update
group: the two items for object definition, the two items for
object redefinition, the two items for object instantiation, the
two items for normalization transformation, SELECT COMPONENT, and
RECALL LIBRARY. The remaining items belong to the first update
group.
平らなU項目は、PIGCFファイルがGKSMメタファイル仕様に一致するように、GKSMユーザ項目要素としてコード化されます。 それに従って、PIGCFファイルは全体としてGKSMメタファイルになるでしょう。 私たちはGKSM仕様と同じ形式コンベンションを使用します。 これらのコンベンションになじみがないものは付録の始まりを読むはずです。 以下の項目は2番目のアップデートグループのものです: オブジェクト定義のための2つの項目、オブジェクト再定義のための2つの項目、オブジェクト具体化のための2つの項目、正常化変換のための2つの項目、SELECT COMPONENT、およびRECALL LIBRARY。 残っているアイテムは最初のアップデートグループに属します。
Aguilar [Page 14]
アギラル[14ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
Items for Object Definition
オブジェクト定義のための項目
BEGIN DEFINITION
定義を始めてください。
| 'GKSM 120' | L |
| 'GKSM120'| L|
Indicates beginning of object definition sequence
オブジェクト定義系列の始まりを示します。
END DEFINITION
終わりの定義
| 'GKSM 121' | L | I |
| 'GKSM121'| L| I|
Indicates end of object definition sequence. I(Nc): object
identifier ( N preceding c, i, r means an arbitrary number
of characters, integers, or reals.) Objects defined
interactively are made visible on the screen; i.e. they are
automatically instantiated. If only the definition is to be
kept but not the image, a DISAPPEAR item must follow.
オブジェクト定義系列の終わりを示します。 私(Nc): オブジェクト識別子(c、i、rに先行するNがキャラクタ、整数、または本物の特殊活字の数字を意味します。) インタラクティブに定義されたオブジェクトをスクリーンで目に見えるようにします。 すなわち、それらは自動的に例示されます。 DISAPPEARの品目は、イメージが保たれますが、定義がことである保たれてさえいない場合よかったのに続かなければなりません。
BEGIN REDEFINITION
REDEFINITIONを始めてください。
| 'GKSM 122' | L | I |
| 'GKSM122'| L| I|
Indicates beginning of object redefinition sequence
I(Nc): object identifier
オブジェクト再定義系列I(Nc)の始まりを示します: オブジェクト識別子
END REDEFINITION
終わりのREDEFINITION
| 'GKSM 123' | L |
| 'GKSM123'| L|
Indicates end of object redefinition sequence
オブジェクト再定義系列の終わりを示します。
Items for Object Instantiation
オブジェクト具体化のための項目
BEGIN INSTANTIATION
具体化を始めてください。
| 'GKSM 124' | L | I |
| 'GKSM124'| L| I|
Indicates beginning of object instantiation sequence
I(Nc): Object identifier
オブジェクト具体化系列I(Nc)の始まりを示します: オブジェクト識別子
END INSTANTIATION
終わりの具体化
| 'GKSM 125' | L |
| 'GKSM125'| L|
Indicates end of object instantiation sequence
オブジェクト具体化系列の終わりを示します。
Aguilar [Page 15]
アギラル[15ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
Items for Object Manipulation
オブジェクト操作のための項目
TRANSFORM OBJECT
変換オブジェクト
| 'GKSM 126' | L | C | I | M |
| 'GKSM126'| L| C| I| M|
Apply transformation M to object I
C: number of characters in identifier
I(Nc): object id
M(6r): upper and center rows of a 3x3 matrix representing
a 2D homogeneous transformation [12].
M 11 M 12 M 13 M 21 M 22 M 23
変換MをオブジェクトIに適用してください、C: 識別子I(Nc)のキャラクタの数: オブジェクトイドM(6r): 2D線形変換[12]を表す3×3マトリクスの上側の、そして、センターの行。 M11M12M13M21M22M23
DELETE OBJECT
オブジェクトを削除してください。
| 'GKSM 127' | L | I |
| 'GKSM127'| L| I|
I(Nc): object identifier
私(Nc): オブジェクト識別子
DISPLAY OBJECT
ディスプレイオブジェクト
| 'GKSM 128' | L | I |
| 'GKSM128'| L| I|
Turn on visibility of object I
I(Nc): object identifier
オブジェクトI I(Nc)の目に見えることをつけてください: オブジェクト識別子
DISAPPEAR OBJECT
見えなくなる、オブジェクト
| 'GKSM 129' | L | I |
| 'GKSM129'| L| I|
Turn off visibility of object I
I(Nc): object identifier
オブジェクトI I(Nc)の目に見えることをオフにしてください: オブジェクト識別子
EXPOSE OBJECT
露出オブジェクト
| 'GKSM 130' | L | I |
| 'GKSM130'| L| I|
Redisplay object I on top of any overlapping objects
I(c): object identifier
どんな重なっているオブジェクトI(c)の上のRedisplayオブジェクトI: オブジェクト識別子
HIDE OBJECT
オブジェクトを隠してください。
| 'GKSM 131' | L | I |
| 'GKSM131'| L| I|
Redisplay object I behind any overlapping objects
I(c): object identifier
どんな重なっているオブジェクトI(c)の後ろのRedisplayオブジェクトI: オブジェクト識別子
Aguilar [Page 16]
アギラル[16ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
SELECT COMPONENT
コンポーネントを選択してください。
| 'GKSM 132' | L | I | P |
| 'GKSM132'| L| I| P|
Select component P of object I
I(c): object identifier
P(i): pick id of component
This is used to select a group of output primitives
identified by P in a segment associated with I.
オブジェクトI I(c)の部品Pを選択してください: 識別子P(i)は反対します: コンポーネントのThisの選択イドは、Iに関連しているセグメントのPによって特定された出力基関数のグループを選択するのに使用されます。
ERASE COMPONENT
抹消コンポーネント
| 'GKSM 133' | L | I | P |
| 'GKSM133'| L| I| P|
Erase component P of object I
I(c): object identifier
P(i): pick id of component
オブジェクトI I(c)の部品Pを消してください: 識別子P(i)は反対します: コンポーネントのイドを選んでください。
This erases a group of output primitives identified by P in
a segment associated with I. This element can be used only
within a REDEFINE OBJECT sequence.
これはI.に関連しているセグメントのPによって特定された出力基関数のグループを消します。REDEFINE OBJECT系列だけの中でThis要素は使用できます。
Items for Normalization Transformation
正常化変換のための項目
SET WINDOW
窓を設定してください。
| 'GKSM 134' | L | W |
| 'GKSM134'| L| W|
Define boundaries of world window for normalization
transformation.
W(4r): limits of world window (XMIN, XMAX, YMIN, YMAX )
正常化変換のために世界ウィンドウの境界を定義してください。 W(4r): 世界ウィンドウの限界(XMIN、XMAX、YMIN、YMAX)
SET VIEWPORT
ビューポートを設定してください。
| 'GKSM 135' | L | V |
| 'GKSM135'| L| V|
Define boundaries of NDC viewport for normalization
transformation.
V(4r): limits of NDC viewport (XMIN, XMAX, YMIN, YMAX )
正常化変換のためにNDCビューポートの境界を定義してください。 V(4r): NDCビューポートの限界(XMIN、XMAX、YMIN、YMAX)
Aguilar [Page 17]
アギラル[17ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
Items for Other Operations
他の操作のための項目
ABORT
アボート
| 'GKSM 136' | L |
| 'GKSM136'| L|
Abort ongoing operation transmitted in PIGCF stream. This
provides the means to abort unwanted or erroneous
operations. Only the innermost operation of a nested
sequence is aborted; successive aborts can be used to get
out of several levels of operation nesting.
PIGCFストリームで伝えられた進行中の操作を中止してください。 これは求められていないか誤った操作を中止する手段を提供します。 入れ子にされた系列の最も奥深い操作だけが中止されます。 いくつかのレベルの操作巣篭もりを出るのに連続したアボートを使用できます。
POINTER TRACKING
指針トラッキング
| 'GKSM 137' | L | T | P |
| 'GKSM137'| L| T| P|
Update graphical pointer position to P
T(i): 0 causes only cursor to be moved
1 causes cursor movement to be traced with
a line
P(p): a point sampled from graphical pointer
movement trace
P T(i)のグラフィカルな指針位置をアップデートしてください: 0は動く1原因が系列P(p)と共にたどられるべきカーソル移動であったならカーソルだけを引き起こします: グラフィカルな指針動き跡から抽出されたポイント
Aguilar [Page 18]
アギラル[18ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
RUBBER BAND
輪ゴム
| 'GKSM 138' | L | T | P |
| 'GKSM138'| L| T| P|
Echo a rubber band of type T with given reference and
feedback points. The first occurrence of this item in a
sequence carries the coordinates of the echo reference
point. Subsequent occurrences carry updates to a pointer
position indicating an echo feedback point.
与えられた参照とフィードバックポイントでタイプTの輪ゴムを反響してください。 この項目の最初の発生は次々にエコー基準点の座標を運びます。 その後の発生はエコーフィードバックポイントを示す指針位置までアップデートを運びます。
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)
T(i): タイプ(0エコー基準点; >0エコーフィードバック: 1つの=系列、2=長方形、3=円)P(r)を反響してください: エコー参照ポイント(T=0)、またはエコーフィードバックポイント(T>0)
The reference and feedback points are:
T = 1 - reference is one end of line, feedback is
other end.
T = 2 - reference is one corner of rectangle, feedback
is opposite corner.
T = 3 - reference is center of circle, feedback is
perimeter point.
参照とフィードバックポイントは以下の通りです。 T=1--参照が系列の片端である、フィードバックは他の終わりです。 T=2--参照が長方形の1つの角である、角の反対側にフィードバックがあります。 T=3--参照は円の中心、フィードバックが周辺ポイントであるということです。
RECALL LIBRARY
ライブラリを思い出してください。
| 'GKSM 139' | L | F |
| 'GKSM139'| L| F|
Recall graphical library in file F
F(i): name of file containing library
ファイルF F(i)でグラフィカルなライブラリを思い出してください: ライブラリを含むファイルの名前
The graphical pictures in F and all their components become
available for use during the communication session. The
pictures are assumed to be recorded with the PIGCF, and
their components have to be displayed with DISPLAY OBJECT
elements or similar actions so that the pictures become
visible.
Fのグラフィカルな画像とそれらのすべてのコンポーネントがコミュニケーションセッションの間、使用に利用可能になります。 PIGCFと共に画像が記録されると思われて、画像は、DISPLAY OBJECT要素か同様の動作と共にそれらのコンポーネントを表示しなければならないので、目に見えるようになります。
Aguilar [Page 19]
アギラル[19ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
V. AN ARCHITECTURE FOR PIGCF PROCESSING
V。 PIGCF処理のためのアーキテクチャ
This section presents an example software architecture for the generation and interpretation of PIGCF in a multimedia conferencing system using GKS as the underlying programmer's graphics interface. This section should not be interpreted as a definitive statement of such an architecture, but only as an exercise to illustrate how the format proposed in this paper fits within the overall framework of a conferencing system. Choosing GKS simplifies the example architecture; nevertheless, other graphics packages can be used by adding, to the architecture, the modules to interpret and generate the PIGCF level L items.
このセクションは、マルチメディア会議システムにおける、PIGCFの世代と解釈のために基本的なプログラマの図形インターフェースとしてGKSを使用することで例のソフトウェア・アーキテクチャを提示します。 このセクションは、この紙で提案された形式が会議システムの総合的なフレームワークの中でどう合うかを例証するためにそのようなアーキテクチャの決定的な声明として解釈されるのではなく、単に運動として解釈されるべきです。 GKSを選ぶと、例のアーキテクチャは簡略化します。 それにもかかわらず、PIGCFの平らなLの品目を解釈して、生成するためにモジュールをアーキテクチャに追加することによって、他のグラフィックスパッケージを使用できます。
Figure 1 shows the major software modules charged with graphics interaction and display at a conferencing workstation. This is a familiar programmer's view of the graphics pipeline. A conferencing application program updates data structures and uses device-independent graphics services through a language binding. These services, in turn, use device-dependent graphics services that call on device drivers to accept input and to present graphic pictures. The application performs numerous other functions for conference management and control of other media streams, but we need not consider them in this example.
図1は会議ワークステーションでグラフィックス相互作用とディスプレイで告発された主要なソフトウェア・モジュールを示しています。 これは詳しいプログラマのグラフィックスパイプラインの視点です。 会議アプリケーション・プログラムは、データ構造をアップデートして、言語結合でデバイスから独立しているグラフィックスサービスを利用します。 これらのサービスは順番にデバイスドライバが入力を受け入れて、グラフィック画像を提示するよう呼びかけるデバイス依存するグラフィックスサービスを利用します。 アプリケーションは他のメディアストリームの会議管理とコントロールのために他の多数の機能を実行しますが、私たちはこの例でそれらを考える必要はありません。
In Figure 2, the basic graphics pipeline has been augmented with the software modules involved in the generation, transmission, reception, and interpretation of PIGCF streams. The application has a module for interpreting the lower and higher levels of PIGCF and one for generating the upper level U. The device-independent graphics services include modules for generating and interpreting the lower level, L. This reflects the current practice of including the generation and interpretation functions in the graphics package. There is also a module that transmits the outgoing PIGCF streams to remote work stations. Similarly, there is a module that receives incoming streams from remote stations. In actual practice, the transmit and receive modules are decomposed into several processes implementing a layered protocol architecture. A process receives both levels of PIGCF and writes them into a conference record metafile for future use. A router process receives and forwards PIGCF traffic from and to the modules previously referred. This router is likely to be replaced by independent communication interfaces between pairs of modules exchanging PIGCF.
図2では、PIGCFストリームの世代にかかわるソフトウェア・モジュール、トランスミッション、レセプション、および解釈によると、基本的なグラフィックスパイプラインは増大しました。アプリケーションには、上側のレベルUを生成するために下側の、そして、より高いレベルのPIGCFと1つを解釈するためのモジュールがあります; デバイスから独立しているグラフィックスサービスは下のレベルを生成して、解釈するためのモジュールを含んでいます、そして、L.Thisは世代を含む現在の習慣を反映します、そして、解釈はグラフィックスパッケージの中に機能します。 また、外向的なPIGCFストリームをリモートワークステーションに伝えるモジュールがあります。 同様に、遠隔局から入って来るストリームを受けるモジュールがあります。 モジュールを送受信してください。現実実務で分解する、層にされたプロトコルがアーキテクチャであると実装しながら、いくつかのプロセスに分解されます。 プロセスは、PIGCFの両方のレベルを取って、今後の使用のために会議記録メタファイルにそれらを書きます。 ルータプロセスは、受信して、モジュールと、そして、以前に参照されたモジュールへのトラフィックをPIGCFに送ります。 このルータは、PIGCFを交換しながら、組のモジュールの間で独立している通信インターフェースに取り替えられそうです。
The thick arrows show the flow of outgoing PIGCF, whereas the thin arrows show the incoming PIGCF flow. We first follow the outgoing path, starting at the application. The application processes local user actions which are transformed into data structure updates, level
厚い矢は出発しているPIGCFの流れを示していますが、薄い矢は入って来るPIGCF流動を示しています。 私たちは最初に、アプリケーションから外向的な経路の後をつけます。 アプリケーションはデータ構造アップデート、レベルに変えられる地方のユーザ動作を処理します。
Aguilar [Page 20]
アギラル[20ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
U PIGCF elements, and executions of device independent graphics subroutines that, among other things, generate level L PIGCF (GKSM) elements.
平らなL PIGCF(GKSM)に要素を特に生成するU PIGCF要素、およびデバイスの独立しているグラフィックスサブルーチンの実行。
The router merges both level streams according to generation order and sends them to the local copy of the conference record and to the transmission module. The latter batches Group-2 PIGCF items until it receives a Group-1 item. It also timestamps the PIGCF stream to synchronize its play-back, at the receiver, with the play-back of other media information. The PIGCF may be separated into traffic categories transmitted over diverse communication facilities according to the transport services required by the categories, for example, real-time service for pointer updates, highly reliable transmission for new object definitions, or low-priority service for graphical library transfers. Finally, the transmit module must acknowledge the reception of incoming PIGCF, and of other media traffic as well.
ルータは、世代命令によって両方の平らなストリームを合併して、会議記録の地方のコピーと、そして、トランスミッションモジュールにそれらを送ります。 それまでの後者のバッチGroup-2 PIGCFの品目はGroup-1の品目を受けます。 それ、また、PIGCFが受信機で他のメディア情報の再生に再生を連動させるように流すタイムスタンプ。 PIGCFはカテゴリによって必要とされた輸送サービスに従ってさまざまの通信機器の上に伝えられたトラフィックカテゴリに切り離されるかもしれません、例えば、指針アップデートのためのリアルタイムのサービス、新しいオブジェクト定義のための高信頼性トランスミッション、またはグラフィカルなライブラリに、低い優先サービスが移されます。 最終的である、必須が入って来るPIGCF、および他のメディアトラフィックのレセプションをよく承認するモジュールを伝えてください。
The receive module is the entry point for incoming PIGCF streams that may come within diverse traffic categories requiring merging. It checks the timestamps for synchronizing PIGCF items with related data in other media, for example, voice. It is possible to include here a high-level error-correction function that validates the received streams using state and context information about PIGCF syntax and semantics. The receive module passes the streams to the router which forwards them to three processes: It sends level L items to the GKSM interpreter which produces the corresponding changes on the displayed picture; it sends level L and level U items to the conference record, as well as to the PIGCF interpretation code in the application. The level U items cause updates to both the data structures modeling object hierarchies, and the pictorial representation of the hierarchies, through the execution of graphics services. U items also update graphics cursors and may recall new graphics libraries. The application must process level L items because they could indicate updates to the data structures; this happens if, for example, the structures record attribute value information for the object hierarchies. The application coordinates these actions with other media effects according to the timestamps. Conference record play-back is done in off-line mode. Record items are received by the router and thereafter processed similarly to incoming PIGCF.
受信してください。モジュールは合併するのが必要でありながらさまざまのトラフィックカテゴリに含まれるかもしれない入って来るPIGCFストリームのためのエントリー・ポイントです。 それはPIGCFの品目を関連するデータと他のメディア、例えば、声で同期させるのがないかどうかタイムスタンプをチェックします。 ここにPIGCF構文と意味論の状態と文脈情報を使用することで容認されたストリームを有効にするハイレベルのエラー訂正機能を含んでいるのは可能です。 受信してください。モジュールは3つのプロセスにそれらを送るルータにストリームを通過します: それは平らなL商品をGKSMインタプリタに送ります(対応する変化を表示された画像に発生させます)。 それはレベルLと平らなU商品を会議記録に送ります、よくアプリケーションにおけるPIGCF解釈コードのように。 平らなU項目原因はモデルオブジェクト階層構造、および階層構造の絵の表現を両方のデータ構造にアップデートします、グラフィックスサービスの実行で。 U項目も、グラフィックスカーソルをアップデートして、新しいグラフィックスライブラリを思い出すかもしれません。 彼らがアップデートをデータ構造に示すかもしれないので、アプリケーションは平らなL項目を処理しなければなりません。 例えば、構造がオブジェクト階層構造のための属性値情報を記録するなら、これは起こります。 タイムスタンプに応じて、アプリケーションは他のメディア効果に伴うこれらの動作を調整します。 オフライン・モードでコンファレンス記録再生をします。 記録的な項目は、ルータによって受け取られて、その後、同様に入って来るPIGCFに処理されます。
Aguilar [Page 21]
アギラル[21ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
+------------+ +-------------+
|APPLICATION | | OTHER |
| DATA | | MEDIA |
|STRUCTURES | |-------------|
+-----|------+ | CONFERENCE |
|----------> | APPLICATION |
| GRAPHICS |
|----------> | |
+-----|------+ | |
| LANGUAGE | +-------------+
| BINDING |
+-----|------+ +-------------+
|----------> | DEVICE- |
+------------+ | INDEPENDENT |
| DEVICE | | GRAPHICS |
| DEPENDENT | <---> | SERVICES |
| GRAPHICS | | |
| SERVICES | | |
+-----|------+ | |
| | |
v | |
+------------+ | |
| DEVICE | | |
| DRIVERS | | |
+------------+ +-------------+
+------------+ +-------------+ |アプリケーション| | 他| | データ| | メディア| |構造| |-------------| +-----|------+ | 会議| |、-、-、-、-、-、-、-、-、--、>| アプリケーション| | グラフィックス| |、-、-、-、-、-、-、-、-、--、>|、| +-----|------+ | | | 言語| +-------------+ | 付きます。| +-----|------+ +-------------+ |、-、-、-、-、-、-、-、-、--、>| デバイス| +------------+ | 独立者| | デバイス| | グラフィックス| | 扶養家族| <-->、| サービス| | グラフィックス| | | | サービス| | | +-----|------+ | | | | | v| | +------------+ | | | デバイス| | | | ドライバー| | | +------------+ +-------------+
FIGURE 1 - THE BASIC GRAPHICS PIPELINE
IN A CONFERENCING SYSTEM
1図--会議システムの基本的なグラフィックスパイプライン
Aguilar [Page 22]
アギラル[22ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
+------------+ +------------+ +------------------+
|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 |===> | |
+------------+ +------------+ +-----+
+------------+ +------------+ +------------------+ |アプリケーション| | 他| | 伝わってください。| | データ| | メディア| | ACK|=>| 構造| |------------| +-----+ | 別々のトラフィック|=>+-----|------+ | 会議| | |===>| バッチング|=>|---------->|アプリケーション| | | | TIMESTAMPING| | グラフィックス| | | +------------------+ |、-、-、-、-、-、-、-、-、--、>|、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| PIGCF L、U| <--、|、| +------------------+ +-----|------| | インタプリタ| | | | 受信してください。| | 言語| +------------+ | R| | トラフィックを合併してください。| <、-、| 付きます。| | PIGCF U|===>| O| <--、| タイムスタンプをチェックしてください。| <、- +-----|------+ | ジェネレータ| | U| | エラー修正| <、-、| +------------+ | T| | | ------------------| | E| +------------------+ +------------+ +-----V------+ | R| | デバイス| | デバイス| | | +------------------+ | 扶養家族| |独立者| | |====>|、|、| グラフィックス| <-->、| グラフィックス| | |、-、-、--、>| 会議| | サービス| | サービス| | | | 記録| | | | | | | | | +-----|------+ |------------| | | +------------------+ | | GKSM| | | v| インタプリタ| <、-、--、|、| <-- 入って来るPIGCF+------------+ +------------+ | | | デバイス| | GKSM| | | ===>の出発しているPIGCF| ドライバー| | ジェネレータ|===>|| +------------+ +------------+ +-----+
FIGURE 2 - A CONFERENCING SOFTWARE ARCHITECTURE FOR PROCESSING PIGCF
2図--処理PIGCFのための会議ソフトウェア・アーキテクチャ
VI. CONCLUSIONS
VI。 結論
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
現在のところ、必要なプロトコルとして、または、プロトコルのための形式として存在かグラフィックス標準として現れるどれかを使用できませんが、規格が発展するのに応じて、これは変化するかもしれません。 私たちは、規格開発をモニターしていて、形式基礎、特にCGIとしてそれらのいくつかの使用を研究するつもりです。 それにもかかわらず、コンピュータ
Aguilar [Page 23]
アギラル[23ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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.
コミュニケーション共同体はとてもマルチメディア会議実装の経験を必要とします。 これらのアプリケーションが起こるように、人は広いユーザベースがある相互運用性を保証しながら、グラフィックス通信プロトコルを職員、または、その結果広い使用を獲得しそうなデファクト規格に基礎づけることができます。 私たちは、GKSMセッションメタファイルを使用することによって適切な方向に入って来ていると信じています。
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.
提案されたPIGCFを生成して、解釈するためにソフトウェア・アーキテクチャを計画していると、私たちが完全なグラフィックスプロトコルの開発に向かって仕事を続けているのに応じて、私たちが直面するつもりであるいくつかの問題が持って来られました。 マルチメディア通信におけるSRIの継続しているプログラムの一部としてこれをしています。 このプログラムの中では、私たちは、簡単なマルチメディア会議プロトタイプを実装していて、より完全なものを設計するつもりです。 両方の運動からの経験はプロトコルアーキテクチャデザインへの貴重な入力になるでしょう。
Aguilar [Page 24]
アギラル[24ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
APPENDIX A
付録A
Excerpt from "Draft Proposal: Graphical Kernel System" [14]
抜粋、「提案を作成してください」 「グラフィカルなカーネルシステム」[14]
E.2 Metafile Based on ISO DIS7942
ISO DIS7942に基づくE.2メタファイル
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.
このメタファイルはGKSにされたファンクションコールの完全系列を記録する手段を提供することを目指すものとして分類されるかもしれません。 機能的な能力は平らなmからレベル2まで全体の範囲のGKS出力関数をカバーしています。 したがって、それは個々のグラフィックス動作が'再生される'必要があるアプリケーションに適しています、インタプリタが恐らく選択しているグラフィカルな編集を完了していて。
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.
2encodingsがこのメタファイルに指定されました。 多くのアプリケーションに、あるコード化が効率が悪いです。 2番目は不特定のバイナリフォーマットを許容します。 このIGCF付録の残りはこれらのメタファイル構造とencodingsの一部始終を与えます。
E.2.1 File Format and Data Format
E.2.1ファイル形式とデータの形式
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:
GKSメタファイルは論理的なデータ項目の系列として確立されます。ファイルはメタファイル(作者、インストール)の発生源、以下の項目の形式、および数表現を説明する固定フォーマットでファイルヘッダーから始まります。 最終品目がファイルの必然的な結末を示していて、ファイルは終わります。 これらの2つの項目の間では、以下の情報は監査証跡の意味に記録されます:
a) workstation control items and message items;
a) ワークステーション管理項目とメッセージ項目。
b) output primitive items, describing elementary
graphics objects;
基本のグラフィックスオブジェクトについて説明して、b)は原始の項目を出力しました。
c) attribute information, including output primitive
attributes; segment attributes, and workstation
attributes;
c) 出力の原始の属性を含む情報を結果と考えてください。 セグメント属性、およびワークステーション属性。
d) segment items, describing the segment structure and
dynamic segment manipulations;
d)セグメント項目、セグメント構造について説明して、およびダイナミックなセグメント操作。
e) user items.
e)ユーザ項目。
Aguilar [Page 25]
アギラル[25ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
The overall structure of the GKS metafile is as follows:
GKSメタファイルの全体的な構造は以下の通りです:
FILE: |file |item|---|item|---|end |
|header| 1 | | i | |item|
以下をファイルしてください。 |ファイル|項目|---|項目|---|終わり| |ヘッダー| 1 | | i| |項目|
ITEM: |item |item data record|
|header | |
項目: |項目|項目データレコード| |ヘッダー| |
ITEM |'GKSM' |identification|length of item data|
項目|'GKSM'|識別|項目データの長さ|
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;
a) ファイルの読みやすさを改良して、誤り制御施設を提供するために存在しているキャラクタストリング'GKSM'(任意の)。
b) the item type identification number which indicates
the kind of information that is contained in the
item;
b) 項目に含まれている情報の種類を示す項目タイプ確認番号。
c) the length of the item data record.
c) 項目データレコードの長さ。
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.)
メタファイルは(c)、(i)、項目記述における(r)であるとマークされたキャラクタ、整数、および実数を含んでいます。 ISO646とISO2022に従って、メタファイルにおけるキャラクターは表されます。 ISO6093に従って、数は、整数のための形式F1と本物のための形式F2を使用することで表されるでしょう。 (注意: 形式のF1とF2はFORTRAN形式私とFでそれぞれ書かれていて、読むことができます。)
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.
座標について説明する実数と長さの単位は正常にされたデバイス座標として保存されます。 この形式のメタファイルを書くワークステーションのためのアプリケーション・プログラムで指定されるなら、ワークステーション変換は実行されませんが、WORKSTATION WINDOWとWORKSTATION VIEWPORTは後の用法のためにデータ項目に保存されます。 実数は整数として保存されるかもしれません。 この場合、変換パラメタは、正常にされたデバイス座標に整数の適切な変換を許容するためにファイルヘッダーで指定されます。
Aguilar [Page 26]
アギラル[26ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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.
節約のために、内部のバイナリフォーマットを使用することで数を保存できます。 規格が全く2進数表示のために存在していなくて、この形式はメタファイルの移植性を制限します。 このドキュメントの範囲の外にそのような2進数表示の仕様があります。
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
メタファイルのE.3世代
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.
テーブルE 1はリストを含んでいます、カテゴリMOのワークステーション、およびこのGKSMへのそれらの効果に適用されるすべてのGKS機能のクラスで。 テーブルでは、GKSM-OUTはこの形式のメタファイルを書くワークステーションを示すワークステーション識別子です。
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]).
切り取り長方形と切り取りインディケータの概念は切り取り長方形を指定する1つのメタファイル項目でカプセル化されます。 この項目がメタファイルに書かれている、値(0、1、0、1)でワークステーションを動かしてください、切り取りインディケータがOFF、または現在の正常化変換のビューポートであるなら、切り取りインディケータがONであるなら。 切り取りインディケータがONであるときに、現在の正常化変換のビューポートが再定義されるか、または異なった正常化変換が選択されるなら、さらなる切り取り長方形の品目は書かれます。 切り取りインディケータがOFFに変わるなら、切り取り長方形の品目(0、1、0、1)は書かれます。 切り取りインディケータがONに変わるなら、現在の正常化変換のビューポートを含む項目は書かれます。 これはセグメントにおける切り取りの取り扱いに類似しています。(4.7.6[14])を見てください。
GKS functions which apply to workstations GKSM item created of category MO or effect ========================================================================
カテゴリMOか効果について作成されたワークステーションGKSMの品目に適用されるGKS機能========================================================================
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
開いているワークステーション(外のGKSM、…) - (ファイルヘッダー) 1 (CONDITIONAL)CLOSE WORKSTATION(GKSM-OUT)0(最終品目)ACTIVATE WORKSTATION(GKSM-OUT)(21-44の61)は属性電流を確実にします。 出力を可能にしてください。
Aguilar [Page 27]
アギラル[27ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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
________________________________________________________________________
DEACTIVATE WORKSTATION(GKSM-OUT)は、出力がCLEAR WORKSTATION(GKSM-OUT、…)であると無効にします。 1 2はワークステーション(外のGKSM)アップデートワークステーション(外のGKSM、…)の上のすべてのセグメントを描き直します。 3 セット延期状態(外のGKSM、…) 4メッセージ(外のGKSM、…) 5 (メッセージ)エスケープ6________________________________________________________________________
Output Primitives
出力基関数
POLYLINE 11 POLYMARKER 12 TEXT 13 FILL AREA 14 CELL ARRAY 15 GENERALIZED DRAWING PRIMITIVE 16 ________________________________________________________________________
POLYLINE11POLYMARKER12テキスト13は原始の16を描きながら一般化された領域14セル配列15をいっぱいにしています。________________________________________________________________________
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
膨張係数31セット文字間隔32指定教材色のインデックス33セットキャラクタの高さ34はベクトル34指定教材経路35指定教材整列36セット中詰め領域インデックス37セットの中詰めの領域の内部のスタイル38セット中詰め領域スタイルインデックス39セット中詰め領域色のインデックス40にキャラクタを設定します。
SET PATTERN SIZE 41 SET PATTERN REFERENCE POINT 42
パターンサイズ41セットパターン基準点42を設定してください。
Aguilar [Page 28]
アギラル[28ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
SET ASPECT SOURCE FLAGS 43 SET PICK IDENTIFIER 44 ________________________________________________________________________
ソース旗43が設定するセット局面は識別子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 ________________________________________________________________________
POLYLINE表現(外のGKSM、…)を設定してください。 51 セットPOLYMARKER表現(外のGKSM、…) 52 指定教材表現(外のGKSM、…) 53 セット中詰め領域表現(外のGKSM、…) 54 セットパターン表現(外のGKSM、…) 55 セット色の表現(外のGKSM、…) 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
現在の正常化61、34、41、42変換SELECT NORMALIZATION TRANSFORMATION61、34、41、42SET CLIPPING INDICATOR61SET WORKSTATION WINDOW(GKSM-OUT、…)の現在の正常化34、41、42変換SET VIEWPOINTのSET WINDOW 71セットワークステーション窓のビューポート(外のGKSM、…) 72
Note: item 61 (CLIPPING RECTANGLE) is described more fully in E.2.2.
以下に注意してください。 項目61(CLIPPING RECTANGLE)は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). ________________________________________________________________________
以下に注意してください。 現在の正常化変換を変更するとき、(項目34、41、および42)をコーディネートしている情報を含む属性に対応する項目に送ります。 ________________________________________________________________________
Segment Functions
セグメント機能
CREATE SEGMENT 81 CLOSE SEGMENT 82 RENAME SEGMENT 83 DELETE SEGMENT 84
作成、近いセグメント82がセグメント83に改名するセグメント81はセグメント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)
ワークステーション(外のGKSM、…)からセグメントを削除してください。 ワークステーション81がある84の副セグメント、(21-44)、(11-16)(外のGKSM、…) (61), ワークステーション(外のGKSM、…)への82コピーセグメント (21-44), (11-16), (61)
INSERT SEGMENT (21-44), (11-16), (61) ________________________________________________________________________
セグメント(21-44)、(11-16)、(61)を挿入してください。________________________________________________________________________
Aguilar [Page 29]
アギラル[29ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
Segment Attributes
セグメント属性
SET SEGMENT TRANSFORMATION 91
セグメント変換91を設定してください。
SET VISIBILITY 92 SET HIGHLIGHTING 93 SET SEGMENT PRIORITY 94 SET DETECTABILITY 95 ________________________________________________________________________
目に見えること92セットハイライト93セットセグメント優先権94セット検出度95を設定してください。________________________________________________________________________
Metafile Functions
メタファイル機能
WRITE ITEM TO GKSM > 100 ________________________________________________________________________
GKSM>100に項目を書いてください。________________________________________________________________________
E.4 Interpretation of Metafiles
メタファイルのE.4解釈
E.4.1 Introduction
E.4.1序論
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.
GKSにおける、メタファイルの解釈は4.9[14]で説明されます。 すべてのタイプのメタファイル項目のためのINTERPRET ITEMの効果は以下のセクションで説明されます。 機能性のクラスは項目から構成されています。
E.4.2 Control Items
E.4.2管理項目
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.5との各個条の定義で説明されます。 の代わりにする、([14]が読む、「E.2.4"、「私たちが誤りであると信じているE.5")、」
E.4.3 Output Primitives
E.4.3出力基関数
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).
このクラスにおける、項目の解釈は原始関数に対応する出力を生成します、ポイントの座標がNDCに表されるのを除いて。 基関数に縛られた原始の属性はこの特定のメタファイルにおける、原始の属性項目の解釈から発したもの(E.4.4を見る)です。
E.4.4 Output Primative Attributes
E.4.4出力Primative属性
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.
このクラスにおける、項目の解釈は次にこの特定のメタファイルから発する基関数のディスプレイに使用のための値をはめ込みます(E.4.3を見てください)。 GKS州のリストで変更を全くエントリーにしません。
Aguilar [Page 30]
アギラル[30ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
E.4.5 Workstation Attributes
E.4.5ワークステーション属性
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.
このクラスにおける、項目の解釈には、Tableに1E示された対応するGKS機能の実施と同じ効果があります。 GKS機能はすべてのアクティブなワークステーションに実行されます。
E.4.6 Transformations
E.4.6変換
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.
切り取り長方形の品目の解釈は次にこの特定のメタファイルから発する切り取り出力基関数に使用のための値をはめ込みます。 GKS州のリストで変更を全くエントリーにしません。 このクラス(WORKSTATION WINDOWとWORKSTATION VIEWPORT)における、他の項目の解釈はすべてのアクティブなワークステーションの上で対応するGKS機能の実施を引き起こします。
E.4.7 Segment Manipulation
E.4.7セグメント操作
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.)
このクラスにおける、項目の解釈には、Tableに1E示された対応するGKS機能の実施と同じ効果があります。 (項目84はDELETE SEGMENTの実施を引き起こします。)
E.4.8 Segment Attributes
E.4.8セグメント属性
Interpretation of items in this class has the same effect as
invocation of the corresponding GKS functions shown in Table
E1.
このクラスにおける、項目の解釈には、Tableに1E示された対応するGKS機能の実施と同じ効果があります。
E.5 Control Items
E.5管理項目
FILE HEADER
ファイルヘッダー
| GKSM | N | D | V | H | T | L | I | R | F | RI | ZERO | ONE |
| GKSM| N| D| V| H| T| L| I| R| F| ロードアイランド| ゼロ| 1つ|
All fields in the file header item have fixed length. Numbers are formated according to ISO 6093 - Format F1.
ファイルヘッダーの品目のすべての分野が長さを固定しました。 ISO6093によると、数はformatedされます--形式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
GKSM4バイト含有は2バイトの作者/インストールD8バイト日付(月/日、例えば、79/12/31の年/)のVバージョン番号の名前を含む'GKSM'N40バイトを結びます: ここで説明されたメタファイルはストリング'GKSM'のいくつのバイトがそれぞれの記録の始めに繰り返されるかを指定するバージョンNo.1H2バイト整数を持っています。 可能な値: 0, 1, 2, 3, 4
Aguilar [Page 31]
アギラル[31ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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).
項目データレコード長さのインディケータの項目のタイプのインディケータの分野のLの2バイトの長さのTの2バイトの長さは項目データレコード(項目記述における(r)であるとマークされたすべてのデータに適用する)の各本物のための分野の項目データレコード(項目記述における(i)であるとマークされたすべてのデータに適用される)R2バイトの長さにおける各整数のために分野のI2バイトの長さをさばきます。
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
2バイトのF Possible値: 1, 2. これは(i)か(r)であるとマークされた項目のすべてのデータと、そして、項目タイプと項目データレコードの長さに適用されます: 1: ISO6093 2に従って、すべての数がフォーマットされます: すべての数(ファイルヘッダーを除いた)がロードアイランドの2バイトのPossibleが評価する内部のバイナリフォーマットで格納されます: 1, 2. これは(r)であるとマークされたデータのための数表現です: 1は0.0に同等な2の=の整数のZEROの11バイトの本当の整数と等しいです、ロードアイランドが1.0に同等な2ONE11バイト整数と等しいなら、ロードアイランド=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
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.
想定されます。 形式(c)、(i)、および(r)に加えて、(p)は1組の実数(2r)によって表されたポイントを指示します。形式は既に説明されます。 記法で、そのタイプの値の数を示して、表現でただ一つの手紙は先行します。
{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].}
いくつかの項目仕様に説明しているコメントを追加してあります; これらがGKS Appendix Eの一部でなく、それらが支柱に同封される. 対応するGKS機能[14]の定義で世代の完全な定義とGKSMの品目の解釈をします。
END ITEM
最終品目
| 'GKSM 0' | L |
| 'GKSM0'| L|
Last item of every GKS Metafile. Sets condition for the error.
あらゆるGKS Metafileの最後の項目。 条件を誤りに出します。
Aguilar [Page 32]
アギラル[32ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
CLEAR WORKSTATION
明確なワークステーション
| 'GKSM 1' | L | C |
| 'GKSM1'| L| C|
Requests CLEAR WORKSTATION on all active workstations.
すべてのアクティブなワークステーションでCLEAR WORKSTATIONを要求します。
C(i): clearing control flag
(0 = CONDITIONAL, 1 = ALWAYS)
C(i): 指揮旗をきれいにします。(0=に依存している、1 = いつも)
REDRAW ALL SEGMENTS ON WORKSTATION
ワークステーションの上のすべてのセグメントを描き直してください。
| 'GKSM 3' | L | R |
| 'GKSM3'| L| R|
Requests UPDATE WORKSTATION on all active workstations.
すべてのアクティブなワークステーションでUPDATE WORKSTATIONを要求します。
R(i): regeneration flag
(0 = PERFORM, 1 = SUSPEND)
R(i): 再生旗(=が実行する0、=が中断させる1)
DEFERRAL STATE
延期状態
| 'GKSM 4' | L | D | R |
| 'GKSM4'| L| D| R|
Requests SET DEFERRAL STATE on all active workstations.
すべてのアクティブなワークステーションでSET DEFERRAL STATEを要求します。
D(i): deferral mode
(0 = ASAP, 1 = BNIG, 2 = BNIL, 3 = ASTI)
D(i): 延期モード(0、= できるだけ早く1=BNIG、2がBNIL、3=アスティと等しい、)
R(i): implicit regeneration mode
(0 = ALLOWED, 1 = SUPPRESSED)
R(i): 暗黙の再生モード(=が許容した0、抑圧された1=)
{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.}
この項目は、アプリケーションの必要性に従ってワークステーション能力の使用を最適化するためにGKS機能の視覚効果の発生のコントロールを提供します。
MESSAGE
メッセージ
| 'GKSM 5' | L | N | T |
| 'GKSM5'| L| N| T|
Requests MESSAGE on all active workstations.
N(i): number of characters in string
T(Nc): string with N characters.
すべてのアクティブなワークステーションでMESSAGEを要求します。 N(i): ストリングT(Nc)のキャラクタの数: Nと共にキャラクタを結んでください。
{The message is not part of a metafile output primitives; the
message is only for interpretation by workstation operators.}
メッセージはメタファイルの一部が基関数を出力しました; メッセージがワークステーションオペレータによる解釈のためだけのものであるということではありません。
Aguilar [Page 33]
アギラル[33ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
ESCAPE
エスケープ
| 'GKSM 6' | L | FI | L | M | I | R |
| 'GKSM6'| 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.
FI(i): 機能識別子L(i): データレコードM(i)の整数データの長さ: データレコードI(李)の本当のデータの長さ: 整数データR(さん): 本当のデータ。
{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.}
{この項目は特定の標準的でないエスケープ機能FIの実施を可能にします。 与えられたパラメタがある機能の実行は、GKS州のリストを変更して、幾何学的な出力を起こしてはいけません。}
E.6 Items for Output Primitives
出力基関数のためのE.6の品目
POLYLINE
POLYLINE
| 'GKSM 11' | L | N | P |
| 'GKSM11'| L| N| P|
N(i): number of points of the polyline
P(Np): list of points
N(i): polyline P(Np)の先の数: ポイントのリスト
POLYMARKER
POLYMARKER
| 'GKSM 12' | L | N | P |
| 'GKSM12'| L| N| P|
N(i): number of points
P(Np): list of points.
N(i): ポイントP(Np)の数: ポイントのリスト。
TEXT
テキスト
| 'GKSM 13' | L | P | N | T |
| 'GKSM13'| 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
P(p): キャラクタストリングN(i)の出発点: ストリングT T(Nc)のキャラクタの数: Nと共にISO646のセットからキャラクタを結んでください。
FILL AREA
領域をいっぱいにしてください。
| 'GKSM 14' | L | N | P |
| 'GKSM14'| L| N| P|
N(i): number of points
P(Np): list of points.
N(i): ポイントP(Np)の数: ポイントのリスト。
Aguilar [Page 34]
アギラル[34ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
CELL ARRAY
セルアレイ
| 'GKSM 15' | L | P | Q | R | N | M | CT |
| 'GKSM15'| L| P| Q| R| N| M| コネチカット|
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
P(p)、Q(p)、R(p): 角のポイントの画素の座標はM(i)を整列させます(PとQは機能CELL ARRAYで指定されたポイントPとQのイメージです、そして、Rは別の角です): アレイN(i)の列の数: アレイコネチカット(MNi)の段数: 色のインデックスリストの勢ぞろいは列のそばに列を格納しました。
{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.}
{この項目は、ラスター・イメージをGKSに通過するのを可能にします。 ラスター・イメージは色のインデックスマトリクスコネチカット、および何ポイントPとQも与えられたそのWorld Coordinate位置によって定義されます。}
GENERALIZED DRAWING PRIMITIVE
原始的に描くのを総合します。
| 'GKSM 16' | L | GI | N | P | L | M | I | R |
| 'GKSM16'| 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.
GI(i): GDP識別子N(i): ポイントP(Np)の数: ポイントL(i)のリスト: データレコードM(i)の整数データの長さ: データレコードI(李)の本当のデータの長さ: 整数データR(さん): 本当のデータ。
{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.}
{この項目は追加標準的でない出力基関数を図面のための標準の方法に提供します。 ポイントリストPとデータレコードによると、一般化された描いている原始のGIはIとRに描かれます。}
E.7 Items for Output Primitive Attributes
出力の原始の属性のためのE.7の品目
POLYLINE INDEX
POLYLINEインデックス
| 'GKSM 21' | L | LT |
| 'GKSM21'| L| LT|
LT(i): linetype
LT(i): linetype
Aguilar [Page 35]
アギラル[35ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
LINEWIDTH SCALE FACTOR
線幅スケール要素
| 'GKSM 23' | L | LW |
| 'GKSM23'| L| LW|
LW(r): linewidth scale factor
LW(r): 線幅スケール要素
{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.}
{GKSでは、線幅はGKS変化で影響を受けません。 しかしながら、有効な線幅は名目上の線幅時勢の線が描かれると有効な線幅位取り因数の生成物として計算されます。}
POLYLINE COLOUR INDEX
POLYLINE色のインデックス
| 'GKSM 24' | L | CI |
| 'GKSM24'| L| CI|
CI(i): polyline colour index
CI(i): polyline色のインデックス
POLYMARKER INDEX
POLYMARKERインデックス
| 'GKSM 25' | L | I |
| 'GKSM25'| L| I|
I(i): polymarker index
I(i): polymarkerインデックス
MARKER TYPE
マーカータイプ
| 'GKSM 26' | L | MT |
| 'GKSM26'| L| MT|
MT(i): marker type
MT(i): マーカータイプ
MARKER SIZE SCALE FACTOR
マーカーサイズスケール要素
| 'GKSM 27' | L | MS |
| 'GKSM27'| L| さん|
MS(r): marker size scale factor
MS(r): マーカーサイズスケール要素
{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.}
{GKSでは、マーカーサイズはGKS変化で影響を受けません。 しかしながら、有効なマーカーサイズは名目上のマーカーサイズ回数のマーカーが描かれると有効なマーカーサイズ位取り因数の製品として計算されます。}
POLYMARKER COLOUR INDEX
POLYMARKER色のインデックス
| 'GKSM 28' | L | CI |
| 'GKSM28'| L| CI|
CI(i): polymarker colour index
CI(i): polymarker色のインデックス
Aguilar [Page 36]
アギラル[36ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
TEXT INDEX
テキストインデックス
| 'GKSM 29' | L | I |
| 'GKSM29'| L| I|
I(i): text index
I(i): テキストインデックス
TEXT FONT AND PRECISION
テキスト字体AND精度
| 'GKSM 30' | L | F | P |
| 'GKSM30'| L| F| P|
F(i): text font
P(i): text precision
(0 = STRING, 1 = CHAR, 2 = STROKE)
F(i): テキスト字体P(i): テキスト精度(0=ストリング、1=炭、2=ストローク)
CHARACTER EXPANSION FACTOR
キャラクタ膨張係数
| 'GKSM 31' | L | CEF |
| 'GKSM31'| L| CEF|
CEF(r): character expansion factor
CEF(r): キャラクタ膨張係数
{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.}
{この項目はキャラクタ本体の幅/高さの操作を許します。 キャラクタ本体の幅はCEF要素によってスケーリングされます。}
CHARACTER SPACING
文字間隔
| 'GKSM 32' | L | CS |
| 'GKSM32'| L| Cs|
CS(r): character spacing
Cs(r): 文字間隔
TEXT COLOUR INDEX
テキスト色のインデックス
| 'GKSM 33' | L | CI |
| 'GKSM33'| L| CI|
CI(i): text colour index
CI(i): テキスト色のインデックス
Aguilar [Page 37]
アギラル[37ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
CHARACTER VECTORS
キャラクタベクトル
| 'GKSM 34' | L | CH | CW |
| 'GKSM34'| L| CH| CW|
CH(2r): character height vector
CW(2r): character width vector
CH(2r): キャラクタ高さのベクトルCW(2r): キャラクタ幅のベクトル
Note: These vectors are the height and width vectors described
in 4.4.5 of [14].
以下に注意してください。 これらのベクトルは高さです、そして、幅のベクトルは[14]について4.4で.5について説明しました。
{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 |
| 'GKSM35'| L| P|
P(i): text path
(0 = LEFT, 1 = RIGHT, 2 = UP, 3 = DOWN)
P(i): テキスト経路(0は左と等しく、2=が上にある1つの=権利が3=下です)
TEXT ALIGNMENT
テキスト整列
| 'GKSM 36' | L | H | V |
| 'GKSM36'| 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)
H(i): 水平な字並び(CENTRE、LEFT、0=NORMAL、1=2=3はRIGHTと等しい)V(i): 垂直な字並び(0=標準、1つの=先端、2=キャップ、3=.5、4=ベース、5=下部)
FILL AREA INDEX
中詰め領域インデックス
| 'GKSM 37' | L | I |
| 'GKSM37'| L| I|
I(i): fill area index
I(i): 中詰め領域インデックス
FILL AREA INTERIOR STYLE
領域の内部のスタイルをいっぱいにしてください。
| 'GKSM 38' | L | S |
| 'GKSM38'| L| S|
S(i): fill area interior style
(0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH)
S(i): 領域の内部のスタイルをいっぱいにしてください。(0=くぼみ、1つの=固体、2=パターン、3=ハッチ)
Aguilar [Page 38]
アギラル[38ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
FILL AREA STYLE INDEX
中詰め領域スタイルインデックス
| 'GKSM 39' | L | SI |
| 'GKSM39'| L| SI|
SI(i): fill area style index
SI(i): 中詰め領域スタイルインデックス
FILL AREA COLOUR INDEX
中詰め領域色のインデックス
| 'GKSM 40' | L | CI |
| 'GKSM40'| L| CI|
CI(i): fill area colour index
CI(i): 中詰め領域色のインデックス
PATTERN SIZE
パターンサイズ
| 'GKSM 41' | L | PW | PH |
| 'GKSM41'| L| PW| PH|
PW(2r): pattern width vector
PH(2r): pattern height vector
PW(2r): 幅のベクトルPH(2r)を型に基づいて作ってください: パターン高さのベクトル
{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.}
{領域をいっぱいにするための1つの方法がカラーセルのパターンと共にあります。 そのようなパターンは寸法がPWとPHによって与えられている状態でパターン長方形に写像される色のインデックスリストの勢ぞろいによって定義されます。}
PATTERN REFERENCE POINT
参考見本ポイント
| 'GKSM 42' | L | P |
| 'GKSM42'| L| P|
P(p): reference point
P(p): 基準点
{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.}
{領域をいっぱいにするための1つの方法がカラーセルのパターンと共にあります。 そのようなパターンは左下隅がPによって与えられるパターン長方形に写像される色のインデックスリストの勢ぞろいによって定義されます。}
Aguilar [Page 39]
アギラル[39ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
ASPECT SOURCE FLAGS
局面のソース旗
| 'GKSM 43' | L | F |
| 'GKSM43'| L| F|
F(13i): aspect source flags
(0 = BUNDLED, 1 = INDIVIDUAL)
F(13i): 局面のソース旗(=が束ねた0、1人の=個人)
{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 |
| 'GKSM44'| L| P|
P(i): pick identifier
P(i): 識別子を選んでください。
E.8 Items for Workstation Attributes
ワークステーション属性のためのE.8の品目
POLYLINE REPRESENTATION
POLYLINE表現
| 'GKSM 51' | L | I | LT | LW | CI |
| 'GKSM51'| L| I| LT| LW| CI|
I(i): polyline index
LT(i): linetype number
LW(r): linewidth scale factor
CI(i): polyline colour index
I(i): polylineインデックスLT(i): linetype番号LW(r): 線幅スケール要素CI(i): polyline色のインデックス
POLYMARKER REPRESENTATION
POLYMARKER表現
| 'GKSM 52' | L | I | MT | MS | CI |
| 'GKSM52'| L| I| MT| さん| CI|
I(i): polymarker index
MT(i): marker type
MS(r): marker size scale factor
CI(i): polymarker colour index
I(i): polymarkerインデックスMT(i): マーカータイプMS(r): マーカーサイズスケール要素CI(i): polymarker色のインデックス
Aguilar [Page 40]
アギラル[40ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
TEXT REPRESENTATION
テキスト表現
| 'GKSM 53' | L | I | F | P | CEF | CS | CI |
| 'GKSM53'| 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
I(i): テキストインデックスF(i): テキスト字体P(i): テキスト精度(CHAR、0=STRING、1=2はSTROKEと等しい)CEF(r): キャラクタ膨張係数CS(r): 文字間隔CI(i): テキスト色のインデックス
FILL AREA REPRESENTATION
領域表現をいっぱいにしてください。
| 'GKSM 54' | L | I | S | SI | CI |
| 'GKSM54'| 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
I(i): 領域インデックスS(i)をいっぱいにしてください: 領域の内部のスタイル(PATTERN、SOLID、0=HOLLOW、1=2=3はHATCHと等しい)SI(i)をいっぱいにしてください: 領域スタイルインデックスCI(i)をいっぱいにしてください: 中詰め領域色のインデックス
PATTERN REPRESENTATION
パターン表現
| 'GKSM 55' | L | I | N | M | CT |
| 'GKSM55'| L| I| N| M| コネチカット|
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
I(i): インデックスN(i)を型に基づいて作ってください: アレイ*M(i)の段数: アレイコネチカット(MNi)の列の数: 色のインデックスリストのテーブルは列のそばに列を格納します。
{* The ANSI document reads "area" instead of "array".}
*ANSIドキュメントは「アレイ」の代わりに「領域」を読みます。
{One style for filling areas is with a pattern of color cells.
Such a pattern is defined by a pattern representation.}
{領域をいっぱいにするための1つの方法がカラーセルのパターンと共にあります。 そのようなパターンはパターン表現で定義されます。}
COLOUR REPRESENTATION
色の表現
| 'GKSM 56' | L | CI | RGB |
| 'GKSM56'| L| CI| RGB|
CI(i): colour index
RGB(3r): red, green, blue intensities
CI(i): インデックスRGB(3r)を着色してください: 赤くて、緑色の、そして、青い強度
Aguilar [Page 41]
アギラル[41ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
E.9 Items for Transformations
変化のためのE.9の品目
CLIPPING RECTANGLE
切り取り長方形
| 'GKSM 61' | L | C |
| 'GKSM61'| L| C|
C(4r): limits of clipping rectangle (XMIN, XMAX, YMIN, YMAX)
C(4r): 切り取り長方形の限界(XMIN、XMAX、YMIN、YMAX)
WORKSTATION WINDOW
ワークステーションの窓
| 'GKSM 71' | L | W |
| 'GKSM71'| L| W|
W(4r): limits of workstation window (XMIN, XMAX, YMIN, YMAX)
W(4r): ワークステーションの窓の限界(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).}
GKSはNDCスペース(ワークステーションの窓)の長方形をデバイス座標スペース(ワークステーションビューポート)の長方形に写像するワークステーション変化を含んでいます。
WORKSTATION VIEWPORT
ワークステーションビューポート
| 'GKSM 72' | L | V |
| 'GKSM72'| L| V|
V(4r): limits of workstation viewport (XMIN, XMAX, YMIN, YMAX)
V(4r): ワークステーションビューポートの限界(XMIN、XMAX、YMIN、YMAX)
E.10 Items for Segment Manipulation
セグメント操作のためのE.10の品目
CREATE SEGMENT
セグメントを作成してください。
| 'GKSM 81' | L | S |
| 'GKSM81'| L| S|
S(i): segment name
S(i): セグメント名
CLOSE SEGMENT
セグメントを閉じてください。
| 'GKSM 82' | L |
| 'GKSM82'| L|
indicates end of segment
セグメントの終わりを示します。
RENAME SEGMENT
セグメントを改名してください。
| 'GKSM 83' | L | SO | SN |
| 'GKSM83'| L| そのように| SN|
SO(i): old segment name
SN(i): new segment name
そのように、(i): 古いセグメント名SN(i): 新しいセグメント名
Aguilar [Page 42]
アギラル[42ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
DELETE SEGMENT
セグメントを削除してください。
| 'GKSM 84' | L | S |
| 'GKSM84'| L| S|
S(i): segment name
S(i): セグメント名
E.11 Items for Segment Attributes
セグメント属性のためのE.11の品目
SET SEGMENT TRANSFORMATION
セグメント変化を設定してください。
| 'GKSM 91' | L | S | M |
| 'GKSM91'| 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
S(i): セグメント名M(6r): 2D線形変換[9]M11M12M13M21M22M23を表す3×3マトリクスの変換行列の上側の、そして、センターの列
{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.}
{これは要素が示したマトリクスによるANSI X3.124 Jan. 5 1984ドキュメントと異なっています。 私たちは、そのようなドキュメントには誤りがあると信じています。}
SET VISIBILITY
目に見えることを設定してください。
| 'GKSM 92' | L | S | V |
| 'GKSM92'| L| S| V|
S(i): segment name
V(i): visibility
(0 = VISIBLE, 1 = INVISIBLE)
S(i): セグメント名V(i): 目に見えること(目に見える0=、目に見えない1=)
SET HIGHLIGHTING
ハイライトを設定してください。
| 'GKSM 93' | L | S | H |
| 'GKSM93'| L| S| H|
S(i): segment name
H(i): highlighting
(0 = NORMAL, 1 = HIGHLIGHTED)
S(i): セグメント名H(i): ハイライト(0=標準、=が強調した1)
SET SEGMENT PRIORITY
セグメント優先権を設定してください。
| 'GKSM 94' | L | S | P |
| 'GKSM94'| L| S| P|
S(i): segment name
P(r): segment priority
S(i): セグメント名P(r): セグメント優先権
Aguilar [Page 43]
アギラル[43ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
SET DETECTABILITY
検出度を設定してください。
| 'GKSM 95' | L | S | D |
| 'GKSM95'| L| S| D|
S(i): segment name
D(i): detectability
(0 = UNDETECTABLE, 1 = DETECTABLE)
S(i): セグメント名D(i): 検出度(検知されなくて、1=検出可能な0=)
E.12 User Items
E.12ユーザの品目
USER ITEM
ユーザ項目
| 'GKSMXXX' | L | D |
| 'GKSMXXX'| L| D|
XXX > 100
D: user data (L bytes)
XXX>100D: 利用者データ(Lバイト)
{The PIGCF level U items are encoded as GKSM USER ITEM elements
so that a PIGCF file will conform to the GKSM metafile
specification.}
PIGCFの平らなUの品目は、PIGCFファイルがGKSMメタファイル仕様に一致するように、GKSM USER ITEM要素としてコード化されます。
Aguilar [Page 44]
アギラル[44ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
APPENDIX B
付録B
Example of PIGCF Use in Conferencing
会議におけるPIGCF使用に関する例
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.
このセクションはオーディオのグラフィックス会議交換で提案されたPIGCFグラフィカルな部品を例証する例を提示します。 私たちは会議交換のグラフィカルな部分だけを提示します。(スピーチは実際に交換に補われるでしょう)。 簡潔のために、例は会議セットアップが必要とするすべてのパラメタ交渉を含んでいません。
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.
例は海軍指令室と海軍特別委員会とのオンラインオーディオのグラフィックス会議に関するものです。 見せられたPIGCFの品目はただ一つのトランスミッションの流れに属しません。 彼らが属す流れはそれらを送信するステーションのそばで決定しています、そして、送信機の識別は下のレベル通信プロトコルに属します。 私たちはこのPIGCFの例に2進のものよりむしろキャラクタコード化を使用します。 私たちはまさしくこの例でbatchedされることができた項目の可能なグループのいくつかを例証します。 例の陰謀は以下の通りです。
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:
今、私たちは項目が交換したPIGCFを記載しかけます。 センターは、グラフィカルな情報を交換するために基本の表現パラメタを設定するFILE HEADERの品目による会議のグラフィカルなセットアップに着手します。 E.5[14]との定義に従って、この項目を解釈できます。 この例のための最も重要なパラメタ選択は以下の通りです。
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
i) 項目が項目ヘッダーの識別分野の"GKSM"ストリングの0文字を含んでいる、ii) PIGCFを含む項目タイプインディケータ分野
Aguilar [Page 45]
アギラル[45ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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.
商品番号は各個条iii)の3バイト長です。 6バイト長整数は4バイト長であり、本物はiv)です。 項目データレコード長さのインディケータは2バイト長です。
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.
私たちはPIGCF仕様フィールド長と前述のフィールド長設定に従うつもりです。 「しかしながら、私たちが以前後に、あるスペースを加えるつもりである、」|「読みやすさを改良する分離符。」 また、あらゆる項目が名前で先行されて、識別を助けるでしょう。
FILE HEADER:
ヘッダーをファイルしてください:
| GKSM | center | 84/11/10 | 1 | 0 | 3 | 2 | 4 | 6 | 1 | 1
| | |
| GKSM| センター| 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 |
ワークステーションの窓: | 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 |
窓を設定してください: | 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.
センターは地方のNDCビューポートの位置を知らせますが、しかしながら、他の相談相手は同じ変化のための異なったNDCビューポートを選ぶことができますが、それらのワークステーションの窓は会議のものを含んでいるはずです。 すべてのシステムが会議を記録します: 世界ウィンドウ、NDCビューポート、およびワークステーション未亡人。
SET VIEWPORT: | 135 | 28 | 0.0 0.5 0.0 0.375 |
ビューポートを設定してください: | 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 |
ライブラリを思い出してください: | 139 | 9 | caribbean| 物を表示してください: | 128 | 11 | 海岸_線| ライブラリを思い出してください: | 139 | 10 | タスク_ユニット|
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
センターはタスク_ユニット図書館に特別委員会の1つを例示しかけます。 いくつかのライブラリ物を思い出して、後で変化を物に適用することによって、これをします。 セットウィンドウ、セットビューポート、およびリコールライブラリがアップデートに属すので
Aguilar [Page 46]
アギラル[46ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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.
-2を分類してください、そして、表示物がアップデートGroup-1から入られるまで、それらはbatchedされることができます。 表示物が作り出されるまで、以下と共にリコールライブラリをbatchedされることができる秒に具体化を始めてください。 例の残りはbatchedされることができる項目系列に関する、より多くのケースを含んでいます。 しかしながら、簡潔に関して、私たちはそれらをもう示しません。
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 |
具体化を始めてください: | 124 | 15 | 米国_構成| 物を表示してください: | 128 | 15 | 米国_構成| 物を変えてください: | 126 | 55 | 15 | 米国_構成| 0.1 0.0 0.0 0.0 0.1 0.0 | 物を変えてください: | 126 | 55 | 15 | 米国_構成| 0.1 0.0 0.312 0.0 0.1 0.078 | 具体化を終わらせてください: | 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 |
具体化を始めてください: | 124 | 13 | 米国の_の新しい_ジャージー| 物を表示してください: | 128 | 13 | 米国の_の新しい_ジャージー| 物を変えてください: | 126 | 53 | 13 | 米国の_の新しい_ジャージー| 0.1 0.0 0.0 0.0 0.1 0.0 | 物を変えてください: | 126 | 53 | 13 | 米国の_の新しい_ジャージー| 0.1 0.0 0.312 0.0 0.1 0.093 | 具体化を終わらせてください: | 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.
次に、新しいアイコンをスクリーンに引き込むことに備えて2のためのセンター・セット値は原始の属性を出力しました。 私たちは、会議セットアップの結果、他のすべての属性にデフォルト値を割り当ててあると思います。
POLYLINE INDEX: | 21 | 4 | 20 | POLYLINE COLOUR INDEX: | 24 | 4 | 200 |
POLYLINEは索引をつけます: | 21 | 4 | 20 | POLYLINEはインデックスを着色します: | 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 |
定義を始めてください: | 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 | 定義を終わらせてください: | 121 | 8 | 目撃例|
Then the unidentified vessel "sighting" is scaled and placed at the sighting site.
次に、不審船「目撃例」は、目撃例サイトにスケーリングされて、置かれます。
Aguilar [Page 47]
アギラル[47ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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 |
具体化を始めてください: | 124 | 8 | 目撃例| 物を変えてください: | 126 | 48 | 8 | 目撃例| 0.2 0.0 0.0 0.0 0.2 0.0 | 物を変えてください: | 126 | 48 | 8 | 目撃例| 0.1 0.0 0.156 0.0 0.1 0.016 | 具体化を終わらせてください: | 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 |
ポインタトラッキング: | 137 | 16 | 0 | 0.39 0.032 | ポインタトラッキング: | 137 | 16 | 0 | 0.388 0.035 | ポインタトラッキング: | 137 | 16 | 0 | 0.388 0.039 | ポインタトラッキング: | 137 | 16 | 0 | 0.386 0.04 |
from one of the platforms:
プラットホームの1つから:
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 |
ポインタトラッキング: | 137 | 16 | 0 | 0.22 0.016 | ポインタトラッキング: | 137 | 16 | 0 | 0.222 0.159 | ポインタトラッキング: | 137 | 16 | 0 | 0.233 0.157 | ポインタトラッキング: | 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 |
ポインタトラッキング: | 137 | 16 | 1 | 0.388 0.038 | ポインタトラッキング: | 137 | 16 | 1 | 0.386 0.038 | ポインタトラッキング: | 137 | 16 | 1 | 0.386 0.052 | ポインタトラッキング: | 137 | 16 | 1 | 0.375 0.078 | ポインタトラッキング: | 137 | 16 | 1 | 0.369 0.105 | ポインタトラッキング: | 137 | 16 | 1 | 0.361 0.125 | ポインタトラッキング: | 137 | 16 | 1 | 0.352 0.144 | ポインタトラッキング: | 137 | 16 | 1 | 0.351 0.156 | ポインタトラッキング: | 137 | 16 | 1 | 0.35 0.16 |
A platform moves the two US ship icons to interception positions.
プラットホームは2つの米国船のアイコンを妨害位置に動かします。
Aguilar [Page 48]
アギラル[48ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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 |
物を変えてください: | 126 | 55 | 15 | 米国_構成| 1.0 0.0 0.16 0.0 1.0 -0.046 | 物を変えてください: | 126 | 53 | 13 | 米国の_の新しい_ジャージー| 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 |
ワークステーションの窓: | 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.
2個のプラットホームが、各船の中心に置かれた円形の輪ゴムを使用することでそれらの砲撃距離を示します。 各プラットホームに関しては、私たちは、エコーフィードバックが示されるのを最初に、エコー基準点と次に、2に示します。 多くのフィードバックポイントが通常あるでしょう。
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 |
輪ゴム: | 138 | 10 | 0 | 0.335 0.125 | 輪ゴム: | 138 | 10 | 3 | 0.35 0.128 | 輪ゴム: | 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 |
輪ゴム: | 138 | 10 | 0 | 0.384 0.13 | 輪ゴム: | 138 | 10 | 3 | 0.367 0.128 | 輪ゴム: | 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 |
ワークステーションの窓: | 71 | 24 | 0.0 0.5 0.0 0.375 |
The center terminates the conference
センターは会議を終えます。
END ITEM: | 0 | 0 |
最終品目: | 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.
会議の終わりに、最終的な絵はスクリーンで目に見えたままで残っています。 さらに、PIGCFの品目は、必要なら、会議の話し合いを再生するために全体として記録されるでしょう。 また、マルチメディアメッセージの一部として会議記録を他の位置に送ることができました。
Aguilar [Page 49]
アギラル[49ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
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.
[1]J.D.日、H.Zimmermann、「OSI規範モデル」、IEEEの議事、V71、N12。 1983年12月、pp1334-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.
[2]W.PferdとL.A.PeraltaとF.X.プレンダガスト、「インタラクティブグラフィックス電子会議」、IEEEコンピュータ対12、N11。 1979年11月、pp62-72。
[3] K. S. Sarin, "Interactive On-Line Conferences", Ph.D. Diss.
MIT, Dept. of EE and CS, 1984.
[3] 博士号は、K.S.サリン、「対話的なオンラインコンファレンス」とけなします。 MIT、EEと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.
[4] S.ランドル、「共有されたグラフィックワークスペース:」 「Teleconference EnvironmentのインタラクティブData Sharing」、Proceedings CompCon82Fall、IEEEコンピュータSociety、pp535-542。
[5] G. Heffron, "Teleconferencing Comes of Age", IEEE Spectrum,
Oct. 1984, pp 61-66, pp 61-66.
[5] G.ヘフロン、「電子会議は成年に達する」IEEE Spectrum、1984年10月、pp61-66、pp61-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.
[6] R.W.ハフとR.R.Panko、「電子会議システム:」 「芸術の州SurveyとPreliminary Analysis」、SRIインターナショナル、メンローパークカリフォルニア、SRIは3735を映し出して、4月は1977です。
[7] C. W. Kelly III, "An Enhanced Presence Video Teleconferencing
System" Proc. CompCon 1982, Sept. 20-23 Washington D.C., pp
544-551.
[7] C.W.ケリーIII、「高められた存在ビデオ遠隔会議システム」Proc。 CompCon1982年9月20日-23ワシントンDC、pp544-551。
[8] J. Vanglian, "Private Communication", Comments on the
suitability of videotex for on-line graphical communication.
[8]J.Vanglian、「私信」、オンライングラフィカルなコミュニケーションのためのビデオテックスの適合のComments。
[9] ANSI Technical Committee X3H, "Draft Proposal: Virtual Device
Metafile", X3.122, X3 Secretariat, CBEMA, Washington, D.C.
[9] ANSI専門委員会X3H、「提案を作成してください」 「仮想の装置メタファイル」、X3.122、X3事務局、CBEMA、ワシントンDC
[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.
[10]規格委員会X3H3、「バーチャルデバイスインターフェース」、X3--コンピュータ事務機器製造業者協会、ワシントンDCからの情報処理システム、働くドキュメント、空いている1985年1月2日
[11] E. Van Deusen, "Graphics Standards Handbook", CC Exchange 1984,
P.O. Box 1251, Laguna Beach, CA 92652.
[11] 「グラフィックス標準ハンドブック」というE.バンDeusenは交換1984、私書箱1251にラグナビーチ、カリフォルニア 92652をCCします。
[12] J. D. Foley and A. Van Dam, "Fundamentals of Interactive
Computer Graphics", Addison-Wesley, 1982.
[12] J.D.フォーリーとA.ヴァンダム、「対話型コンピュータ図形の原理」、アディソン-ウエスリー、1982
Aguilar [Page 50]
アギラル[50ページ]
RFC 965 December 1985 A Format for a Graphical Communication Protocol
グラフィカルな通信プロトコルのための1形式あたりのRFC965 1985年12月
[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.
[13]規格委員会X3H3、「GKS--3D拡大」、X3--コンピュータ事務機器製造業者協会からの情報処理システム、働くドキュメント、空いている1984年11月16日、ワシントンDC
[14] ANSI Technical Committee X3H3, "Draft Proposal: Graphical
Kernel System", X3.124, X3 Secretariat, CBEMA, Washington, D.C.
[14] ANSI専門委員会X3H3、「提案を作成してください」 「グラフィカルなカーネルシステム」、X3.124、X3事務局、CBEMA、ワシントンDC
[15] G. Enderle, K. Kansy, and G. Pfaff, "Computer Graphics
Programming", Springer-Verlag, 1984.
[15] G.Enderle、K.KansyとG.パーフ、「コンピュータグラフィックスプログラミング」、追出石-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.
[16] 国際標準化機構、「情報処理--、数値の表現が情報交換のためにぴったりした結ぶ、」、ISO/DIS6093.2、ISO/TC97、1984年1月19日。 ANSI、ニューヨーク、ニューヨークから、利用可能です。
Aguilar [Page 51]
アギラル[51ページ]
一覧
スポンサーリンク
