RFC493 日本語訳
0493 GRAPHICS PROTOCOL. J.C. Michener, I.W. Cotton, K.C. Kelley, D.E.Liddle, E. Meyer. April 1973. (Format: TXT=67843, PDF=1563891 bytes) (Obsoletes RFC0292) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Michener
Request for Comments: 493 MAC
NIC: 15358 I. Cotton
References: 282, 258 MITRE
Obsoletes: 292 K. Kelley
U. of Ill.
D. Liddle
Ownes Ill.
E. Meyer
MAC
コメントを求めるワーキンググループJ.ミッチェナー要求をネットワークでつないでください: 493 Mac NIC: 15358 I.綿の参照: 282 258斜め継ぎは以下を時代遅れにします。 292 イリノイ州のK.ケリーU. D。 Liddle Ownesイリノイ州 E。 マイヤーMAC
GRAPHICS PROTOCOL
グラフィックスプロトコル
Introduction
序論
This document reflects opinions expressed and decisions reached at the second meeting of the Network Graphics Group, held at the Stanford Artificial Intelligence Laboratory in late November 1971. It describes part of a proposed Network Standard Graphics Protocol for transmitting graphics data within the ARPA network. The particular aspects of the protocol covered in this document relate to the form and content of graphics information sent from a source of graphical information (an application program, say, in the "Serving Host") to a display package for output to a graphics console (at the "Using Host"). This will take the form of a sequence of 8-bit bytes, and will be called the graphics output byte stream.
このドキュメントは11月の1971下旬にスタンフォード大学人工知能研究所で持たれていたNetwork Graphics Groupの2番目のミーティングで達した述べられた意見と決定を反映します。 それは、ARPAネットワークの中でグラフィックスデータを送るために提案されたNetwork Standard Graphicsプロトコルの一部について説明します。 本書ではカバーされたプロトコルの特定の局面はグラフィカルな情報(たとえば「給仕のホスト」のアプリケーション・プログラム)の源から出力のための表示パッケージに送られたグラフィックス情報のフォームと内容にグラフィックスコンソール(「使用しているホスト」の)に関連します。 これは、8ビットのバイトの系列の形を取って、グラフィックス出力バイト・ストリームと呼ばれるでしょう。
This document is intended to serve as a basis for discussion and for experimentation over the network. This document does not include form or content of graphics input (data sent from the Using Host to the Serving Host) nor does it cover how the connection is established between the hosts. A proposal for the former will be generated eventually by this committee; the latter is the job of the Connection Committee (of the Network Graphics Group).
このドキュメントは議論の叩き台となることを意図してネットワークの上の実験のためのものです。 グラフィックスの内容は(Using HostからServing Hostに送られたデータ)を入力しました、そして、このドキュメントがフォームを含んでいないか、またはそれは接続がホストの間でどう確立されるかを覆っていません。 前者のための提案は結局、この委員会によって発生するでしょう。 後者はConnection Committee(Network Graphics Groupの)の仕事です。
This RFC describes the commands which are available in the protocol in terms of the effect they would have at the receiving (Using Host) end. Clearly, some subroutine package is desirable at the Serving Host for use by applications in transmitting graphics data, but on this topic this RFC does not intend to comment.
このRFCはそれらが受信(Hostを使用する)終わりに持っている効果でプロトコルで利用可能なコマンドについて説明します。 明確に、アプリケーションによる使用には、何らかのサブルーチンパッケージがServing Hostでグラフィックスデータを送るのにおいて望ましいのですが、この話題に関して、このRFCはコメントしないつもりです。
It may be observed by the reader that no facility is specified in this protocol allowing the Using Host to report logical errors in the graphics output byte stream to the Serving Host. Such a facility would have to be integrated with the graphics input byte stream, since it involves most of the problems related to synchrony of independent hosts.
施設が全くUsing Hostがグラフィックス出力バイト・ストリームで論理的な誤りをServing Hostに報告できるこのプロトコルで指定されないのが読者によって観測されるかもしれません。 そのような施設はグラフィックス入力バイト・ストリームについて統合していなければならないでしょう、独立しているホストの同期に関連する問題の大部分にかかわるので。
Michener, et. al. [Page 1] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [1ページ]RFC493グラフィックスプロトコル1973年4月26日
Background
バックグラウンド
The reader should probably peruse RFC 282: "Graphics Meeting Report" by Mike Padlipsky to obtain some of the framework surrounding this discussion of network graphics. Also it might be valuable to make note of the model described in RFC 285: "Network Graphics" by Donald Huff.
読者はたぶんRFC282を熟読するべきです: ネットワークグラフィックスのこの議論を囲む枠組みのいくつかを得るマイクPadlipskyによる「グラフィックスMeeting Report。」 また、RFC285でモデルの注意について説明させるのも貴重であるかもしれません: ドナルドが「ネットワークグラフィックス」は立腹します。
Levels and Ground Rules Pertaining Thereto
それに加えて関係するレベルと基本規則
Functions within the graphics protocol will be classified into a number of levels depending partly on how difficult it is to implement those functions. It is intended that any host which claims to implement the functions of level N must implement all lower levels as well. Thus, it is envisioned that sites will implement levels inclemently. Implementations will be improved as a continuing process to include more and more functions, and it is intended that each implementation will be able to identify its own level to a graphics protocol at a remote site which is requesting a graphics interchange. A side result is that each site will be able to determine its own priorities in committing programmers to the graphics protocol as opposed to other efforts.
グラフィックスプロトコルの中の機能はそれらの機能を実行するのが一部どれくらい難しいか依存する多くのレベルに分類されるでしょう。 レベルNの関数が道具へのそれのクレームを実行しなければならないどんなホストもまた、レベルをすべて下げることを意図します。 したがって、思い描かれて、そのサイトが険悪にレベルを実行するということです。 実現はますます多くの機能を含むように継続する過程として改良されるでしょう、そして、それぞれの実現がグラフィックス置き換えを要求しているリモートサイトのグラフィックスプロトコルにそれ自身のレベルを特定できることを意図します。 サイド結果はそれぞれのサイトが他の努力と対照的にグラフィックスプロトコルにプログラマを遂行する際にそれ自身のプライオリティを決定できるということです。
It is also our intention that implementation of level N will require no knowledge of level N+1. Thus a site can implement a level in the (reasonably) firm knowledge that no changes at higher levels will alter the level implemented. At some time it may be decided by the Network Graphics Group to redefine a level which has previously been firmed up. It is not our intention that this shall happen but one must recognize that the proposed Graphics Protocol is experimental and may have to be changed.
また、それはレベルNの実現が+1にレベルNに関する知識を全く必要としないという私たちの意志です。 したがって、サイトは、より高いレベルにおけるどんな変化も実行されたレベルを変更しないという(合理的に)堅い知識のレベルを実行できます。 いつか、レベルを再定義するためにどれが以前に堅かったかとNetwork Graphics Groupによって決められるかもしれません。 それがこれが起こるものとするという私たちの意志ではありませんが、提案されたGraphicsプロトコルが実験していると認めなければならなくて、変えなければならないかもしれません。
One further ground rule: a stream of commands and data which is valid at a given level, K, shall produce "identical" results on any interpreter of level K or higher. By this we mean that as long as the commands and data take advantage only of strictly defined operations, similar pictures should result. Aspects of the protocol which are not strictly defined (at this time) include character size, character position relative to the beam, how control characters in text output affect the terminal and what happens when the beam is moved or a line drawn outside of the logical screen boundary. This rule forces upwards compatibility, so that an application written using features of a low numbered level will still work at sites which have moved on to implement higher levels. Additionally, any aspects
さらなる1つの基本規則: 与えられたレベルで有効なコマンドとデータのストリーム(K)は「同じ」結果をレベルKのどんなインタプリタか、より高く生むものとします。 これで、私たちは、コマンドとデータが利点がかかる限り、単に厳密に定義されているのにおいて、操作、同様の絵が結果として生じるはずであると言っています。 (このとき)厳密に定義されないプロトコルの局面はキャラクタサイズを含んでいます、ビームに比例した欄、テキスト出力における制御文字がどう論理的なスクリーン境界の外に描かれた端末とビームが動かされるとき起こることか線に影響するか。 この規則は上向きに互換性を強制します、それでも、低番号付のレベルの特徴を使用することで書かれたアプリケーションが、より高いレベルを実行するために移動したサイトで動作するように。 さらに、どんな局面
Michener, et. al. [Page 2] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [2ページ]RFC493グラフィックスプロトコル1973年4月26日
of this protocol which are explicitly "left unspecified" in the detailed operations descriptions below shall be explicitly specified in any public description of an actual implementation.
このプロトコルでは、どれが以下から詳細な操作記述で明らかに「不特定のままにされるか」は実際の実現のどんな公共の記述でも明らかに指定されるものとします。
We now describe the framework which will be common to all levels.
私たちは現在、すべてのレベルに共通になる枠組みについて説明します。
Basic Data Forms
基礎データフォーム
Information in the Network Standard Graphics Protocol will be expressed as a sequence of 8-bit bytes. A command will consist of a command byte followed by zero or more arguments. The same command byte will always take the same number of arguments in the same form. The length of each argument may be fixed or variable depending on the argument.
Network Standard Graphicsプロトコルの情報は8ビットのバイトの系列として言い表されるでしょう。 コマンドはゼロか、より多くの議論があとに続いたコマンドバイトから成るでしょう。 同じコマンドバイトはいつも同じフォームの同じ引数の数を取るでしょう。 議論によって、それぞれの議論の長さは、固定されているか、または可変であるかもしれません。
A simple type of argument is a "value", which is a 8-bit integer. Another type of argument is a "string" which is a count followed by (count) number of 8-bit bytes. If the count is between 0 and 127, it is sent in a single byte. If the count is between 128 and 2**15-1 (**means exponentiation), it is sent in two bytes with the high order bit of the first byte set to one. The first byte contains the seven high order bits of the number and the second byte contains the eight low order bits. A string is the only type of argument of a command which can vary in length. For example, whenever a command has optional arguments, they will be represented inside of a string.
純真なタイプの議論は8ビットの整数である「値」です。 別のタイプの議論は8ビットのバイトの(カウント)番号がいうことになったカウントである「ストリング」です。 カウントが0〜127であるなら、それは1バイト送られます。 カウントが128〜2**15-1(**は羃法を意味する)であるなら、それは最初のバイトセットの高位のビットで1つに2バイト送られます。 最初のバイトは数の7高位のビットを含んでいます、そして、2番目のバイトは8下位のビットを含んでいます。 五弦は長さにおいて異なることができる唯一のタイプのコマンドの議論です。 例えば、コマンドに任意の議論があるときはいつも、それらはストリングの表された内部になるでしょう。
Coordinate data engendered considerable discussion at the second Network Graphics Group meeting. It was decided that a two- dimensional Logical Coordinate System was required, and each interpreter for the graphic command byte stream would be responsible for mapping this coordinate system to physical device coordinates. It was decided that data in the logical coordinate system would be in twos-complement notation, that it would be fractional, that each edge of the screen would have unit length, and that the origin would correspond to the center of the screen on the output device. The vertical (horizontal) edges of the screen of the output device correspond to the lines X (Y) = -1/2 or X=+1/2-e where e is a small positive number determined by the precision of the fractional data. Particularly the points (-1/2, -1/2) (-1/2, 1/2-e), (1/2-e, -1/2) and (1/2-e, 1/2-e) shall be visible points at the corners of the logical screen. (In the case of a non-square display surface, the implementer may take his own decision. Thus we shall say that the Logical Coordinate System contains points whose coordinates range from -1/2 to a little less than +1/2.
座標データは2番目のNetwork Graphics Groupミーティングでかなりの議論を生み出しました。 2の次元Logical Coordinate Systemが必要であったと決められて、グラフィックコマンドバイト・ストリームのためのそれぞれのインタプリタはこの座標系をフィジカル・デバイス座標に写像するのに責任があるでしょう。 論理的な座標系のデータが2補数の記法であって、それが断片的であるだろう、スクリーンの各縁にはユニット長があって、起源が出力装置の上のスクリーンのセンターに対応すると決められました。 出力装置のスクリーンの垂直な(水平な)縁はeが断片的なデータの精度で決定しているわずかな正の数である線X(Y)=-1/2かX=+1/2-eに対応しています。 特にポイント(-1/2、-1/2)(-1/2、1/2-e)と(1/2-e、-1/2)と(1/2-e、1/2-e)は論理的なスクリーンの角で目に見えるポイントになるでしょう。 非正方形表示面の場合では、implementerは彼自身の決定を取るかもしれません。(その結果、私たちは、Logical Coordinate Systemが座標が-1/2〜+1/2よりもう少しまで及ぶポイントを含むと言うつもりです。
Michener, et. al. [Page 3] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [3ページ]RFC493グラフィックスプロトコル1973年4月26日
Commands which take coordinate data will be available in various modes. In absolute mode, a position is specified by giving its coordinates in the Logical Coordinate System. In relative mode, the difference between the coordinates of the position and the coordinates of the current position must be specified. Thus a coordinate datum which is an argument for an absolute mode operation should be in the range -1/2 to +1/2-e, while one for a relative mode operation should be in the range -1+e to +1-e.
座標データを取るコマンドが様々なモードで利用可能になるでしょう。 絶対モードで、位置は、Logical Coordinate Systemの座標を与えることによって、指定されます。 相対的なモードで、位置の座標と現在の位置の座標の違いを指定しなければなりません。 したがって、+1/2-eには絶対モード操作のための議論であるコーディネートしているデータが範囲-1/2にあるべきです、+1eには相対的なモード操作のための範囲-1+eにあるべきですが。
Interest was expressed at the second Graphics Group Meeting in eventually allowing a very large coordinate space (many bits of precision in each fractional coordinate). This is to be done by permitting the length, in 8-bit bytes, of each coordinate datum to be set (as a mode). It was decided at the meeting that two bytes per coordinate would suffice for now. Thus "e" in the above discussion is 2**(-15) (one in the least significant bit of a 15-bit plus sign fractional coordinate).
関心は、非常に大きいコーディネートしているスペース(それぞれの断片的な座標の精度の多くのビット)を許容しながら、結局における第2Graphics Group Meetingに示されました。 設定される(モードとして)ためにそれぞれのコーディネートしているデータの8ビットのバイトで長さを可能にすることによって、これをすることになっています。 ミーティングでは、1座標あたり2バイトが当分十分であると決められました。 したがって、上の議論における「e」は2**(-15)です(15ビットのプラスの全く重要な1ビットは断片的な座標に調印します)。
Text data will be transmitted as an argument of various commands for display on the output device. Network ASCII will be used to represent characters. At the lowest-levels of the protocol only one character size will be available -- whatever is "normal" on the display device. If the device has no "normal" size, 72 characters per line would be desirable. At higher levels the size of each individual character can be specified.
テキストデータは表示のための様々なコマンドの議論として出力装置で送られるでしょう。 ネットワークASCIIは、キャラクタの代理をするのに使用されるでしょう。 プロトコルの最も低いレベルでは、何がディスプレイ装置の上で「正常であっ」ても、1つのキャラクタサイズだけが有効になるでしょう。 装置に「正常な」サイズが全くないなら、1線あたり72のキャラクタが望ましいでしょう。 より高いレベルでは、それぞれの個性のサイズを指定できます。
Also, at the lowest levels, control characters will be passed along to the device for it to do the best it can. However, the consensus of the graphics meeting was that at some reasonably low (but non- zero) level, carriage return, line feed, and backspace should be interpreted to do the right thing.
また、最も低いレベルでは、制御文字は、尽くすことができるベストを尽くすために装置に回されるでしょう。 しかしながら、グラフィックスミーティングのコンセンサスは何らかのかなり低(しかし、非ゼロ)レベルにおいてそれでした、復帰、改行、そして、バックスペースキーを押して印字位置を一字分戻ってください。正しいことをするために解釈されるべきです。
Picture Subroutines and Related Topics
絵のサブルーチンと関連した話題
At the second Network Graphics Group meeting, it was decided that two sorts of picture subroutines were desirable, the primary distinction between them being relative difficulty of implementation. At the meeting, the simpler variety was called a subpicture, and the more complex was called a subroutine. This author believes that these terms do not embody enough semantics to facilitate keeping the two straight and so proposes to standardize on "simple subroutine" and "full subpicture" instead.
2番目のNetwork Graphics Groupミーティングでは、2種類の絵のサブルーチンが望ましいと決められました、それらの第一の区別が実現の相対的な困難であり。 ミーティングでは、より簡単なバラエティーは「副-絵」と呼ばれました、そして、複合体はさらにサブルーチンと呼ばれました。 この作者は、これらの用語が代わりに「簡単なサブルーチン」で標準化する2異性愛者とそうが、提案するキープと「完全な「副-絵」」を容易にすることができるくらいの意味論を具体化しないと信じています。
The only parameter which can be passed to a simple subpicture is the "current beam position". In other words, if such a subpicture is called more than once in a picture, the only difference in appearance
簡単な「副-絵」に通過できる唯一のパラメタが「ビーム位置」です。 言い換えれば、外観の唯一の違いそのような「副-絵」が絵の一度よりもう少し呼ばれるなら
Michener, et. al. [Page 4] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [4ページ]RFC493グラフィックスプロトコル1973年4月26日
between the various calls is a translation due to the beam position at the time of the call. Full subpictures, on the other hand, take parameters which can cause scaling, rotation, reflection, or anything else we come up with.
様々な呼び出しの間に、呼び出し時点のビーム位置による翻訳があります。 他方では、完全な「副-絵」は私たちが思いつくスケーリングを引き起こす場合があるパラメタ、回転、反射、または他の何かを取ります。
It is planned that a subpicture definition need be transmitted only once (per network connection) and would not be deleted by a "new picture" operation. Thus a changing picture could be subdivided into several parts on a basis of static versus changing information; only definitions of parts which change need be transmitted to redraw the picture.
計画されていて、そのa「副-絵」の定義が一度(ネットワーク接続単位で)だけ伝えられなければならなくて、「新しい絵」操作で削除されないだろうということです。 したがって、変化の絵を静電気対情報を変えるベースの数個の部品に細分できました。 変化する部品の定義だけが、絵を描き直すために伝えられなければなりません。
Traditionally, picture subroutines which depend only on the initial beam position have been restricted to relative data mode drawing operations. In view of the fact that subpictures will probably be used to save static picture information, it is desirable to allow absolute data mode operations in simple subpictures.
伝統的に、初期のビーム位置だけによる絵のサブルーチンは操作を引き起こす相対データモードに制限されました。 「副-絵」が静的な絵の情報を保存するのにたぶん使用されるという事実から見て、簡単な「副-絵」で絶対データモード操作を許すのは望ましいです。
The next question naturally arises -- what does absolute data mean in a full subpicture which takes both position and scale parameters? Is absolute data really absolute in this case? This author believes that the answer is as follows: the full subpicture is really a picture in its own right, so it has its own logical coordinate system, and its absolute data is really within this coordinate system. Thus "shifting and scaling" a full subpicture really means "scale the subpicture in its own coordinate system and shift the result as a whole".
次の質問は自然に起こります--絶対データは位置とスケールパラメタについてともに取る完全な「副-絵」で何を意味しますか? 絶対データはこの場合本当に絶対ですか? この作者は、答えが以下の通りであると信じています: 完全な「副-絵」は本当にそれ自体で絵です、そして、したがって、それ自身の論理的な座標系を持っています、そして、本当にこの座標系の中に絶対データがあります。 したがって、完全な「副-絵」が「移行して、スケーリング」であることは、本当に「それ自身の座標系で「副-絵」をスケーリングして、全体で結果を移行させます。」と意味します。
In summary, then, a major difference between simple and full subpictures is that a full subpicture has its own logical coordinate system and a simple subpicture uses the logical coordinate system of whoever calls it. This distinction is the reason why full subpictures are harder to implement than simple subpictures.
そして、概要では、簡単で完全な「副-絵」の主要な違いは完全な「副-絵」にはそれ自身の論理的な座標系があって、簡単な「副-絵」がそれを呼ぶ人なら誰でもに関する論理的な座標系を使用するということです。 この区別は完全な「副-絵」が簡単な「副-絵」より実行しにくい理由です。
Another point discussed at the meeting was a special data mode whereby a subpicture can display data at absolute positions on the screen, i.e., absolutely in the main (picture) program. To achieve this, the meeting proposed special data modes for the three operations: move beam invisibly, draw line, and display dot. The intent of these data modes was to bypass all rotation, scaling, and clipping functions associated with the current level of subpicture nesting until this mode was cleared in a certain way. This same effect can be achieved more directly and implemented more efficiently by two commands: one to save and one to re-establish the logical coordinate system for the current subpicture. (Additionally, of course, the "save" operation would establish the initial, highest level, logical coordinate system.)
ミーティングで議論したもう1ポイントは「副-絵」がスクリーンの上の絶対位置にデータを表示できる特別なデータモードでした、すなわち、絶対にメイン(絵)プログラムで。 これを達成するために、ミーティングは3つの操作のための特別なデータモードを提案しました: 目につかないほどビームを動かしてください、そして、線を描いてください、そして、ドットを表示してください。 これらのデータモードの意図はすべての回転を迂回させることでした、このモードが、ある方法でクリアされるまで巣ごもる「副-絵」の現在のレベルに関連している機能をスケーリングして、切り取って。 この同じ効果をより直接達成して、2つのコマンドで、より効率的に実行できます: 救う1つと現在の「副-絵」のために論理的な座標系を復職させる1。 (もちろん、さらに、「節約してください」という操作は初期の、そして、最も高い平らで、論理的な座標系を設立するでしょう。)
Michener, et. al. [Page 5] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [5ページ]RFC493グラフィックスプロトコル1973年4月26日
Simple Subpicture Calls
簡単なSubpictureは呼びます。
Besides the <identifier> of the subpicture to be called, a simple subpicture call may specify two optional parameters; the first is an <identifier> which is the "name" (in a sense described below) of this particular subpicture call and the second is an absolute position on the calling page to be invisibly moved to, prior to calling the subpicture. When (eventually) the viewer is allowed to interact by "picking" information displayed before him, if the information is part of a subpicture, then the "name" of the subpicture call will be part of the "graphic input" reported to the serving host. If the information picked by the viewer is within several levels of subpicture calls, the names of each of the calls will be reported in a manner which indicates their nesting. (Note that just the name of the subpicture by itself is not sufficient, since one subpicture may be displayed in several positions and the application may wish to distinguish between individual calls.) If the identifier is not specified it defaults to the null string. If the position (for the invisible move) is not specified, the current beam position is used.
呼ばれるべき「副-絵」の<識別子>以外に、簡単な「副-絵」の呼び出しは2つの任意のパラメタを指定するかもしれません。 1番目はこの特定の「副-絵」の呼び出しの「名前」(ある意味で以下で説明される)である<識別子>です、そして、2番目は目につかないほど動かされる呼ぶページの絶対位置です、「副-絵」を呼ぶ前に。 ビューアーが(結局)彼の前に表示された情報が「選択」であることによって相互作用できるとき、情報が「副-絵」の一部であるなら、「副-絵」の呼び出しの「名前」は給仕のホストに報告された「グラフィック入力」の一部になるでしょう。 いくつかのレベルの「副-絵」の呼び出しの中にビューアーによって選ばれた情報があると、それぞれの呼び出しの名前は彼らの巣篭もりを示す方法で報告されるでしょう。 (まさしくそれ自体で「副-絵」の名前が十分でないことに注意してください、アプリケーションがいくつかの位置に1枚の「副-絵」を表示するかもしれなくて、個々の呼び出しを見分けたがっているかもしれないので。) 識別子が指定されないなら、それはヌルストリングをデフォルトとします。 位置(目に見えない移動のための)が指定されないなら、ビーム位置は使用されています。
Which of these two parameters are present is encoded by two bits in a code byte which precedes the parameters. If both parameters are present then they are always in the same order; this order and the bits of the code byte assigned to the two parameters are specified in the detailed description of the Simple Instance command (and in the BNF in Appendix 1). Preceding even the code byte, and immediately following the name of the subpicture which is being called upon, is a count of the data in the remainder of the instance command. Thus is included so that it is not necessary to decode the code byte to determine the total length of any one Simple Instance operation.
これらの2つのパラメタのどれが存在しているかは2ビットによってパラメタに先行するコードバイトでコード化されます。 両方のパラメタが存在しているなら、いつも同次にはそれらがあります。 2つのパラメタに割り当てられたコードバイトのこの注文とビットはSimple Instanceコマンド(そしてAppendix1のBNFで)の詳述で指定されます。 コードバイトにさえ先行して、すぐに訪問されている「副-絵」の名前に従うのは、例のコマンドの残りで、データのカウントです。 したがって、含まれているそうは解読するのが必要でない何かSimple Instance操作の全長を決定するコードバイトですか?
Windowing: Clipping, Blanking, or (?)
窓を付けます: または切り取り、空白である。(?)
While on the subject of coordinate systems and subpictures, it might be good to touch on the topic of: who (which end of the connection) is responsible for doing what, when a picture is potentially going to be displayed beyond the edge of the virtual screen? It was the consensus at the graphics meeting that the interpreter of the graphics protocol (i.e., the using end) would not be held responsible for doing anything reasonable in case a picture displays information beyond the edge of the screen (e.g., by relative moves and draws).
座標系と「副-絵」に関して良い間、それは以下の話題に関して接触に良いかもしれません。 潜在的に仮想のスクリーンの縁を超えて絵を表示するとき、だれが何をするのに責任がありますか?(接続のどの終わり) それはグラフィックスミーティングでグラフィックスプロトコル(すなわち、使用している終わり)のインタプリタが絵がスクリーン(例えば、親類で動いて、描く)の縁を超えて情報を表示するといけないので何も妥当なことをするのに責任を負わせられないだろうというコンセンサスでした。
Michener, et. al. [Page 6] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [6ページ]RFC493グラフィックスプロトコル1973年4月26日
The interpreter must react properly to the next absolute data in the proper range, however. Various solutions to this situation in existing graphics systems include:
しかしながら、インタプリタは適切な範囲で適切に次の絶対データに反応しなければなりません。既存のグラフィックスシステムのこの状況の様々な解決策は:
clipping a line to display as much as is proper,
適切であるのと同じくらい多くを表示するために線を切り取ります。
blanking the whole of a line if any part is invisible, or
またはどれか部分が目に見えないなら線の全体が空白である。
discarding high order bits of the current position register, so
that no invisible positions can be represented ("wraparound").
どんな目に見えない位置も表すことができない(「巻きつけて着るドレス」)ように現在の位置のレジスタの高位のビットを捨てます。
In addition to problems of the edge effects at the highest level, problems arise with respect to (full) subpictures. It is nice to be able to select a rectangular portion of a subpicture to be displayed as part of a subpicture call. (See: Newman, Display procedures, Communications of the ACM, Volume 14, Number 10, October 1971, pp651-660). In accordance with the consensus of the meeting, which was to make this capability optional, this author merely hopes to include in the protocol a method of encoding this information since his site a) can handle some such windowing, and b) hopes to provide a service facility to perform this function.
最高水準におけるエッジ効果の問題に加えて、問題は(完全)の「副-絵」に関して起こります。 「副-絵」の長方形の部分が「副-絵」の呼び出しの一部として表示されるのを選択できてうれしいです。 (見てください: ニューマン、Display手順、ACMのCommunications、Volume14、Number10、1971年10月pp651-660。) この能力を任意にすることであったミーティングのコンセンサスによると、彼のサイトa)がそのようないくつかのウインドーを扱うことができて、この作者は、プロトコルにこの情報をコード化する方法を含んでいることを単に望んでいて、b)は、この機能を実行するためにサービス施設を提供することを望んでいます。
Appendix 2 describes how to concatenate several levels of portions into a single rectangular test, as long as no rotations are involved. It also outlines the problems related to rotations and portioning.
付録2はただ一つの長方形のテストにいくつかのレベルの部分を連結する方法を説明します、回転が全くかかわらない限り。 また、それは回転に関連されて、分配することにおける問題について概説します。
Full Subpicture Calls
完全なSubpictureは呼びます。
We are now in position to consider what may be specified as part of a full subpicture call, in addition to the name of the subpicture being called, which is, of course, required. The data described below will all be optional: a single code byte will precede all these data; the presence or absence of one of the parameters will be indicated by a bit in the code byte being one or zero. The parameters will always appear in the same order, if they are present. This order is given below in the detailed description of the Full Instance command (and in the BNF in Appendix 1). Additionally, preceding even the code byte, will be a <count> of the following bytes, including the code byte to determine the total length of any particular Full Instance operation.
私たちは現在、指定されるかもしれないことが完全な「副-絵」の呼び出しの一部であるとみなす立場にいます、呼ばれる「副-絵」の名前に加えて。もちろん、名前が必要です。 以下で説明されたデータはすべて任意になるでしょう: 1コードバイトはこれらのすべてのデータに先行するでしょう。 パラメタの1つの存在か不在が1かゼロであるコードバイトで少し示されるでしょう。 それらが存在していると、パラメタは同次にいつも現れるでしょう。 Full Instanceコマンド(そしてAppendix1のBNFで)の詳述でこのオーダーを以下に与えます。 さらに、コードバイトにさえ先行するのはどんな特定のFull Instance操作の全長も決定するためにコードバイトを含む以下のバイトの<カウント>になるでしょう。
One parameter is an <identifier> which can be used to distinguish this particular call to this subpicture from all other calls to the subpicture. This parameter was already described under Simple Subpicture Calls.
1つのパラメタが他のすべての呼び出しから「副-絵」までこの特定の呼び出しをこの「副-絵」に区別するのに使用できる<識別子>です。 このパラメタはSimple Subpicture Callsの下で既に説明されました。
Michener, et. al. [Page 7] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [7ページ]RFC493グラフィックスプロトコル1973年4月26日
On parameter which may be specified is a translation: this will be specified by giving the absolute coordinates of the center (on the calling page) of the image of the subpicture; this will default to the beam position current at the time of the call.
指定されるかもしれないパラメタに、翻訳があります: これは「副-絵」のイメージのセンター(呼ぶページの)の絶対座標を与えることによって、指定されるでしょう。 これは呼び出し時点で、ビーム位置の電流をデフォルトとするでしょう。
A rotation may be specified by giving a 16-bit fraction in the range 0 to .1111111111111111 (binary) inclusive; this fraction will represent what part of a full circle (2pi) the rotation is. The default value of angle of rotation will be zero.
回転は範囲で0〜.1111111111111111(2進の)に16ビットの断片を与えることによって、包括的に指定されるかもしれません。 意志が表すこの断片に、満のどんな部分が(2pi)回転を旋回するかがあります。 回転角のデフォルト値はゼロになるでしょう。
(Actually, the rotation representation scheme works identically if one thinks of it as a two's complement fraction from -1/2 to just less than +1/2. That is, the same bit configurations encode the same rotation, due to the periodic nature of sine and cosine. For example, binary zero always represents 0 pi 010000...0 denotes pi/2 in both schemes; 100...00 denotes 1/2 in one scheme and -1/2 in the other, which correspond to rotations of +pi and -pi respectively, i.e. identical rotations.)
正弦とコサインの周期的な本質に同じ回転をコード化してください。(-1/2は+ パイとパイすなわち、それぞれと、同じ回転の回転に対応します)。(実際に、人が、-1/2〜+1/2Thatよりちょうど少なく、同じビット構成までの2の補数断片として例えば、2進のゼロがいつも010000...0がパイ/2を指示する0パイを表すとそれを考えるなら表現計画が同様に扱う回転はともに計画されます; 100...00は1つの計画における1/2ともう片方における-1/2を指示します。)
Also specifiable as apart of a full subpicture call is a rectangular portion of the called picture to be imaged on the calling picture (see previous section for a discussion of clipping). This rectangle is specified by its center and one half its total size in x and y. That is, the rectangle will consist of all points whose x coordinate differs from that of the center by no more than the specified x-size and whose y coordinate satisfies a similar condition. The default for these values will place the center at the origin and give both the x half width and the y half width the value of +1/2. Thus the default includes the whole of the logical coordinate system of the called page (and also some points one of whose coordinates are +1/2, which, strictly speaking, lie "outside" of the coordinate system; how this inconsistency is resolved is left unspecified).
また、完全な「副-絵」の呼び出しで隔たるとして明記できるのは、職業の絵の上に像を描かれるべき呼ばれた絵の長方形の部分(切り取りの議論に関して前項を見る)です。 この長方形はxとyでその総サイズのセンターと半分によって指定されます。 すなわち、長方形は指定されたx-サイズだけに従ってx座標がセンターのものと異なっているすべてのポイントから成るでしょう、そして、だれのyが調整されるかが類縁疾患を満たします。 これらの値のためのデフォルトは、起源にセンターをみなして、x半値幅とy半値幅の両方に+1/2の値を与えるでしょう。 したがって、デフォルトは呼ばれたページの論理的な座標系の全体を含んでいます(また、+1 座標の1つが厳密に言うと、「外に座標系の」横たわってください; この矛盾がどう決議されているかが、そうである/2である諸点は不特定のままにされました)。
Finally, one must specify the scaling to be applied in determining the image; this can be done in many ways. One way is to specify a uniform magnification to be applied to the subpicture. So that magnifications in a wide range can be achieved, it is the author's opinion that some form of scientific notation (i.e., floating point) will have to be employed. If there is already a network standard floating point notation (which I am not aware of) it should be employed. Failing that, it is suggested that this notation consist of an 8-bit (two's complement) exponent followed by a 16-bit (two's complement) fractional part.
最終的に、イメージを決定する際に適用されるためにスケーリングを指定しなければなりません。 様々な意味でこれができます。 1つの方法は「副-絵」に適用されるために一定の倍率を指定することです。 広範囲の倍率を達成できるように、何らかのフォームの科学表記法(すなわち、浮動小数点)が使われなければならないのは、作者の意見です。 ネットワークの標準の浮動小数点記法(私はそこを意識していない)が既にあれば、それは使われるべきです。 それに失敗して、この記法が16ビットの(2の補数)断片的な部分があとに続いた8ビットの(2の補数)解説者から成ることが提案されます。
Another form of scaling is to specify separate magnifications in x and in y, to be applied to the subpicture before any rotation is performed. Yet a third way is to specify a rectangular area in the calling picture's coordinate system to be filled with the image of
別のフォームのスケーリングはどんな回転も実行される前に「副-絵」に適用されるためにxとyで別々の倍率を指定することです。 しかし、3番目の道は絵のものがイメージで満たされるべきシステムを調整する呼ぶことにおける長方形エリアを指定することです。
Michener, et. al. [Page 8] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [8ページ]RFC493グラフィックスプロトコル1973年4月26日
the subpicture. Since the center of the image is already specified (by the translation), this image information consists only of half- edge size data. If none of the three methods of scaling are chosen (and an affine transformation (see below) is not given explicitly), then a uniform magnification of unity (i.e., no scaling) is used. Note that the three forms of scaling tend to contradict each other and only one of them should be used in any one call. What happens if self-contradictory information is given in these fields is left unspecified.
「副-絵」。 イメージのセンターが既に指定されるので(翻訳で)、この画像情報は半分縁のサイズデータだけから成ります。 スケーリングの3つの方法のいずれも選ばれていないなら(アフィン変換(以下を見る)は明らかに与えられていません)、統一(すなわち、比例しない)の一定の倍率は使用されています。 スケーリングの3つのフォームが、互いに逆らう傾向があって、それらの1つだけがどんな呼び出しにも使用されるべきであることに注意してください。 これらの分野で自己矛盾の情報を与えるなら何が起こるかは不特定のままにされます。
Appendix 2 presents the mathematics involved in transforming the subpicture's coordinate system into the calling picture's coordinate system. It is shown there that all the individual operations (scaling, rotating, and translating) can be represented as a single affine transformation (which consists of 6 values). It might be nice to permit the serving program to specify this transformation directly. Accordingly, one possible parameter of a full subpicture call will consist of six floating point numbers (of the form described under magnification, above) to be interpreted as an affine transformation. Indeed, if the affine transformation has the following form:
付録2は「副-絵」の座標系を呼ぶことの絵の座標系に変えるのにかかわる数学を提示します。 そこでは、ただ一つのアフィン変換(6つの値から成る)としてすべての単独運転(スケーリングして、回転して、翻訳する)を表すことができるのが示されます。 給仕プログラムが直接この変化を指定することを許可してうれしいかもしれません。 それに従って、完全な「副-絵」の呼び出しの1つの可能なパラメタが、アフィン変換として解釈されるために6つの浮動小数点(上で倍率の下で説明されたフォームについて)から成るでしょう。 本当に、アフィン変換に以下があるなら、形成してください:
/_ |x |y_/ = /_ x y_/ * / L11 L12 / + /_ T1 T2_/
/_ L21 L22 _/
/_ |x|y_/=/_x y_/*/ L11 L12 /+/_T1 T2_//_L21 L22_/
then the values shall (arbitrarily) be sent in the following (columnar) order: L11, L21, L12, L22, T1, T2. This affine transformation should be invertible that is, L11*L22 - L21*L12 should not be zero.
次に、以下の(円柱状)のオーダーで(任意に)値を送るものとします: L11、L21、L12、L22、T1、T2。 L11*L22、このアフィン変換はinvertibleであるべきです--L21*L12はゼロであるべきではありません。
Viewporting
Viewportingします。
Another topic discussed at the meeting, and referred to the protocol committee for decision, was the capability of placing the "top level" picture in some rectangle of the virtual screen. The default rectangle might be the full screen. Alternatively it might be left up to the viewer to specify the default (via) interaction with the graphics system at the Using Host). In general, viewporting allows more than one "top level" picture to be viewed at once. The desire to view several different pictures on the same screen arises in cases where multiple users are working together and in cases where one user is interacting with a group of applications (in separate serving hosts). This author maintains that the coordinate transformations required by this feature are simpler than that of "full subpictures" since no rotations are involved, and would be part of the same mechanism in its implementation. In particular, merely another affine transformation (see Appendix 2) would be added to the levels caused by full subpicture calls. All that is required is keeping
ミーティングで議論して、プロトコル委員会が決定について参照された別の話題は「先端平らな」絵を仮想のスクリーンの何らかの長方形に置く能力でした。 デフォルト長方形はフルスクリーンであるかもしれません。 を通してあるいはまた、それがデフォルトを指定するのがビューアーに任せられるかもしれない、()、Using Hostのグラフィックスシステムとの相互作用) 一般に、viewportingは、1「トップレベル」の絵がすぐに見られるのを許容します。 同じスクリーンの上のいくつかの異なった絵を見る願望は複数のユーザが一緒に働いている場合と1人のユーザがアプリケーションのグループと対話している場合(別々の給仕のホストの)で起こります。 この作者はこの特徴によって必要とされた座標変換が回転が全くかかわらないので、「完全な「副-絵」」でそれより簡単であり、実現で、同じメカニズムの一部であることを支持します。 特に、そして、単に別のアフィン変換(Appendix2を見る)は完全な「副-絵」の呼び出しで引き起こされたレベルに加えられるでしょう。 必要なすべてが保たれています。
Michener, et. al. [Page 9] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [9ページ]RFC493グラフィックスプロトコル1973年4月26日
track of viewport identifiers and the associated rectangles. Since little extra work is involved, it is proposed that this feature be included at some high level of the protocol.
ビューポート識別子と関連長方形の道。 時間外労働がほとんどかかわらないので、この特徴がプロトコルの何らかの高いレベルで含まれているよう提案されます。
Command Codes
コマンドコード
Each command in the graphics protocol will be assigned a non-negative value which will represent this command in the byte stream. The algorithm whereby values and commands are associated is, it turns out, a very touchy subject. There are five or ten different criteria for a "best" algorithm, each criterion different in emphasis. This Gordian knot will be cut, in this proposal, by ordering the commands approximately according to level, and then just numbering them. In addition, if several closely related commands occur at the same level, some attempt will be made to encode variations of meanings in terms of bit configurations. Even if some later consideration causes a change in ordering to be proposed, it is this committee's feeling that the numbering should not be altered. However, until this matter is firmly settled, it is strongly advised that any implementation take into account the possibility of reassignment of command codes.
バイト・ストリームでこのコマンドを表す非負の数はグラフィックスプロトコルにおける各コマンドに割り当てられるでしょう。 値とコマンドが関連しているアルゴリズムがあって、それはアウト、非常に扱いにくい対象を回します。 「最も良い」アルゴリズムの5か10の異なった評価基準、強調において異なったそれぞれの評価基準があります。 このゴーディアン・ノットは切られるでしょう、この提案で、レベルに従って周囲でコマンドを注文して、次に、ただそれらに付番することによって。 さらに、いくつかの密接に関係づけられたコマンドが同じレベルで起こると、ビット構成に関して意味の変化をコード化するのを何らかの試みをするでしょう。 何らかの後の考慮で注文における変化を提案してもさえ、それはこの委員会が、付番が変更されるべきでないと感じることです。 しかしながら、この件がしっかり決着するまで、どんな実現もコマンドコードの再割当ての可能性を考慮に入れると強く忠告されます。
Particular Proposal for Level 0 Protocol
レベル0 プロトコルのための特定の提案
It is proposed that level 0 be kept very simple. This is so that implementation can be quickly accomplished and experimentation with the protocol begun. Another reason is that the least powerful host and even programmable terminals should be able to implement it. In accordance with this, the "rule" was made that a command be included only if its output is a function solely of the current command and the "beam position" current at the start of the command. In other words, the interpreter for level 0 need have no internal storage for "modes" or pushdown stacks. With this restriction it is hoped that a very simple implementation will be possible for level 0. In particular, perhaps one could eventually build a hardware translator from level 0 code to one's own particular terminal's code.
レベル0が非常に簡単に保たれるよう提案されます。 これがそうであるので、すぐにその実現を実行できます。そして、プロトコルが始められている実験。 別の理由は最も強力でないホストと同等のプログラム式端末がそれを実行するはずであることができるということです。 これに従って、コマンドが出力が唯一コマンドの始めの現在のコマンドと「ビーム位置」電流の機能である場合にだけ含まれているという「規則」は作られました。 言い換えれば、レベル0のためのインタプリタには、「モード」かプッシュダウンスタックのための内部記憶装置が全くある必要はありません。 この制限で、レベル0に、非常に簡単な実現が可能であることが望まれています。 恐らく、特に、人は結局、ハードウェア翻訳者をレベル0 コードから自分自身の特定の端末のコードまで建てることができました。
Note that in the opcode assignment for level 0, bits 4, 2, and 1 have special meaning for the move, line, and dot commands. In particular, the 1 bit encodes absolute versus relative data mode, the 4 bit encodes whether any visible output occurs, and the 2 bit determines whether the visible output is a line or a dot.
ビット4、2、および1がレベル0のためのopcode課題では、移動のための特別な意味を持って、立ち並んでいて、コマンドに点を打たせることに注意してください。 どんな目に見える出力も現れるか否かに関係なく、特に、1ビットは相対データモード、4ビットに対する絶対のエンコードをコード化して、2ビットは、目に見える出力が線かそれともドットであるかを決定します。
Level 0: Command Summary
レベル0: コマンド概要
The following is a list of commands (and their syntax) in level zero. Detailed descriptions of these commands follow in the next section. Commands dealing with protocol may be added by the Connection Committee. (They currently request opcodes in the range 128 to 255.)
↓これはレベルゼロにおけるコマンド(そして、それらの構文)のリストです。 これらのコマンドの詳述は次のセクションで続きます。 プロトコルに対処するコマンドはConnection Committeeによって加えられるかもしれません。 (彼らは現在、範囲で128〜255にopcodesを要求します。)
Michener, et. al. [Page 10] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [10ページ]RFC493グラフィックスプロトコル1973年4月26日
(As described in Basic Data Forms, above, <x coordinate>, <y coordinate>, <x delta> and <y delta> are two-byte coordinate values, <string> is a count followed by <count> many bytes and <value> is an eight bit number.)
(<yコーディネートしている>、<xデルタの>と<yデルタ>はBasic Data Forms、上の<x座標>で説明されるように2バイトの座標値であり、<ストリング>は多くのバイト<カウント>によっていうことになられたカウントであり、<値の>は8ビットの数です。)
Decimal Octal Binary Format 0 0 00000000 Null 1 1 00000001 Erase screen and reset beam 2 2 00000010 Move Absolute <x coordinate> <y coordinate> 3 3 00000011 Move Relative <x delta> <y delta> 4 4 00000100 Draw Absolute <x coordinate> <y coordinate> 5 5 00000101 Draw Relative <x delta> <y delta> 6 6 00000110 Dot Absolute <x coordinate> <y coordinate> 7 7 00000111 Dot relative <x delta> <y delta> 8 10 00001000 Text <string> 9 11 00001001 TextR <string> 10 12 00001010 End of Picture 11 13 00001011 Escape <value> <string>
10進Octal Binary Format0 0 00000000Null1 1 00000001Eraseスクリーンとリセットビーム2 2 00000010Move Absolute<x座標><y座標>3 3 00000011Move Relative<xデルタ><yデルタ>4 4 00000100Draw Absolute<xのコーディネートしている><yは>5 5 00000101Draw Relative<xを調整します; デルタ><yデルタ>6 6 00000110Dot Absolute<x座標><y座標>の7 7の00000111のDotの相対的な<xデルタ><yデルタ>8 10 00001000Text<ストリング>9 11 00001001TextR<はPicture11 13 00001011Escape<値の><ストリング>の>10 12 00001010Endを結びます。
Level 0: Command Descriptions
レベル0: コマンド記述
0 Null Statement ("NULL").
This statement has no arguments--and no effect, either.
0空文(「ヌル」の)。 この声明には、議論がなく、および効果が全くありません。
1 Erase screen and reset beam to origin ("ERASE").
This command indicates that a new picture is about to be drawn. It
should always be (eventually) paired with a following End of Picture
command.
1個の抹消スクリーンとリセットは起源(「抹消」)に発します。 このコマンドは、新しい絵が描かれようとしているのを示します。 それは(結局、)いつもPictureコマンドの次のEndと対にされるべきです。
2 Move beam invisibly to absolute position
("MOVEA") <x coordinate> <y coordinate>.
Nothing is drawn; the beam is positioned to the specified absolute x,y
position.
2は目につかないほどビームを絶対位置のコーディネートしている><yコーディネートしている("MOVEA")<x>に動かします。 何も描かれません。 ビームは指定された絶対的なものx、y位置に置かれます。
3 Move beam invisibly by relative amount
("MOVER") <x coordinate> <y coordinate>.
Nothing is drawn; the beam is shifted by the specified amount in x and
y.
3は親類のコーディネートしている><yコーディネートしている量の(「動く人」)<x>で目につかないほどビームを動かします。 何も描かれません。 ビームはxとyで一定金額によって移動させられます。
4 Draw line to absolute position
("DRAWA") <x coordinate> <y coordinate>.
A line is drawn from the current beam position to the specified absolute
x,y position.
4は絶対位置のコーディネートしている><yコーディネートしている("DRAWA")<x>に線を引きつけます。 指定された絶対的なものxへのビーム位置、y位置から線を得ます。
Michener, et. al. [Page 11] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [11ページ]RFC493グラフィックスプロトコル1973年4月26日
5 Draw line to relative position
("DRAWR") <x delta> <y delta>.
A line is drawn from the current beam position to the position delta x
and delta y away.
5は親類位置の("DRAWR")<xデルタ><yデルタ>に線を引きつけます。 線は遠くのビーム位置からポジションデルタxとデルタyまで描かれます。
6 Display a Dot at absolute position
("DOTA") <x coordinate> <y coordinate>.
The beam is moved invisibly to absolute position x,y and a dot is
displayed there.
6は絶対位置のコーディネートしている><yコーディネートしている("DOTA")<x>にDotを表示します。 目につかないほどビームを絶対位置x、yに動かします、そして、そこにドットを表示します。
7 Display a Dot at relative position
("DOTR") <x delta> <y delta>.
The beam is moved invisibly by the specified amount in x and y and a dot
is displayed there.
7は親類位置の("DOTR")<xデルタ><yデルタ>にDotを表示します。 ビームはxとyで一定金額で目につかないほど感動しています、そして、そこにドットを表示します。
8 Display text ("TEXT") <string>.
At the current beam position, display some characters at the normal size
for the device being operated. <string> consists of a <count> followed
by count many characters. If there is no "normal size", choose the size
so that seventy-two characters are displayed per line. The characters in
the string are coded in network ASCII all codes between 0 and 127
(decimal) inclusive are permitted. (At level zero, what happens to
control characters is left unspecified.) Where the beam is, following
execution of this command, is left unspecified, except that another
Display Text command immediately following will append its text to the
previous string. (The use of the TEXT command is discouraged; use TextR
instead.) The position of the first character relative to the initial
beam position is left unspecified.
8 表示テキスト(「テキスト」)<は>を結びます。 ビーム位置では、操作される装置のために標準サイズで何人かのキャラクタを見せてください。 <ストリング>はカウント多くのキャラクタによって後をつけられた<カウント>から成ります。 「標準サイズ」が全くなければ、線単位で72のキャラクタを見せるようにサイズを選んでください。 ストリングのキャラクタは0と127(10進)の間で包括的なすべてのコードが受入れられるネットワークASCIIでコード化されます。 (レベルゼロでは、制御文字がどうなるかは不特定のままにされます。) このコマンドの実行に続いて、ビームがどこにあるかは不特定のままにされ、すぐに続いて、別のDisplay Textが命令するのを除いて、前のストリングにテキストを追加するでしょう。 (TEXTコマンドの使用はお勧めできないです; 代わりにTextRを使用してください。) 初期のビーム位置に比例した最初のキャラクタの位置は不特定のままにされます。
9 Display text and restore beam ("TEXTR") <string>.
At the current beam position, display a string of characters at the
normal size for the device being operated; then reposition the beam to
where it was before the command. <string> consists of a <count> followed
by count many characters. If there is no "normal size", choose the size
so that seventy-two characters are displayed per line. The characters in
the string are coded in network ASCII; all codes between 0 and 127
(decimal) inclusive are permitted. (At level zero, what happens to
control characters is left unspecified.) The position of the first
character relative to the initial beam position is left unspecified.
9は、テキストを表示して、ビーム("TEXTR")<ストリング>を返します。 ビーム位置では、操作される装置のために標準サイズで一連のキャラクタを見せてください。 そして、コマンドの前に、それがあったところにビームの位置を変えてください。 <ストリング>はカウント多くのキャラクタによって後をつけられた<カウント>から成ります。 「標準サイズ」が全くなければ、線単位で72のキャラクタを見せるようにサイズを選んでください。 ストリングのキャラクタはネットワークASCIIでコード化されます。 0と127(10進)の間で包括的なすべてのコードが受入れられます。 (レベルゼロでは、制御文字がどうなるかは不特定のままにされます。) 初期のビーム位置に比例した最初のキャラクタの位置は不特定のままにされます。
10 End of Picture ("ENDPIC").
This command denotes the end of a new picture. It must be paired with a
preceding ERASE command.
絵の("ENDPIC")の10終わり。 このコマンドは新しい絵の端を指示します。 前のERASEコマンドとそれを対にしなければなりません。
11 Escape to device specifics ("ESCDEV") <value> <string>.
If "value" is the code assigned (by the Protocol Committee) to the
device being operated, then transmit the eight-bit bytes in <string>
(which starts with a <count> indicating the number of bytes) to the
11は装置詳細("ESCDEV")<値の><ストリング>に逃げます。 その時は、コードが「値」であるなら操作される装置に割り当てられる(プロトコルCommittee)と<ストリング>(バイト数を示すa<カウント>から始まる)の8ビットのバイトを伝えます。
Michener, et. al. [Page 12] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [12ページ]RFC493グラフィックスプロトコル1973年4月26日
device without examining them. Otherwise ignore this command. If the device does not accept 8-bit information, reformat the data in some device specific way; an example would be throwing away the high order bit for a seven bit device, or gathering 5 8-bit bytes into one 36-bit word, again discarding the high order bits, perhaps. The action of the bytes in the string should leave alone (or at least restore) any hardware beam position registers in the device which the interpreter might conceivably depend on.
それらを調べることのない装置。 さもなければ、このコマンドを無視してください。 装置は8ビットの情報を受け入れないで、何らかの装置の特定の方法で再フォーマットはデータです。 例は、7ビットの装置に高位のビットを無駄にするか、または1つの36ビットの単語に8ビットの5バイト集まっているでしょう、再び恐らく高位のビットを捨てて ストリングにおける、バイトの動作が単独でいなくなるべきである、(少なくとも、回復、)、どんなハードウェアビーム位置もインタプリタが多分当てにするかもしれない装置に登録されます。
This command really should not be used it was included at level 0 so that specific applications can do mode setting and other device specific manipulations. For example, ARDS terminals may optionally have several independently addressable output scopes. The selection mechanism changes state only when a particular sequence of ASCII characters reaches the terminal. Thus ESCDEV would be used to select which scope(s) is/are to be affected by following commands. (The current state is invisible to the graphics package at the Using Host.)
このコマンドは本当に使用されて、特定のアプリケーションがモード設定と対向機器の特定の操作ができるようにそれがレベル0で含まれていたということであるべきではありません。 例えば、ARDS端末には、数個の独自にアドレス可能な出力範囲が任意にあるかもしれません。 選択メカニズム変化は、ASCII文字の特定の系列がいつだけ端末に達するかを述べます。 したがって、ESCDEVによるどの範囲が/であるかを選択するのにおいて使用されているのが、コマンドに続くことによって影響を受けることであるということでしょう。 (現状はUsing Hostでのグラフィックスパッケージに目に見えません。)
Further, suppose that another make of terminal has a similar option, which responds to a different code sequence. This possibility is the motivation for conditionally ignoring the ESCDEV command based on the "<value>" specified. Given that a particular application will only be used to output to either an ARDS or this second make (with the multiple scope option), then the application could always send two ESCDEV commands, one applicable only to ARDS terminals, and the other applicable only to the second make.
さらに、別の造の端末には同様のオプションがあると仮定してください。(オプションは異なったコード系列に応じます)。 この可能性は条件付きに、「<値の>」に基づいたコマンドが指定したESCDEVを無視することに関する動機です。 特定用途がARDSかこの2番目が作る(複数の範囲オプションで)どちらかへの出力に使用されるだけであるなら、アプリケーションはいつもESCDEVコマンド、ARDS端末だけに適切な1つ、および2番目だけに適切な他が作る2を送るかもしれません。
LEVEL 1
レベル1
*Set Line mode ("LINMOD") <value>.
This command sets the current line mode possible modes and the
<value> which sets each are: solid (0), dashed (1), dotted (2), and
others (3 or >). At the beginning of a new picture (i.e., after an
Erase and Reset command), line mode is solid. If a site does not have
a certain mode readily available, it may a) simulate it in software,
b) substitute another in its place (dashed for dotted, or vice versa)
c) ignore it entirely. What is provided should be clearly indicated
in any public document. It is strongly recommend that at least solid
and one other mode be provided.
*線モード("LINMOD")<値の>を設定してください。 このコマンドはモードとセットする<価値の>がそれぞれそうであることが可能な現在行モードを設定します: 投げつけられた点を打たされた固体(0)、(1)、(2)、および他のもの(3か>)。 新しい絵(すなわち、EraseとResetが命令した後に)の始めに、ライン・モードはしっかりしたです。 それはあるモードがサイトで容易に利用可能にならないなら、します。a)はソフトウェアでそれをシミュレートして、b)代用品は(点を打たれた状態で、逆もまた同様に突進します)c)がそれを完全に無視する場所の別です。 提供されるものはどんな官庁出版物でも明確に示されるべきです。 それは少なくとも固体と他の1つのモードが提供されることを強く勧めることです。
*Set intensity ("SETINT") <value>.
This command sets the intensity of lines, dots and characters
displayed following the command. If <value> is 128 decimal, normal
intensity should be set. If <value> is 255 decimal, brightest should
be selected, and if it is 0, then the beam should be blanked.
Intermediate values should be mapped appropriately as the implementer
*強度("SETINT")<値の>を設定してください。 このコマンドはコマンドに続いて、見せられた台詞、ドット、およびキャラクタの強度を設定します。 <値の>が128小数であるなら、正常な強度は設定されるべきです。 <値の>が255小数であるなら、選択されて、それが0であるなら最も明るいのが、小数であるべきであり、次に、ビームは空白であるべきです。 中間的値はimplementerとして適切に写像されるべきです。
Michener, et. al. [Page 13] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [13ページ]RFC493グラフィックスプロトコル1973年4月26日
sees fit. For instance, if brightest is the same as normal, all values from 128 through 255 should be mapped to normal. Information displayed between the start of a new picture (the ERASE command) and the first SETINT command appears at normal intensity.
適していると決めます。 例えば、最も明るいなら、標準、128〜255の値が写像されるべきであるすべてと同じくらいは正常ですか? 新しい絵(ERASEコマンド)の始まりと最初のSETINTコマンドの間に表示された情報は正常な強度に現れます。
*Text out ("TEXTO") <string>.
Starting from the current beam position, this command displays the
<string> (of network ASCII characters) formatted as if it were typed
material (at the current intensity). <string> consists of a <count>
followed by count many characters. That is, text extending past the
right margin will be broken and repositioned at the left margin on
the next line down. Of the control characters, only carriage return,
line feed, and backspace are required to be interpreted properly.
*テキストの出ている("TEXTO")<は>を結びます。 ビーム位置から始めて、このコマンドはまるでそれがタイプされた材料(現在の強度で)であるかのようにフォーマットされた<ストリング>(ネットワークASCIIキャラクタの)を表示します。 <ストリング>はカウント多くのキャラクタによって後をつけられた<カウント>から成ります。 すなわち、ライト・マージンの先で広がるテキストは壊れるでしょう、そして、次の線の左のマージンで位置を変えられて、ダウンしてください。 バックスペースキーを押して印字位置を一字分戻ってください。そして、制御文字、復帰だけ、改行について適切に解釈されるのが必要です。
*Subpicture header ("SUBHED") <identifier> <count> <header info>.
This command begins the definition of a subpicture named
"<identifier>". This definition is terminated by a matching SUBEND
command. The definition will be remembered until a new one is
specified or until the graphics network connection is broken. Note
that <identifier> is a <string> consisting solely of capital letters
and numbers.
*Subpictureヘッダー("SUBHED")<識別子><カウント><ヘッダーインフォメーション>。 このコマンドは「<識別子>」という「副-絵」の定義を始めます。 この定義は合っているSUBENDコマンドで終えられます。 新しいものが指定されているか、またはグラフィックスネットワーク接続が失意であるまで、定義は覚えていられるでしょう。 <識別子>が唯一大文字と数から成る<ストリング>であることに注意してください。
Subpicture definitions may be nested this will be equivalent to transmitting the two definitions separately. In other words, all subpicture names are globals and are "known" to all other subpictures. If a subpicture definition has not been received prior to its use in a picture, the empty subpicture should be displayed in its place until a definition is received.
Subpicture定義は入れ子にされて、これが別々に2つの定義を伝えるのに同等になるということであるかもしれません。 言い換えれば、すべての「副-絵」の名が、他のすべての「副-絵」においてglobalsであり、「知られています」。 絵における使用の前に「副-絵」の定義を受けていないなら、定義が受け取られているまで、場所に空の「副-絵」を表示するべきです。
A subpicture definition need not be transmitted as part of a picture (i.e., within an ERASE and END command pair). Indeed, all subpicture definitions might precede the main picture.
「副-絵」の定義は絵(すなわち、ERASEとENDコマンド組の中の)の一部として伝えられる必要はありません。 本当に、すべての「副-絵」の定義が主な絵に先行するかもしれません。
Currently, the <count> will always be 1, indicating only one byte of <header info> follows, but at higher levels of the protocol room for expansion may be required. In the <header info>, the 80 hex bit will be set if this subpicture can be a simple subpicture, and the 40 hex bit will be set if the subpicture can be a full subpicture. (It is possible that one subpicture can be both.)
現在、<カウント>はいつも1になるでしょう、1バイトの<ヘッダーインフォメーション>だけを続きますが、拡大のプロトコル部屋の、より高いレベルで必要としてもよいのを示して。 <ヘッダーインフォメーション>では、80十六進法ビットはこの「副-絵」が簡単な「副-絵」であるかもしれないなら設定されて、40十六進法ビットは「副-絵」が完全な「副-絵」であるかもしれないなら設定されるでしょう。 (1枚の「副-絵」が両方であるかもしれないことが可能です。)
Other information that may eventually be present in <header info> include whether the current value of a certain mode or parameter should be saved on entry to, and restored on exit from, this subroutine whenever it is called. These modes and parameters include: line mode, intensity, character size, and data length.
他のあるモードかパラメタがエントリーが節約されて、回復するべきであるaの現行価値が出るか否かに関係なく、結局<ヘッダーインフォメーション>インクルードで存在するかもしれない情報、このサブルーチン、それが呼ばれるときはいつも。 これらのモードとパラメタは: モード、強度、キャラクタサイズ、およびデータの長さを裏打ちしてください。
Michener, et. al. [Page 14] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [14ページ]RFC493グラフィックスプロトコル1973年4月26日
*Subpicture end ("SUBEND").
This command ends the definition of a subpicture. Each SUBEND must
match a preceding SUBHED command.
*Subpictureは("SUBEND")を終わらせます。 このコマンドは「副-絵」の定義を終わらせます。 各SUBENDは前のSUBHEDコマンドに合わなければなりません。
*Simple instance ("INSTS") <identifier> <simple instance tail>
This command indicates that the subpicture <identifier> is to be
called (instanced). At this level, level 1, no subpicture may call
another; if one does, what happens is left unspecified. Also, this
must be a call to a simple subpicture. Thus the 80 hex bit of the
single byte of <header info> must have been set in the SUBHED command
which started the definition of <identifier>. If the subpicture
<identifier> has never been defined, the empty subpicture should be
displayed in its place.
*このコマンドが呼ばれる(例証される)ために「副-絵」の<識別子>がそうであることを示す簡単な例(「INSTS」)の識別子の>の<の簡単な例の<テール>。 どんな「副-絵」も、平らで、平らなこれ時に別のものと呼ばないかもしれません。 1がそうするなら、何が起こるかは不特定のままにされます。 また、これは簡単な「副-絵」への呼び出しであるに違いありません。 したがって、<ヘッダーインフォメーション>の単一のバイトの80十六進法ビットは<識別子>の定義を始めたSUBHEDコマンドで設定されたに違いありません。 「副-絵」の<識別子>を一度も定義したことがないなら、場所に空の「副-絵」を表示するべきです。
The <simple instance tail> begins with a count of the amount of information which follows. This count may be zero. If non-zero, the next byte is a code byte to be interpreted to see what further information follows. If the 80-hex bit is set, next in the byte stream is an <identifier> (called "AS information"). This <identifier> is the name of this particular instance of the subpicture as described under Simple Subpicture Calls. If the 40-hex bit is set, then next in the byte stream (following the AS information, if present) is an x,y position (in the calling picture's coordinate scheme) at which the subpicture will be centered. (This is called AT information.)
<の簡単な例のテール>は続く情報量のカウントで始まります。 このカウントはゼロであるかもしれません。 非ゼロであるなら、次のバイトはどんな詳細が従うかを見るために解釈されるべきコードバイトです。 80十六進法のビットが設定されるなら、バイト・ストリームで次であるのは、<識別子>(「AS情報」と呼ばれる)です。 この<識別子>はSimple Subpicture Callsの下で説明されるように「副-絵」のこの特定の例の名前です。 40十六進法のビットが設定されるなら、バイト・ストリーム(存在しているなら、AS情報に従う)で次であるのは、x、「副-絵」が中心に置かれるy位置(呼ぶことの絵のコーディネートしている計画における)です。 (これはAT情報と呼ばれます。)
If AT information is not specified, the current beam position is used as a default. If AS information is not specified, it defaults to the <string> containing zero characters. If neither the 40 hex nor the 80 hex bits are set, then neither the AT information not the AS information is present, and the code byte should be zero. (Also, the length count had better be 1.)
AT情報が指定されないなら、ビーム位置はデフォルトとして使用されます。 AS情報が指定されないなら、それはキャラクタを全く含まない<ストリング>をデフォルトとします。 どちらも40十六進法か80十六進法であるなら、ビットは設定されて、次に、どちらもいずれのAS情報も存在していないというAT情報ではありません、そして、コードバイトがゼロであるべきです。 (また、長さのカウントは、より良いのが1であることを持っていました。)
Changes to levels 0 commands for level 1.
レベル0 レベル1のためのコマンドへの変化。
TEXT and TEXTR -- Carriage return, line feed and backspace characters should definitely be interpreted whenever they appear in <string>. The results of other control characters remain unspecified. The intensity of the characters shall be affected by the SETINT command.
TEXTとTEXTR--<ストリング>に現れるときはいつも、復帰、改行、および後退文字は確実に解釈されるべきです。 他の制御文字の結果は不特定のままで残っています。 キャラクタの強度はSETINTコマンドで影響を受けるものとします。
ERASE -- Normal intensity and solid line mode must be established at the start of a new picture.
ERASE--新しい絵の始めで正常な強度と実線モードを確立しなければなりません。
DRAWA and DRAWR -- Line mode and intensity shall be affected by the LINMOD and SETINT commands.
DRAWAとDRAWR--ライン・モードと強度はLINMODとSETINTコマンドで影響を受けるものとします。
DOTA and DOTR -- Intensity shall be affected by the SETINT command.
DOTAとDOTR--強度はSETINTコマンドで影響を受けるものとします。
Michener, et. al. [Page 15] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [15ページ]RFC493グラフィックスプロトコル1973年4月26日
LEVEL 2
レベル2
*Mark ("MARK").
This command causes the current x,y beam position to be saved on a
pushdown stack. This pushdown stack must be separate from the
subpicture call pushdown stack.
*(「マーク」)をマークしてください。 このコマンドは電流x、プッシュダウンスタックの上で救われるべきyビーム位置を引き起こします。 このプッシュダウンスタックは「副-絵」の呼び出しプッシュダウンスタックから別々であるに違いありません。
*Move to mark and pop ("MOVEMK").
This command sets the current beam position equal to the x,y position
at the top of the "mark" pushdown stack. If the stack is empty, the
origin is used, instead. Then the stack is popped up (unless it is
empty).
*("MOVEMK")を動いて、マークして、飛び出させてください。 このコマンドは「マーク」プッシュダウンスタックの先端にx、y位置と等しいビーム位置を設定します。 スタックが空であるなら、起源は代わりに使用されます。 そして、スタックは打ち上げされます(それが空でない場合)。
*Draw to mark and pop ("DRAWMK").
If the "mark" pushdown stack is not empty, this command draws a line
(of the current line mode and intensity) from the current beam
position to the x,y position at the top of the "mark" pushdown stack,
and sets the beam position to that value. Then the stack is popped.
If the stack is empty, the line is drawn to the origin and the beam
position is set there also.
*("DRAWMK")を描いて、マークして、飛び出させてください。 「マーク」プッシュダウンスタックが空でないなら、このコマンドは、ビーム位置からx、「マーク」プッシュダウンスタックの先端のy位置に線を引いて(現在行モードと強度について)、その値にビーム位置を設定します。 そして、スタックは飛び出します。 スタックが空であるなら、線は起源に引きつけられます、そして、また、ビーム位置はそこに設定されます。
Changes to level 0 and 1 for level 2.
レベル2のためのレベル0と1への変化。
INTS -- arbitrary levels of simple subpictures must be supported. (Note that recursive use of subpictures is not allowed: once recursion starts, it can never be stopped.) The pushdown stack for subpicture calls must be kept separate from the "mark" pushdown stack.
INTS--簡単な「副-絵」の任意のレベルを支持しなければなりません。 (「副-絵」の再帰的な使用が許されていないことに注意してください: 再帰がいったん始まると、それを決して止めることができません。) 「マーク」プッシュダウンスタックから別々に「副-絵」の呼び出しのためのプッシュダウンスタックを保たなければなりません。
Level 3
レベル3
(Perhaps all rotational transformations should be put at a higher level, for instance higher than viewport operations.)
(恐らくすべての回転変換が、より高いレベル、例えば、ビューポートより高い操作のときに置かれるべきです。)
*Full Instance ("INSTF") <identifier> <full instance tail>
This command indicates that the subpicture <identifier> is to be
called (instanced) in a "full" manner as described in an explanatory
section. For one thing, this means that the 40 hex bit of the single
byte of <header info> must have been set in the SUBHED command which
started the definition of <identifier>. If <identifier> has never
been defined, the empty subpicture (i.e., nothing) should be
displayed in its place.
*このコマンドが説明しているセクションで説明されるように「完全な」方法で呼ばれる(例証される)ために「副-絵」の<識別子>がそうであることを示す完全なInstance("INSTF")の識別子の>の<の完全な例の<テール>。 一つには、これは、<ヘッダーインフォメーション>の単一のバイトの40十六進法ビットが<識別子>の定義を始めたSUBHEDコマンドで設定されたに違いないことを意味します。 <識別子>を一度も定義したことがないなら、場所に空の「副-絵」(すなわち、何でもない)を表示するべきです。
The <full instance tail> is similar to the <simple instance tail> described under the INSTS command, but the former contains more information. Below is a list of the information which can be specified, and the bit assigned to the presence/absence of each piece of information. The pieces of information which are present always
<の完全な例のテール>はテール>がINSTSコマンドで説明した<の簡単な例と同様ですが、前者は詳しい情報を含んでいます。 以下に、指定できる、情報のリスト、およびそれぞれの情報の存在/欠如に割り当てられたビットがあります。 情報のいつも存在している断片
Michener, et. al. [Page 16] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [16ページ]RFC493グラフィックスプロトコル1973年4月26日
appear in the byte stream in the order they are described in this list. (All pieces of information are described more fully in Full Subpicture Calls, except for the "AS information" which is described in Simple Subpicture Calls.)
出現、オーダーにおけるバイト・ストリームでは、それらはこのリストで説明されます。 (情報のすべての断片がFull Subpicture Callsで、より完全に説明されます、Simple Subpicture Callsで説明される「AS情報」を除いて。)
Bit (hex) Information
80 As information --"name" of this particular instance.
Consists of an <identifier>.
この特定の例のビット(魔法をかける)情報80As情報--「名前」。 <識別子>から成ります。
40 Translation information -- Center of the subpicture's image
on the calling page. Consists of an <x coordinate> and a
<y coordinate>.
40 翻訳情報--呼ぶページの「副-絵」のイメージのセンター。 <のxコーディネートしている>と<のyコーディネートしている>から成ります。
20 Rotation -- Fractional part of 2pi to rotate the image
counterclockwise. Consists of a 16-bit unsigned fraction.
20 回転--イメージを反時計回りに回転させる2piの断片的な部分。 16ビットの無記名の断片から成ります。
10 Portion Information -- Rectangular part of subpicture which
is to be displayed. Consists of <x coordinate>,
<y coordinate>, <x delta>, and <y delta>.
10 部分情報--表示されることになっている「副-絵」の長方形の部分。 <xコーディネートしている>、<yコーディネートしている>、<xデルタの>、および<yデルタ>から成ります。
8 Uniform Magnification -- Amount to scale the whole
subpicture. Consists of a floating point number (which
should not be zero).
8のユニフォームMagnification--達して、全体の「副-絵」をスケーリングしてください。 浮動小数点(ゼロであるべきでない)から成ります。
4 Separate x and y magnification -- Separate scales for the x
and y axes of the subpicture. Consists of two floating
point numbers (neither of which should be zero).
4の別々のxとy倍率--「副-絵」のxとy軸のためにスケールを切り離してください。 2つの浮動小数点(それのどちらもゼロであるべきでない)から成ります。
2 Image Size -- How large a rectangle on the calling page is
the image to occupy. Consists of an <x delta> and a
<y delta> (neither of which should be zero).
2 イメージSize--呼ぶページのどれくらい大きい長方形は占領するイメージですか? >(それのどちらもゼロであるべきでない)の<x>デルタと<yデルタから成ります。
1 Affine transformation -- The map from the called to the
calling coordinates system. Consists of six floating point
numbers.
1 アフィン変換--呼ぶのからの呼ぶことへの地図はシステムを調整します。 6つの浮動小数点から成ります。
Notes:
注意:
1) At most one of the three bits: 8, 4, and 2, should be set.
1) 高々3ビットの1つ: 8、4、および2は設定されるべきです。
2) If the 1 bit is set, bits 2, 4, 8, 20, and 40, should not be set.
2) 1ビットを設定するなら、ビット2、4(8、20、および40)を設定するべきではありません。
3) If additional optional parameters are ever added to the full subpicture call, another code byte could follow all the above information. In that case, the <count> part of the <full instance tail> would include this second code byte and any additional bytes of information.
3) 追加任意のパラメタが今までに完全な「副-絵」の呼び出しに加えられるなら、もう1コードバイトはすべての上記の情報に従うかもしれません。 その場合、<の完全な例のテール>の<カウント>部分はこの2番目のコードバイトとどんな追加バイトの情報も含んでいるでしょう。
Michener, et. al. [Page 17] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [17ページ]RFC493グラフィックスプロトコル1973年4月26日
*Escape to top level coordinate system ("ESCTOP").
Until a RESLEV command is (subsequently) executed, all display
commands (moves, draws, dots, and texts) shall operate as if they
were issued by the top level (main) picture instead of the subpicture
containing them. That is, they shall be mapped to the screen
according to the map for the highest level. Subpicture calls
themselves, which are made while an ESCTOP command is in effect, are
not affected by the command. That is, transformations are calculated
as if the command were not in effect. The calculated transformations
are ignored, however, and information displayed by the subpicture
still appears to be at the top level, until a RESLEV command
nullifies the ESCTOP mode. Thus a subpicture call executed while an
ESCTOP command is in effect, acts as if a RESLEV were executed
immediately before the call, and an ESCTOP command were executed as
the first command of the subpicture. Similar considerations hold for
returning from subpictures.
*座標系("ESCTOP")というトップレベルに逃げてください。 まるでそれらを含んでいて、それらが「副-絵」の代わりに最高平らな(主な)絵によって発行されるかのようにRESLEVコマンドが(次に)実行されるまで、すべての表示命令(移動、ドロー、ドット、およびテキスト)が作動するものとします。 地図によると、すなわち、それらは最高水準のためにスクリーンに写像されるものとします。 Subpicture電話(ESCTOPコマンドが有効である間、される)自体はコマンドで影響を受けません。 まるでコマンドが有効でないかのようにすなわち、変化は計算されます。 しかしながら、計算された変化は無視されます、そして、「副-絵」によって表示された情報はトップレベルにあるようにまだ見えています、RESLEVコマンドがESCTOPモードを無効にするまで。 したがって、事実上、ESCTOPコマンドが行為ですが、まるでRESLEVが呼び出し、およびESCTOPコマンドの直前実行されるかのように呼び出しが実行した「副-絵」は「副-絵」の最初のコマンドとして実行されました。 同様の問題は、「副-絵」から戻るために成立します。
*Resume current level coordinate system ("RESLEV").
This command restores the logical coordinate system corresponding to
the subpicture currently executing, in case that coordinate system
was disabled by an ESCTOP command. (See ESCTOP.)
*座標系("RESLEV")という現在のレベルを再開してください。 このコマンドはその座標系がESCTOPコマンドで損傷されるといけなかったので現在実行される「副-絵」に対応する論理的な座標系を返します。 (ESCTOPを見てください。)
Changes to levels 0, 1, and 2 for level 3.
レベル3のためのレベル0、1、および2への変化。
MARK -- the saved beam position shall be in terms of the logical coordinate system, not the physical coordinate system.
マーク--物理的な座標系ではなく、論理的な座標系に関して救われたビーム位置があるものとします。
TEXTR, TEXT, TEXTO -- Since a full subpicture is supposed to be transformed as a whole, as if it were a picture in its own right, it appears to this author that, in particular, all beam movements related to characters should be affected. This includes character size, tab, carriage return and line feed. In particular, carriage return should set the beam to the left margin--that is, to the left edge of the logical coordinate system of the called subpicture. All these changes may be very hard to accomplish, and what should be done will be left unspecified at this time, with comment from readers particularly invited.
TEXTR、TEXT、TEXTO--完全な「副-絵」によって全体で変えられるべきであるので、まるでそれがそれ自体で絵であるかのように、キャラクタが影響を受けるべきであるように特に、すべてのビーム運動が関連したこの作者にとって見えます。 これはキャラクタサイズ、タブ、復帰、および改行を含んでいます。 特に、復帰はすなわち、左のマージン、呼ばれた「副-絵」の論理的な座標系の左の縁にビームを設定するべきです。 これらのすべての変化は達成するのが非常に困難であるかもしれません、そして、するべきであることはこのとき不特定のままにされるでしょう、特に招待された読者からのコメントで。
Level 4
レベル4
(Perhaps viewpoint operations can be included in level 3.)
(恐らく、レベル3に観点操作を含むことができます。)
*Declare Viewport
("SETVW") <viewport id> <x coordinate> <y coordinate> <x delta>
<y delta>
Set the viewport identified by <viewport id> to represent the
indicated area of the logical screen. The x and y data are not
physical screen coordinates, since that would involve device
*コーディネートしているViewport("SETVW")の<のxコーディネートしている><<ビューポートイド>yデルタ><yデルタ><x>が、<ビューポートイド>によって特定されたビューポートに論理的なスクリーンの示された領域を表すように設定したと宣言してください。 それは装置にかかわるでしょう、したがって、xとyデータは物理的な画面座標ではありません。
Michener, et. al. [Page 18] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [18ページ]RFC493グラフィックスプロトコル1973年4月26日
dependencies. This command completely supersedes any previous declaration of the same viewport. If information is already displayed within the viewport specified, this command causes the displayed information to be relocated on the screen to its new position.
依存。 このコマンドは同じビューポートのどんな前の宣言にも完全に取って代わります。 指定されたビューポートの中に既に情報を表示するなら、このコマンドで、スクリーンで表示された情報を新しい位置に移動させます。
If the area specified exceeds the limits of the graphics standard display screen, what happens is left unspecified. Viewports need not be disjoint; in other words, two viewports can present display information at the same point on the screen.
指定された領域がグラフィックス標準表示スクリーンの限界を超えているなら、何が起こるかは不特定のままにされます。 ビューポートはばらばらになることである必要はありません。 言い換えれば、2つのビューポートがスクリーンの同じポイントで表示情報を提示できます。
If <x delta> or <y delta> are negative, the viewport named should be deleted. All information displayed by it shall no longer appear.
<xデルタ>か<yデルタ>が否定的であるなら、指定されたビューポートは削除されるべきです。 それによって表示されたすべての情報はもう現れないものとします。
Because it affects the top level picture, this author feels that this command should not occur as part of a picture or in a subpicture declaration.
それが最高平らな絵に影響するので、この作者は、このコマンドが絵の一部か「副-絵」の宣言で起こるべきでないのを感じます。
*Add subpicture to viewport ("ADDSVW") <identifier> <viewport id>
The subpicture named <identifier> is displayed within the viewport
specified, if it is not already displayed there. (If it is, nothing
is done.) The subpicture must be capable of being called via a full
subpicture call. If the viewport has never been declared via a SETVW
command what happens is left unspecified. (Three possibilities are:
nothing is displayed; the viewport defaults to the whole logical
screen; the human viewer is permitted by the Using Host to specify
the viewport.) If the viewport is subsequently declared, the
subpicture shall be displayed in it. If the subpicture has never be
declared, nothing is displayed for it; when and if it is subsequently
declared, the new definition is displayed in the viewport. More than
one subpicture may be displayed in a single viewport at once.
*「副-絵」が<識別子>と命名したビューポート("ADDSVW")<識別子><ビューポートイド>への「副-絵」がそれが既にそこに表示されないなら指定されたビューポートの中に表示されると言い足してください。 (それがそうなら、何もしません。) 「副-絵」は完全な「副-絵」の呼び出しで呼ぶことができなければなりません。 ビューポートがSETVWコマンドで一度も宣言されたことがないなら、何が起こるかは不特定のままにされます。 (何も表示しません; ビューポートは全体の論理的なスクリーンをデフォルトとします; 3つの可能性は以下の通りであり、人間のビューアーがビューポートを指定するのがUsing Hostによって可能にされます。) 次にビューポートを宣言するなら、それに「副-絵」を表示するものとします。 「副-絵」を一度も申告したことがないなら、それのために何も表示しません。 いつことであるか、そして、次に宣言していて、ビューポートで新しい定義を表示するということであるかどうか。 すぐに、ただ一つのビューポートで1枚以上の「副-絵」を表示するかもしれません。
Because it affects the top level picture, this author feels that this command should not occur as part of a picture or in a subpicture declaration.
それが最高平らな絵に影響するので、この作者は、このコマンドが絵の一部か「副-絵」の宣言で起こるべきでないのを感じます。
*Clear viewport ("CLVW") <viewport id>
All subpictures which have been added with the ADDSVW command to the
viewport specified in this command are removed from it. Thus the
specified viewport contributes nothing to what the human viewer sees.
(After a CLVW, the area of the viewport may not be blank due to
other, non-cleared viewports which overlap it.)
*ビューポート("CLVW")<ビューポートイド>がどれをすべて「副-絵」であるかが明確であるのは、ビューポートへのコマンドがこのコマンドで指定したADDSVWがそれから加えられる状態で取り外されるということです。 したがって、指定されたビューポートは人間のビューアーが見るものに何も寄付しません。 (CLVWの後に、ビューポートの領域はそれを重ね合わせる他の、そして、非クリアされたビューポートのために空白でないかもしれません。)
Because it affects the top level picture, this author feels that this command should not occur as part of a picture or in a subpicture declaration.
それが最高平らな絵に影響するので、この作者は、このコマンドが絵の一部か「副-絵」の宣言で起こるべきでないのを感じます。
Changes to levels 0, 1, 2, and 3 for level 4.
レベル4のためのレベル0、1、2、および3への変化。
Michener, et. al. [Page 19] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [19ページ]RFC493グラフィックスプロトコル1973年4月26日
ERASE -- All viewports are cleared (as in the CLVW command) but their declarations are remembered.
ERASE--すべてのビューポートがクリアされますが(CLVWコマンドのように)、彼らの宣言は覚えていられます。
ENDPIC -- This command partially loses its purpose: it no longer serves to mark the end of all picture information to be presented to the user, since viewport operations may follow which amend or alter the picture. This function is partially taken over by the DELAY and NODELAY commands described below.
ENDPIC--このコマンドは目的を部分的に失います: それは、もうユーザに提示されるすべての絵の情報の終わりを示すのに役立ちません、ビューポート操作が続くかもしれないので(絵を修正するか、または変更します)。 この機能はコマンドが以下で説明したDELAYとNODELAYによって部分的に引き継がれます。
Level ?
レベル?
*Set Character Size ("SETCHS") <x delta> <y delta>.
Until further notice, characters shall be displayed so that each
occupies approximately <x delta> and <y delta> in the appropriate
coordinate direction in the current logical coordinate system.
Inter-character and inter-line spacing could be certain percentages
(any ideas?) more than <x delta> and <y delta>, or they could be
specified separately. In any case, only a "best effort" would be
expected at a site. Character size is always set to normal (as
defined by level 0 character size being normal) by the ERASE command.
<x delta> and <y delta> should be positive, except that if <x delta>
is equal to zero, then <y delta> being negative, zero, or positive,
correspond to a character size which is "smaller than normal",
"normal", or "larger than normal". How much smaller or larger than
normal is left up to the site.
*キャラクターSize(「SETCHS」)<xデルタ><yデルタ>を設定してください。 追って通知があるまで、キャラクタを見せるものとするので、それぞれが現在の論理的な座標系で<xデルタ>と<yデルタおよそ>を適切なコーディネートしている方向に占領します。 インターキャラクタと相互線スペースは<xデルタ>と<yデルタ>よりさらにある割合であるかもしれません(何か考え?)か別々にそれらを指定できました。 「ベストエフォート型だけ」がサイトで予想されるでしょう。 キャラクターサイズはいつもERASEによる通常(レベル0 標準であることのキャラクタサイズによって定義されるように)のコマンドに設定されます。 <xデルタ>と<yデルタ>は積極的であるべきであり、<xデルタ>が次に、<yデルタ>が否定的のゼロのゼロを合わせるために等しいか、または積極的であるなら、それを除いて、「標準より小さい」キャラクタサイズ、「標準」、「標準より大きく」対応してください。 標準よりどれほど小さいか、または大きいのが、サイトに上がっている左です。
Changes to levels 0 and 1 for level ?.
レベルのためのレベル0と1への変化?
TEXTR, TEXT, and TEXTO -- Characters are to be displayed according to the current character size.
TEXTR、TEXT、およびTEXTO--キャラクターは現在のキャラクタサイズに従って表示することです。
ERASE -- Must establish normal character size, normal being that for level 0.
ERASE--標準がそれでありレベル0のために標準のキャラクタサイズを確立しなければなりません。
Level ?'
'レベル?'
*Set Data Length ("SETDLN") <value>.
Until this mode is explicitly changed with another SETDLN, various
data will consist of <value> number of bytes. <value> may be 1, 2, 3,
or 4. Affected are the following syntactic types (refer to Appendix
1): <coordinate>, <x coordinate>, <y coordinate>, <double
coordinate>, <x delta>, <y delta>, <angle>, and the fractional part
of a floating point number. When a network connection is initially
established, the data length is two.
*データの長さ("SETDLN")の<値の>を設定してください。 様々なデータは<値の>バイト数から別のSETDLNと共にこのモードを明らかに変えるまで成るでしょう。 <値の>は1、2、3、または4であるかもしれません。 影響を受けているのは、以下の構文のタイプ(Appendix1を参照する)です: <のコーディネートしている>、<xは浮動小数点の>、<のyコーディネートしている>、<の二重コーディネートしている>、<xデルタ>、<yデルタ>、<角度>、および断片的な部分を調整します。 ネットワーク接続が初めは確立されるとき、データの長さは2です。
Michener, et. al. [Page 20] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [20ページ]RFC493グラフィックスプロトコル1973年4月26日
Level ?''
「レベル?」
(These commands should probably be at the same level as viewport operations, if not earlier.)
(これらのコマンドは、たぶんビューポート操作と同じレベルにあるか、または、より早いはずです。)
*Extensive Changes Follow ("DELAY").
This optional command is designed to eliminate futile effort on the
part of the Using Host programs. At some hosts and/or with some
output devices (particularly storage tubes) a non-negligible amount
of time may be required to present an image to the human viewer. If
extensive changes are going to be made, this command would be used to
prevent the Using Host graphics package from updating the image after
every change. A NODELAY command exits from the DELAY mode and causes
the image to be prepared and presented to the viewer.
*幅広い変更は(「遅れ」)に続いて起こります。 この任意のコマンドは、Using Hostプログラム側の空しい努力を排除するように設計されています。何人かのホストいくつかの出力装置(特に蓄積管)で、非ごく小額の時間が、人間のビューアーにイメージを提示するのに必要であるかもしれません。 幅広い変更が作られるなら、このコマンドは、Using Hostグラフィックスパッケージがあらゆる変化の後にイメージをアップデートするのを防ぐのに使用されるでしょう。 NODELAYコマンドはDELAYモードと原因からビューアーに準備されて、提示されるイメージを出ます。
For example, the current picture may display four subpictures each of which is going to be redefined. Without a DELAY command, the viewer would see successive stages of the change, each possibly involving a large amount of computation or transmission time.
例えば、現在の絵はそれのそれぞれが再定義される4の「副-絵」を表示するかもしれません。 DELAYコマンドがなければ、ビューアーは変化の連続したステージを見るでしょう、ことによるとそれぞれ多量の計算かトランスミッション時間にかかわって。
*End of Extensive Changes ("NODELAY")
This optional command undoes the effect of the DELAY command.
*Extensive Changes("NODELAY")では、この任意のコマンドが遅れコマンドの効果を元に戻す終わり。
Michener, et. al. [Page 21] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [21ページ]RFC493グラフィックスプロトコル1973年4月26日
Appendix 1: BNF for the Graphics Protocol Byte Stream
付録1: グラフィックスプロトコルバイト・ストリームのためのBNF
Key to below: Non-terminals are represented in < >. Terminals which are keywords standing for particular eight-bit values are in capitals. Terminals whose meaning should be clear to the reader are in lower case. Note that "empty_string" means "zero bytes", not "a <string> whose <count> is zero."
以下を下に合わせてください。 非端末は<>に表されます。特定の8ビットの値を表すキーワードである端末が首都にあります。 小文字には読者にとって、意味が明確であるはずである端末があります。 「空の_ストリング」が「<が>を数える<ストリング>はゼロです」ではなく「バイトがありません」を意味することに注意してください。
<graphics output byte stream> ::= empty_string
| <picture> <graphics output byte stream>
| <subpicture declaration> <graphics output byte stream>
| <viewport operation> <graphics output byte stream>
| <transmission control stt> <graphics output byte stream>
<picture> ::= <new picture sst> <program stt group> <end picture stt>
<subpicture declaration> ::= <subpicture header stt> <program stt
group><subpicture end stt>
<viewport operation> ::= <declare viewport stt>
| <add subpicture to viewport stt>
| <clear viewport stt>
<transmission control stt> ::= <set data length stt>
| <extensive changes follow stt>
| <end of extensive changes stt>
<program stt group> ::= empty_string | <program stt <program stt group>
<program stt> ::= <picture control stt> | <display stt> |
<transmission control stt>
<picture control stt> ::= <escape to device stt>
| <escape to highest coordinate system stt>
| <restore coordinate system stt>
| <mark stt>
| <null stt>
| <line mode stt>
| <set intensity stt>
| <subpicture declaration>
| <simple instance stt>
| <full instance stt>
| <set character size stt>
<display stt> ::= <move absolute stt>
| <move relative stt>
| <draw absolute stt>
| <draw relative stt>
| <dot absolute stt>
| <dot relative stt>
| <move to mark and pop stt>
| <draw to mark and pop stt>
<グラフィックスはバイト・ストリーム>を出力しました:、:= 空の_ストリング| <絵の><グラフィックス出力バイト・ストリーム>。| <「副-絵」の宣言><グラフィックス出力バイト・ストリーム>。| <ビューポート操作><グラフィックス出力バイト・ストリーム>。| <転送管理stt><グラフィックスはバイト・ストリーム><絵の>を出力しました:、:= 新しい<の絵のstt><「副-絵」の絵のsst><プログラムsttグループ><終わりの宣言>:、:= <「副-絵」のヘッダーstt><プログラムsttグループ><「副-絵」の終わりのstt><ビューポート操作>:、:= <は、ビューポートがstt>であると宣言します。| <はビューポートstt>に「副-絵」を加えます。| <の明確なビューポートstt><転送管理stt>:、:= <セットデータの長さのstt>。| <幅広い変更はstt>に続いて起こります。| 幅広い変更stt><プログラムsttグループ>の<端:、:= 空の_ストリング| <プログラムstt<プログラムsttグループ><プログラムstt>:、:= <絵のコントロールstt>。| <表示stt>。| <転送管理stt><絵の制御装置stt>:、:= 装置stt>への<エスケープ| 最も高い座標系stt>への<エスケープ| <は座標系stt>を返します。| <マークstt>。| <のヌルstt>。| <ライン・モードstt>。| <セット強度stt>。| <「副-絵」の宣言>。| <の簡単な例のstt>。| <の完全な例のstt>。| <はキャラクタサイズstt><表示stt>を設定しました:、:= <移動の絶対stt>。| <移動親類stt>。| <ドローの絶対stt>。| <ドローの相対的なstt>。| <ドットの絶対stt>。| <ドット親類stt>。| マークする<移動と大衆的なstt>。| マークする<ドローと大衆的なstt>。
Michener, et. al. [Page 22] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [22ページ]RFC493グラフィックスプロトコル1973年4月26日
| <text and restore beam stt>
| <text stt>
| <text out stt>
<new picture stt> ::= ERASE
<end picture stt> ::= ENDPIC
<subpicture header stt> ::= SUBHED <identifier> count> <header info>
<header info> ::= 80-hex | 40-hex | C0-hex
<subpicture end stt> ::= SUBEND
<set viewport stt> ::= SETVW <viewport id> <x coordinate>
<y coordinate> <x delta> <y delta>
<add subpicture to viewport stt> ::= AADSVW <identifier> <viewport id>
<clear viewport stt> ::= CLVW <viewport id>
<extensive changes follow stt> ::= DELAY
<end of extensive changes stt> ::= NODELAY
<escape to device stt> ::= ESCDEV <device code> <string>
<escape to highest coordinate system stt> ::= ESCTOP
<restore coordinate system stt> ::= RESLEV
<null stt> ::= NULL
<mark stt> ::= MARK
<line mode stt> ::= LINMOD <value>
<set character size stt> ::= SETCHS <x delta> <y delta>
<set data length stt> ::= SETDLN <value>
<move absolute stt> ::= MOVEA <x coordinate> <y coordinate>
<move relative stt> ::= MOVER <x delta> <y delta>
<draw absolute stt> ::= DRAWA <x coordinate> <y coordinate>
<draw relative stt> ::= DRAWR <x delta> <y delta>
<dot absolute stt> ::= DOTA <x coordinate> <y coordinate>
<dot relative stt> ::= DOTR <x delta> <y delta>
<move to mark and pop stt> ::= MOVEMK
<draw to mark and pop stt> ::= DRAWMK
<text and restore beam stt> ::= TEXTR <string>
<text stt> ::= TEXT <string>
<text out stt> ::= TEXTO <string>
| <テキスト、ビームstt>を返してください。| <テキストstt>。| 出ている<テキストの><新しい絵のstt stt>:、:= ERASE<終わりの絵のstt>:、:= ENDPIC<「副-絵」のヘッダーstt>:、:= SUBHED<識別子>カウント><ヘッダーインフォメーション><ヘッダーインフォメーション>:、:= 80十六進法| 40十六進法| C0-十六進法<「副-絵」の終わりのstt>:、:= SUBEND<はビューポートstt>を設定しました:、:= SETVW<ビューポートイド><x座標><y座標><xデルタ><yデルタ><はsubpictureにビューポートstt>に以下を加えます:= AADSVWのビューポートのイドの>の<の明確な<識別子><ビューポートstt>:、:= CLVW<ビューポートイド><幅広い変更はstt>に続いて起こります:、:= 幅広い変更stt>のDELAY<端:、:= NODELAY<は装置stt>に以下から逃げます:= ESCDEV<デバイス・コード><ストリング><は最も高い座標系stt>に以下から逃げます:= ESCTOP<は座標系のstt>を返します:、:= RESLEVの<のヌルstt>:、:= NULL<マークstt>:、:= マーク<ライン・モードstt>:、:= LINMOD<値の><はキャラクタサイズstt>を設定しました:、:= SETCHS<xデルタ><yデルタ><セットデータの長さのstt>:、:= SETDLN<値の><移動の絶対stt>:、:= MOVEA<x座標><y座標><移動親類stt>:、:= MOVER<xデルタ><yデルタ><ドローの絶対stt>:、:= DRAWA<x座標><y座標><ドローの相対的なstt>:、:= DRAWR<xデルタ><yデルタ><ドットの絶対stt>:、:= DOTA<x座標><y座標><ドット親類stt>:、:= DOTR<xデルタ><yデルタ><は以下をマークと大衆的なstt>に動かします:= MOVEMK<はマークと大衆的なstt>に以下を引き込みます:= そして、DRAWMK<テキスト、ビームstt>を返してください:、:= TEXTR<ストリング><テキストstt>:、:= TEXT<ストリング><テキストの出ているstt>:、:= TEXTO<ストリング>。
<simple instance stt> ::= INST <identifier> <simple instance tail>
<full instance stt> ::= INSTF <identifier> <full instance tail>
<simple instance tail> ::= eight_bits_of_binary_0
| <count> <tail code> <as clause> <at clause>
<tail code> ::= bit_pattern_indicating_what_clauses_follow
<full instance tail> ::= eight_bits_of_binary_0
| <count> <tail code> <as clause> <at clause>
<rotation clause> <portion clause>
<uniform magnification clause>
<separate magnification clause> <image size
clause> <complete transformation clause>
<as clause> ::= empty_string | <identifier>
<at clause> ::= empty_string | <x coordinate> <y coordinate>
<rotation clause> ::= empty_string | <angle>
<の簡単な例のstt>:、:= INSTの識別子の>の<の簡単な例の<テール>の<の完全な例のstt>:、:= INSTFの識別子の>の<の完全な例の<テール>の<の簡単な例のテール>:、:= _バイナリー_0の8_ビット_| 節><テールコード>の節><としての<カウント><テールコード><:、:= _どんな_節_が<の完全な例のテール>に続くかを示すビット_パターン_:、:= _バイナリー_0の8_ビット_| 節>としての一定の別々の節の節><完全な変化><回転節><部分節><倍率節><倍率節><画像寸法節><の節><としての<カウント><テールコード><:、:= 空の_ストリング| 節>の<識別子><:、:= 空の_ストリング| <x座標><y座標><回転節>:、:= 空の_ストリング| <角度>。
Michener, et. al. [Page 23] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [23ページ]RFC493グラフィックスプロトコル1973年4月26日
<portion clause> ::= empty_string | <x coordinate> <y coordinate>
<x delta> <y delta>
<uniform magnification clause> ::= empty_string |floating point number>
<separate magnification clause> ::= empty_string |
<floating point number> <floating point number>
<image size clause> ::= empty_string | <x delta> <y delta>
<complete transformation clause> ::= empty_string | six_<floating point
number>'s
<部分節>:、:= 空の_ストリング| <のデルタの>の<の一定の倍率x座標><y座標><xデルタ><y節>:、:= 空の_ストリング|浮動小数点の>の<の別々の倍率節>:、:= 空の_ストリング| <浮動小数点><浮動小数点><画像寸法節>:、:= 空の_ストリング| <のデルタの>の<の完全な変化xデルタ><y節>:、:= 空の_ストリング| 6_<浮動小数点>のもの
<angle> ::= 16-bit_non-negative_fractional_part_of_a_circle
<x coordinate> ::= <coordinate>
<y coordinate> ::= <coordinate>
<x delta> ::= <double coordinate>
<y delta> ::= <double coordinate>
<coordinate> ::= signed,_two_s-complement,_fraction_in_range
-1/2_to_less_than_+1/2
<double coordinate> ::= signed,_two_s_complement,_fraction,
range _strictly_between_-1_and_+1
<floating point number> ::= network_standard_floating_point
number_if_any
| 8-bit_two_s_complement_exponent_part and a
16-bit_two_s_complement_fraction_part <count>
::= 7-bit_non-negative_integer
| 15-bit_non-negative_integer_represented_in
"excess_2**15"_notation
<string> ::= <count> count_8-bit_bytes
<identifier> ::= <count> count_upper_case_letters_or_numbers
<viewport id> ::= <identifier>
<device code> ::= 8-bit_integer
<value> ::= 8-bit_integer
<角度>:、:= 16ビットの_、非、-負の_断片的な_パート_of_a_円の<xは>を調整します:、:= <のコーディネートしている><yコーディネートしている>:、:= <のコーディネートしている><xデルタ>:、:= <の二重コーディネートしている><yデルタ>:、:= <の二重コーディネートしている><コーディネートしている>:、:= _サインされていて、2_s-補数、__+1/2<より少ない_への_断片_コネ_範囲1/2_はコーディネートしている>を倍にします:、:= サインされた_2_s_補数、_断片が_間に_厳密に及ぶ、_-1_と_+1<浮動小数点>:、:= __いずれかであるなら_標準の_浮いている_ポイント番号をネットワークでつないでください。| 8ビットの_2_s_補数_解説者_部分と16ビットの_two_s_は_断片_パート<カウント>の補足となります:、:= 7ビットの_、非、-、負の_整数| 15ビットの_、非、-負の_整数_が中に_を表した、「過剰_2**15インチ_記法<ストリング>:、:、」= <カウント>カウント_の8ビット_バイトの<識別子>:、:= <カウント>カウントの_の上側の_ケース_手紙の_か_数の<ビューポートイド>:、:= <識別子><デバイス・コード>:、:= 8ビットの_整数<価値の>:、:= 8ビットの_整数
Appendix 2. Mathematical Formulae for Subpictures
付録2。 Subpicturesにおける数学の公式
Transformations
変化
In this appendix positions in a logical coordinate system will be represented by a row vector with two elements, as in /_ x y_/. Vectors and matrices will be delimited by these funny brackets: /_ _/. Various symbols will be used to represent parameters in a full subpicture call relating to a transformation from one coordinate system to another; these are defined below:
この付録では、論理的な座標系の位置は列のベクトルによって2つの要素で表されるでしょう、/_x y_/のように。ベクトルとマトリクスはこれらのおかしい括弧によって区切られるでしょう: /_ _/様々なシンボルは1個の座標系から別の座標系までの変化に関連する完全な「副-絵」の呼び出しにおけるパラメタを表すのに使用されるでしょう。 これらは以下で定義されます:
Mx and My : magnifications in x and y to be applied before any
rotation.
They may be negative indicating reflection.
A: an angle of rotation in the range 0 to just less than 2pi.
/_ |cx |cy_/ : the center (in the calling picture) of the image of the
subpicture.
そして、Mx、私、: どんな回転前にも適用されるべきxとyの倍率。 彼らは、反射を示しながら、否定的であるかもしれません。 A: 2piまさしく以下への範囲0の回転角。 /_ |cx|cy_/: 「副-絵」のイメージのセンター(呼ぶことの絵の)。
Michener, et. al. [Page 24] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [24ページ]RFC493グラフィックスプロトコル1973年4月26日
|sx |sy : the half-sizes, in the x and y directions, of the
image on the calling page in terms of the calling page's
coordinate system.
They may be negative to indicate reflection.
/_ x y_/ : a position on the called page.
/_ |x |y_/ : the position on the calling page corresponding to /_x y_/.
/_ Pcx Pcy_/ : The center of the portion of the called subpicture's
coordinate system which is to be mapped to the calling
page.
This defaults to /_ 0 0_/ if not specified.
Psx and Psy : The half-sizes in x and y of the portion of the
subpicture to be mapped. These both default to +1/2
in not specified.
| sx|sy: xの半切と呼んでいるページ座標系に関する呼ぶページのイメージのy指示。 彼らは、反射を示すために否定的であるかもしれません。 /_x y_/: 呼ばれたページの見解。 /_ |x|y_/: /_x y_//_Pcx Pcy_/に対応する呼ぶページの見解: 呼ぶページに写像されることになっている呼ばれた「副-絵」の座標系の一部の中心。 指定されないなら、これは/_0 0_/をデフォルトとします。 PsxとPsy: 写像するべき「副-絵」の一部のxとyの半切。 これらはともに指定されないところの+1/2をデフォルトとします。
(If a uniform magnification is specified, set Mx and My equal to it and proceed below as if they were specified.)
(一定の倍率が指定されるなら、それと等しいMxとMyを設定してください、そして、まるでそれらが指定されるかのように以下で続いてください。)
If magnifications are specified, the following holds:
倍率が指定されるなら、以下は成立します:
/_ |x |y_/ = (/_ x y_/ - /_ Pcx Pcy_>) * / Mx/Psx 0 / *
/_ 0 My/Psy_/
/_ |x|y_/=(/_x y_/--_/Pcx Pcy_>)*/ Mx/Psx0/*/_0My/Psy_/
/ cos 0 sin 0 / * / 1/2 0 / + /_ |cx |cy_/
/_ -sin0 cos0_/ /_ 0 1/2_/
/cos0罪0/*の/ 1/2 0 /+/_|cx|cy_//_-sin0 cos0_//_0 1/2_/
or in other words,
または、言い換えれば。
1)
/_|x |y_/ = /_ x-Pcx y-Pcy_/ * / Mx cosA/2Psx Mx sinA/2Psx /
/_ -My sinA/2Psy My cosA/2Psy_/
+/_ |cx |cy_/
1) /_|x|y_/=/_x-Pcx y-Pcy_/*/Mx cosA/2Psx Mx sinA/2Psx / /_、-、私、sinA/2Psy My cosA/2Psy_/+/_|cx|cy_/
(The factor of 1/2 is necessary because, for instance, (x-Pcx)/Psx ranges from -1 to +1 for x values within the portion (i.e., such that |x-Pcx| <|Psx| ) whereas the image, in the calling subpicture's coordinate system, should only range from -1/2 to +1/2.)
(例えば、(x-Pcx)/Psxが部分の中のx値のために-1〜+1まで及ぶので(それ| すなわち、そのようなx-Pcx|<|Psx|)、1/2の要素が必要ですが、呼んでいる「副-絵」の座標系では、イメージは-1/2〜+1/2まで及ぶだけであるべきです。)
If the image size is specified instead of the magnification, we have the following:
画像寸法が倍率の代わりに指定されるなら、私たちには、以下があります:
/_ |x |y_/ = (/_ x y_/ - /_Pcx Pcy_/) * / 1/Psx 0 / *
/_ 0 1/Psy _/
/_ |x|y_/=(/_x y_/--/_Pcx Pcy_/)*/ 1/Psx0/*/_0 1/Psy_/
/ cosA sinA / * / |sx 0 / + /_ |cx |cy_/
/_ -sinA cosA _/ /_ 0 |sy _/
/ cosA sinA /*/|sx0/+/_|cx|cy_//_-sinA cosA_//_0|sy_/
Michener, et. al. [Page 25] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [25ページ]RFC493グラフィックスプロトコル1973年4月26日
or, in other words,
または、言い換えれば。
2)
/_|x |y_/ = /_x-Pcx y-Pcy_/ * /|sx cosA/Psx |sy sinA/Psx /
/_-|sx sinA/Psy |sy cosA/Psy_/
2) /_|x|y_/=/_x-Pcx y-Pcy_/*/|sx cosA/Psx|sy sinA/Psx / /_、-|sx sinA/Psy|sy cosA/Psy_/
+ /_|cx |cy_/
+ /_|cx|cy_/
Expanding the parenthesized quantities in equations 1) and 2), we have:
方程式1と)2)でparenthesized量を広げて、私たちには以下があります。
3a) /_|x |y_/ = /_x y_/ * /Mx cosA/2Psx Mx sinA/2Psx /
/_-My sinA/2Psy My cosA/2Psy_/
3a) /_|x|y_/=/_x y_/*/Mx cosA/2Psx Mx sinA/2Psx / /_、-、私のsinA/2Psy My cosA/2Psy_/
+ /_|cx-PcxMxcosA/2Psx+PcyMysinA/2Psy
|cy-PcxMxsinA/2Psx-PcyMycosA/2Psy _/
+ /_|cx-PcxMxcosA/2Psx+PcyMysinA/2Psy|cy-PcxMxsinA/2Psx-PcyMycosA/2Psy_/
and
そして
3b) /_|x |y_/ = /_x y_/ * /|sx cosA/Psx |sy sinA/Psx /
/_-|sx sinA/Psy |sy cosA/Psy_/
3b) /_|x|y_/=/_x y_/*/|sx cosA/Psx|sy sinA/Psx / /_、-|sx sinA/Psy|sy cosA/Psy_/
+ /_|cx-Pcx|sxcosA/Psx+Pcy|sxsinA/Psy
|cy-Pcy|sysinA/Psx-Pcy|sycosA/Psy_/
+ /_|cx-Pcx|sxcosA/Psx+Pcy|sxsinA/Psy|cy-Pcy|sysinA/Psx-Pcy|sycosA/Psy_/
Various interesting substitutions can be made in 3a) and 3b). For example, if A=0 (no rotation), then we have:
3a)と3bで代替をすることができる様々な関心があること) 例えば、私たちには以下がA=0(回転がない)であるならあります。
4a) /_|x |y_/ = /_x y_/ * /Mx/2Psx 0 / + /_|cx-PcxMx/2Psx
|cy-PcyMy/2Psy_/
/_ 0 My/2Psy_/
4a) /_|x|y_/=/_x y_/*/Mx/2Psx0/+/_|cx-PcxMx/2Psx|cy-PcyMy/2Psy_//_0 私の/2Psy_/
4b) /_|x |y_/ = /_x y_/ * /|sx/Psx 0 / + /_|cx-Pcx|sx/Psx
|cy-Pcy|sy/Psy_/
/_ 0 |sy/Psy_/
4b) /_|x|y_/=/_x y_/*/|sx/Psx0/+/_|cx-Pcx|sx/Psx|cy-Pcy|sy/Psy_//_0|sy/Psy_/
Another example is if no portioning is done (Pcx=Pcy=0, Psx=Psy=1/2):
別の例は(Pcx=Pcy=0、Psx=Psy=1/2)を部分でないのにするかどうかということです:
5a) /_|x |y_/ = /_ x y_/ * /Mx cosA Mx sinA / + /_|cx |cy_/
/_-My sinA My sinA_/
5a) /_|x|y_/=/_x y_/*/Mx cosA Mx sinA/+/_|cx|cy_//、_、-、私、sinA My sinA_/
5b) /_|x |y_/ = /_ x y_/ * /2|sx cosA 2|sy sinA / + /_|cx |cy_/
/_-2|sx sinA 2|sx cosA_/
5b) /_|x|y_/=/_x y_/*/2|sx cosA2|sy sinA/+/_|cx|cy_//_-2|sx sinA2|sx cosA_/
Michener, et. al. [Page 26] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [26ページ]RFC493グラフィックスプロトコル1973年4月26日
If in addition, 0=0, we have:
さらにと、0=0であるなら、私たちには以下があります。
6a) /_|x |y_/ = /_ xMx+|cx yMy+|cy_/
6a) /_|x|y_/=/_xMx+|cx yMy+|cy_/
6b) /_|x |y_/ = /_ x*2|sx+|cx y*2|sy+|cy_/
6b) /_|x|y_/=/_x*2|sx+|cx y*2|sy+|cy_/
Of course, in all cases, the transformation from /_x y_/ to /_|x |y_/ can be written in the form:
もちろんすべての場合の/_x y_/から/_までの変化|x|フォームにy_/を書くことができます:
/_|x |y_/ = /_x y_/ * / 2 by 2 / + /_ translation _/
/_ matrix _/
/_|x|y_/=/_x y_/*/2 2×/+/_翻訳_//_マトリクス_/
In general, a transformation combining a linear transformation and a translation is called an affine transformation.
一般に、一次変換と翻訳を結合する変化はアフィン変換と呼ばれます。
Transformations with Nested Levels
入れ子にされたレベルとの変化
The combination of two affine transformations is again an affine transformation. Indeed, if
再び、2つのアフィン変換の組み合わせはアフィン変換です。 本当に
/_|x |y_/ = /_x y_/ * / Mat1 / + /_ Tran1 _/
/_ _/
and
/_|x|そしてy_/=/_x y_/*/ Mat1 /+/_Tran1_//_ _/。
/_|x_ |y__/ = /_|x |y_/ * ( / Mat1 / * / Mat2 /)
/_ _/ /_ _/
+ (/_ Tran2 _/ + /_ Tran1 _/ * / Mat2 /)
/_ _/
/_|x_|y__/=/_|x|y_/*(/ Mat1 /*/ Mat2 /)/_ _//_ _/+(/_Tran2_/+/_Tran1_/*/ Mat2 /)/_ _/
Thus if one has nested full subpicture calls, the data at any level need be transformed only once, namely, by the transformation which is the combination of the single step transformations at each level of nesting. A new "grand combination" affine transformation should be computed whenever a full subpicture is called (after pushing down the current transformation) by combining the current grand combination with the affine transformation for this particular subpicture call.
したがって、あるものが完全な「副-絵」の呼び出しを入れ子にしたなら、すなわち、どんなレベルでもデータはそれぞれのレベルの巣篭もりでシングルステップ変化の組み合わせである変化で一度だけ変えられなければなりません。 完全な「副-絵」がこの特定の「副-絵」の呼び出しのためのアフィン変換への現在の壮大な組み合わせを結合することによって呼ばれる(変流を押し下げた後に)ときはいつも、新しい「壮大な組み合わせ」アフィン変換は計算されるべきです。
Portions with Nested Levels
入れ子にされたレベルがある部分
As long as no rotations are involved, or even only rotations in multiples of pi/2, then multiple levels of portions are easy to implement. In the discussion in the next two paragraphs let us assume that no rotations other than whole multiples of pi/2 are involved.
どんな回転もかかわらないか、またはパイ/2の倍数における回転だけさえ、その時が複数である限り、部分のレベルは実行しやすいです。 次の2つのパラグラフにおける議論では、パイ/2の全体の倍数以外の回転が全くかかわらないと仮定しましょう。
Just as one can keep track of a "grand combination" affine transformation, so can one keep a grand combination of portions. At each level, one can proceed as follows: Save a copy of the current
ちょうど1つが「壮大な組み合わせ」アフィン変換の動向をおさえることができるように、1つは部分の壮大な組み合わせを保つことができます。 各レベルでは、1つは以下の通り続くことができます: 電流のコピーを保存してください。
Michener, et. al. [Page 27] RFC 493 GRAPHICS PROTOCOL 26 April 1973
etミッチェナー、アル。 [27ページ]RFC493グラフィックスプロトコル1973年4月26日
grand portion, and use the inverse of the single level affine transformation (specified in the subpicture call) to determine what rectangle of the called page corresponds to the current grand portion (on calling page).
グランドピアノは、呼ばれたページのどんな長方形が現在の壮大な部分(ページと呼ぶときの)に対応するかを決定するのにただ一つの平らなアフィン変換(「副-絵」の呼び出しでは、指定される)の逆を分配して、使用します。
Various relations may exist between this rectangle and the rectangle specified (or defaulted) in the subpicture call. They may be disjoint (in which case this subpicture need not be called at all); they may be equal (an easy case); one may contain the other or they may partially overlap. If there is any intersection, it will be a rectangle, and this rectangle becomes the new grand combination portion.
様々な関係は「副-絵」の呼び出しで指定された(または、デフォルトとします)この長方形と長方形の間に存在するかもしれません。 それらはばらばらになることであるかもしれません(その場合、この「副-絵」は全く呼ばれる必要はありません)。 それらは等しいかもしれません(簡単なケース)。 もう片方を含むかもしれませんか、またはそれらは部分的に重なるかもしれません。 何か交差点があると、長方形になるでしょう、そして、この長方形は新しい壮大な組み合わせ部分になります。
The problem with rotations other than multiples of pi/2 is that the inverse image of the rectangle is no longer in the standard orientation (vertical and horizontal edges). This means that its intersection with the portion specified on the subpicture call may have 3, 4, 5, 6, 7, or 8 edges (if it is non-empty). Deeper levels may get even worse if they involve rotations too. While there may be no conceptual difficulty (for some) in working with such a situation, significantly more computation is involved than in the simple horizontal and vertical edge case.
パイ/2の倍数以外の回転に関する問題はもういずれの標準のオリエンテーション(垂直で水平な縁)でも長方形の逆さのイメージがないということです。 これは、部分が「副-絵」の呼び出しのときに指定されている交差点には3、4、5、6、7、または8つの強味があるかもしれないことを意味します(それが非空であるなら)。 回転にもかかわるなら、より深いレベルはさらに悪くなるかもしれません。 そのような状況で働くのにおいてどんな概念的な困難もないかもしれない間(いくつかのために)、かなり多くの計算が簡単な水平で垂直な縁のケースよりかかわります。
This protocol puts forward no recommendation in the case that rotations other than whole multiples of pi/2 are involved with portions. It does suggest that nested portions be handled as described above in the more straightforward case.
パイ/2の全体の倍数以外の回転が部分にかかわって、このプロトコルは推薦を全く進めません。 それは、入れ子にされた部分が上で、より簡単な場合で説明されるように扱われるのを示します。
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Helene Morin, Via Genie, 12/1999]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリン、Via GenieによるオンラインRFCアーカイブへの12/1999]
Michener, et. al. [Page 28]
etミッチェナー、アル。 [28ページ]
一覧
スポンサーリンク
