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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

cron設定ファイルの実体の保存先

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る