RFC292 日本語訳
0292 Graphics Protocol: Level 0 only. J.C. Michener, I.W. Cotton, K.C.Kelley, D.E. Liddle, E. Meyer. January 1972. (Format: TXT=22342 bytes) (Obsoleted by RFC0493) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group 12 January 1972 Request for Comment: 292 Jim Michener, MAC NIC 8302 Ira Cotton, MITRE References: 282, 285 Karl Kelley, U. of Ill. Updates: None Dave Liddle, Owens Ill. Obsoletes: None Ed Meyer, MAC
コメントを求めるワーキンググループ1972年1月12日の要求をネットワークでつないでください: 292 ジム・ミッチェナー、MAC NIC8302イラCotton、斜め継ぎ参照: 282 285 カール・ケリー、イリノイ州のU. アップデート: デーヴLiddle、オーエンスイリノイ州のいずれも 時代遅れにします: なにも、エド・マイヤー、MAC
GRAPHICS PROTOCOL - LEVEL 0 ONLY
グラフィックスプロトコル--レベル0だけ
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. In particular, only the simplest forms of graphics data will be covered in this, the first version of this document. The next version, already in preparation, will be much more complete. In any case this is not intended to describe a finished protocol; rather it should serve as a basis for graphics experimentation on the network.
このドキュメントは11月の1971下旬にスタンフォード大学人工知能研究所で持たれていたNetwork Graphics Groupの2番目のミーティングで達した述べられた意見と決定を反映します。 それは、ARPAネットワークの中でグラフィックスデータを送るために提案されたNetwork Standard Graphicsプロトコルの一部について説明します。 本書ではカバーされたプロトコルの特定の局面はグラフィカルな情報(たとえば「給仕のホスト」のアプリケーション・プログラム)の源から出力のための表示パッケージに送られたグラフィックス情報のフォームと内容にグラフィックスコンソール(「使用しているホスト」の)に関連します。 これは、8ビットのバイトの系列の形を取って、グラフィックス出力バイト・ストリームと呼ばれるでしょう。 グラフィックスのデータが覆われたコネがこれであったならそうする中で最も簡単なフォーム、このドキュメントの最初のバージョンだけ。 既に準備では、次のバージョンははるかに完全になるでしょう。 どのような場合でも、これが終わっているプロトコルについて説明することを意図しません。 むしろそれはネットワークにおけるグラフィックス実験の基礎として機能するべきです。
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 package 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 intergrated with the graphics _input_ byte stream, since it involves most of the problems related to synchrony of independent hosts.
施設が全くUsing Hostがグラフィックス出力バイト・ストリームで論理的な誤りをServing Hostに報告できるこのプロトコルで指定されないのが読者によって観測されるかもしれません。 そのような施設はグラフィックス_入力_バイト・ストリームによってintergratedされなければならないでしょう、独立しているホストの同期に関連する問題の大部分にかかわるので。
Michener [Page 1] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[1ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
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でモデルの注意について説明させるのも貴重であるかもしれません: ドナルドが「ネットワークグラフィックス」は立腹します。
LEVEL 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 incremently. 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 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 low numbered level will still work at sites which have moved on to implement higher levels. Additionally, any aspects 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.
さらなる1つの基本規則: 与えられたレベルで有効なコマンドとデータのストリーム(K)は「同じ」結果をレベルKのどんなインタプリタか、より高く生むものとします。 これで、私たちは、定義された操作として、同様の絵が結果として生じるはずであると言っています。 (このとき)厳密に定義されないプロトコルの局面はキャラクタサイズを含んでいます、ビームに比例した欄、テキスト出力における制御文字がどう論理的なスクリーン境界の外に描かれた端末とビームが動かされるとき起こることか線に影響するか。 この規則は上向きに互換性を強制します、それでも、低番号付のレベルの特徴を使用することで書かれたアプリケーションが、より高いレベルを実行するために移動したサイトで動作するように。 さらに、実際の実現のどんな公共の記述でも指定されて、どれが明らかにそうであるかが以下の_がそうする詳細な操作記述で「不特定の状態で、いなくなった」というこのプロトコル_のどんな局面も明らかにそうです。
We now describe the framework which will be common to all levels.
私たちは現在、すべてのレベルに共通になる枠組みについて説明します。
Michener [Page 2] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[2ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
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 an 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.
純真なタイプの議論は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 make his own decision, but it is recommended that the largest possible _square_ area be utilized.) 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よりもう少しまで及ぶポイントを含むと言うつもりです。
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
座標データを取るコマンドが様々なモードで利用可能になるでしょう。 絶対モードで、位置は、Logical Coordinate Systemの座標を与えることによって、指定されます。 相対的なモードで、位置の座標と現在の位置の座標の間の_差の_を指定しなければなりません。 その結果、a
Michener [Page 3] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[3ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
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.
+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 had no "normal" size, 72 characters per line would be desirable. Later, variable character size may be introduced.
テキストデータは表示のための様々なコマンドの議論として出力装置で送られるでしょう。 ネットワーク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.
また、最も低いレベルでは、制御文字は、尽くすことができるベストを尽くすために装置に回されるでしょう。 しかしながら、ミーティングが(非ゼロだけ)がいくつかでは、合理的に低く、復帰、改行を平らにして、バックスペースキーを押して印字位置を一字分戻るということであったというグラフィックスのコンセンサスは、正しいことをするために解釈されるべきです。
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の異なった評価基準、強調において異なったそれぞれの評価基準があります。 このゴーディアン・ノットは切られるでしょう、この提案で、レベルに従って周囲でコマンドを注文して、次に、ただそれらに付番することによって。 さらに、いくつかの密接に関係づけられたコマンドが同じレベルで起こると、ビット構成に関して意味の変化をコード化するのを何らかの試みをするでしょう。 何らかの後の考慮で注文における変化を提案してもさえ、それはこの委員会が、付番が変更されるべきでないと感じることです。 しかしながら、この件がしっかり決着するまで、どんな実現もコマンドコードの再割当ての可能性を考慮に入れると強く忠告されます。
Michener [Page 4] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[4ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
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 hosts and even programmable terminals should be able to implement it. In accordance with this, the "rule" was made that a command be implemented only if the 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を要求します。)
(As described in Basic Data Forms, above, <x>, <y>, <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.)
(上でBasic Data Formsで<x>について説明するので、<y>、<xデルタの>と<yデルタ>は2バイトの座標値であり、<ストリング>は多くの(数えます)バイトがいうことになったカウントであり、<値の>は8ビットの数です。)
Decimal Octal Binary Format
10進8進バイナリフォーマット
0 0 00000000 Null 1 1 00000001 Erase screen and reset beam 2 2 00000010 Move Absolute <x> <y> 3 3 00000011 Move Relative <x> <y> 4 4 00000100 Draw Absolute <x> <y> 5 5 00000101 Draw Relative <x delta> <y delta> 6 8 00000110 Dot Absolute <x> <y> 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>
0 0の00000000のヌル1 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 8 00000110ドットAbsolute<x><y>7 7 00000111Dot Relative<xデルタ><yデルタ>8 10 00001000Text<ストリング>9 11 00001001TextR<はPicture11 13 00001011Escape<値の><ストリング>の>10 12 00001010Endを結びます。
Michener [Page 5] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[5ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
LEVEL 0: COMMAND DESCRIPTIONS
レベル0: コマンド記述
0 Null Statement ("null")
This statement has no arguments and no effect, either.
0 議論と少しもいいえがこの声明で作用しないヌルStatement(「ヌル」。)
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
("Move Absolute") <x coordinate> <y coordinate>.
Nothing is drawn; the beam is positioned to the specified absolute
x,y position.
2は目につかないほどビームを絶対位置(「絶対で、動く」)のコーディネートしている><yコーディネートしている<x>に動かします。 何も描かれません。 ビームは指定された絶対的なものx、y位置に置かれます。
3 Move beam invisibly by relative amount
("Move Relative") <x delta> <y delta>.
Nothing is drawn; the beam is shifted by the specified amount in x
and y.
3は親類量(「親類を動かす」)の<xデルタ><yデルタ>で目につかないほどビームを動かします。 何も描かれません。 ビームはxとyで一定金額によって移動させられます。
4 Draw line to absolute position
("Draw Absolute") <x coordinate> <y coordinate>.
A line is drawn from the current beam position to the specified
absolute x, y position.
4は絶対位置(「絶対で、描く」)のコーディネートしている><yコーディネートしている<x>に線を引きつけます。 指定された絶対的なものxへのビーム位置、y位置から線を得ます。
5 Draw line to relative position
("Draw Relative") <x delta> <y delta>.
A line is drawn from the current beam position to the position
delta x and delta y away.
5は親類位置(「親類を描く」)の<xデルタ><yデルタ>に線を引きつけます。 線は遠くのビーム位置からポジションデルタxとデルタyまで描かれます。
6 Display a Dot at absolute position
("Dot Absolute") <x coordinate> <y coordinate>.
The beam is moved invisibly to absolute position x, y and a dot is
displayed there.
6は(「ドット絶対」)の絶対位置のコーディネートしている><yコーディネートしている<x>にDotを表示します。 目につかないほどビームを絶対位置x、yに動かします、そして、そこにドットを表示します。
7 Display a Dot at Relative position
("Dot Relative") <x delta> <y delta>.
The beam is moved invisibly by the specified amount in x and y and
a dot is displayed there.
7はRelative位置(「ドット親類」)の<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
8 表示テキスト(「テキスト」)<は>を結びます。 ビーム位置では、操作される装置のために標準サイズで何人かのキャラクタを見せてください。 <ストリング>はカウント多くのキャラクタによって後をつけられた<カウント>から成ります。 「標準サイズ」が全くなければ、線単位で72のキャラクタを見せるようにサイズを選んでください。 ストリングのキャラクタはネットワークASCIIでコード化されます: 0と127(10進)の間で包括的なすべてのコードが受入れられます。 (レベルゼロでは、制御文字に起こることはそうです。
Michener [Page 6] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[6ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
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.
不特定のままにされます。) このコマンドの実行に続いて、ビームがどこにあるかは不特定のままにされ、すぐに続いて、別の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 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.
11は装置詳細("Escdev")<値の><ストリング>に逃げます。 「値」が操作される装置に割り当てられた(プロトコルCommittee)コードであるなら、それらを調べないで、<ストリング>(バイト数を示す<カウント>から始まる)で8ビットのバイトを装置に伝えてください。 さもなければ、このコマンドを無視してください。 装置は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 scopes(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
さらに、別の造の端末でaが同様になると仮定してください。
Michener [Page 7] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[7ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
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を送るかもしれません。
Michener [Page 8] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[8ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
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," and not "a <string> whose <count> is zero".
以下を下に合わせてください。 非端末は<>に表されます。特定の8ビットの値を表すキーワードである端末が首都にあります。 小文字には読者にとって、意味が明確であるはずである端末があります。 「空の_ストリング」が「<が>を数える<ストリング>はゼロです」ではなく「バイトがありません」を意味することに注意してください。
<graphics output byte stream> ::= empty_string
| <picture> <graphics output byte stream>
<picture> ::= <new picture stt> <sttgroup> <end stt>
<stt group> ::= empty_string | <stt> <stt group>.
<stt> ::= <control stt> | <display stt>
<control stt> ::= <escape to device stt>
| <null stt>
<display stt> ::= <move absolute stt>
| <move relative stt>
| <draw absolute stt>
| <draw relative stt>
| <dot absolute stt>
| <dot relative stt>
| <text and restore beam stt>
| <text stt>
<グラフィックスはバイト・ストリーム>を出力しました:、:= 空の_ストリング| <絵の><グラフィックスはバイト・ストリーム><絵の>を出力しました:、:= 新しい<のstt><sttグループ絵のstt><sttgroup><終わりの>:、:= 空の_ストリング| <stt><sttグループ>。 <stt>:、:= <コントロールstt>。| <表示stt><コントロールstt>:、:= 装置stt>への<エスケープ| ヌル<のstt><表示stt>:、:= <移動の絶対stt>。| <移動親類stt>。| <ドローの絶対stt>。| <ドローの相対的なstt>。| <ドットの絶対stt>。| <ドット親類stt>。| <テキスト、ビームstt>を返してください。| <テキストstt>。
<new picture stt> ::= ERASE
<escape to device stt> ::=ESCDEV <device code> <string>
<null stt>::= NULL
<end stt>::= ENDPIC
<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>
<text and restore beam stt> ::= TEXTR <string>
<text stt> ::= TEXT <string>
<x coordinate> ::= <coordinate>
<y coordinate> ::= <coordinate>
<x delta> ::= <double coordinate>
<y delta> ::= <double coordinate>
<coordinate> ::= singed,_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
<の新しい絵のstt>:、:= ERASE<は装置stt>に以下から逃げます:=ESCDEV<デバイス・コード><ストリング><ヌルstt>:、:= NULL<終わりのstt>:、:= ENDPIC<移動の絶対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>を返してください:、:= TEXTR<ストリング><テキストstt>:、:= TEXT<ストリング><x座標>:、:= <のコーディネートしている><yコーディネートしている>:、:= <のコーディネートしている><xデルタ>:、:= <の二重コーディネートしている><yデルタ>:、:= <の二重コーディネートしている><コーディネートしている>:、:= _表面を焼かれて、2補数、__+1/2<より少ない_への_断片_コネ_範囲1/2_はコーディネートしている>を倍にします:、:= サインされていて、_2_補数、_断片が_間に_厳密に及ぶ、_-1の_と_+1
Michener [Page 9] RFC 292 Graphics Protocol Level 0 January 1972
ミッチェナー[9ページ]RFC292グラフィックスプロトコルレベル0 1972年1月
<count ::= 7-bit_non-negative_integer
| 15-bit_non-negative_integer_represented_in
"excess_2**15"_notation
<string> ::= <count> count_8-bit_bytes
<device code> ::= <value>
<value> ::= 8-bit_integer
<は以下を数えます:= 7ビットの_、非、-、負の_整数| 15ビットの_、非、-負の_整数_が中に_を表した、「過剰_2**15インチ_記法<ストリング>:、:、」= <カウント>カウント_の8ビット_バイトの<デバイス・コード>:、:= <値の><値の>:、:= 8ビットの_整数
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Kelly Tardif, Viag駭ie 10/99]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ケリーTardifによるオンラインRFCアーカイブへのViag駭ie10/99]
Michener [Page 10]
ミッチェナー[10ページ]
一覧
スポンサーリンク
