RFC553 日本語訳
0553 Draft design for a text/graphics protocol. C.H. Irby, K. Victor. July 1973. (Format: TXT=35414 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Irby
Request for Comments: 553 K. Victor
NIC: 17810 SRI-ARC
14 July 1973
コメントを求めるワーキンググループC.イルビーの要求をネットワークでつないでください: 553 K.ビクタNIC: 17810 様アーク1973年7月14日
Draft design for a text/graphics protocol
テキスト/グラフィックスプロトコルのための草稿デザイン
DRAFT DESIGN FOR A TEXT/GRAPHICS PROTOCOL
テキスト/グラフィックスプロトコルのための草稿デザイン
This proposal should be seen as a synthesis of existing ideas rather than an attempt to put forth new ones. It is based on work by the NGG, Elaine Thomas, Peter Deutsch, Charles Irby, Ken Victor, Bill Duvall, Bob Sproull, and others at ARC, PARC, and BBN.
この提案は新しいものを差し出す試みよりむしろ従来のアイデアの統合と考えられるべきです。 それはNGGによって仕事に基礎づけられています、エレイン・トーマス、ピーター。ARC、PARC、およびBBNのドイツ人、チャールズ・イルビー、ケンビクタ、ビル・デュヴァル、ボブ・スプラウル、および他のもの。
We are concerned about the lack of text-handling capabilities of the protocol suggested in RFC 493. Also, we feel that the protocol will have a significant influence on the interface provided to writers of future graphics application programs, and consequently that such things as "beam twiddling" should not be part of the protocol.
私たちはRFC493に示されたプロトコルのテキスト取り扱い能力の不足に関して心配しています。 また、私たちはプロトコルが将来のグラフィックスアプリケーション・プログラムの作家に提供されたインタフェースに重要な影響を与えて、その結果、「ひねり回しを発します」のようなことがプロトコルの一部であるべきでないと感じます。
Things of this nature address the problem at too low a level for a
facility which is intended to service the needs of a wide range of
graphics devices.
この種のものは低過ぎるレベルでさまざまなグラフィックス装置の必要性を修理することを意図する施設に問題と取り組みます。
We feel that, although the breakdown into "levels" as proposed in
RFC 493 may be expedient for initial experimentation, it is
inappropriate for a Network Standard Protocol. Instead, we
propose that the protocol allow for two levels, segmented and
structured. This allows the writers of graphics application
programs to deal with a very simple display facility (segments
consisting of lines, dots, or character strings) or with a
powerful structure of display subroutines.
私たちは、初期の実験に、RFC493で提案される「レベル」への故障が好都合であるかもしれませんが、Network Standardプロトコルに、それが不適当であると感じます。 代わりに、区分されて、構造化されて、私たちは、プロトコルが2つのレベルを考慮するよう提案します。 これは非常に簡単な表示施設(線、ドット、または文字列から成るセグメント)に対処するグラフィックスアプリケーション・プログラムか表示サブルーチンの強力な構造で作家を許容します。
We propose an experimental implementation of such a scheme on the ARC, BBN, and PARC systems to test these ideas using several application programs (including NLS) and at least an IMLAC, ARDS, and an E&S LDS.
私たちは、少なくともいくつかのアプリケーション・プログラム(NLSを含んでいる)、IMLAC、ARDS、およびE&S LDSを使用することでこれらの考えをテストするためにARC、BBN、およびPARCシステムにおけるそのような計画の実験的な実現を提案します。
Environment
環境
We are trying to design a protocol used to communicate with a "virtual display" to operate at the other end of a wire (ARPANET connection) from a "host" which is running some kind of display application program.
私たちはある種の表示アプリケーション・プログラムを走らせているワイヤ(アルパネット接続)のもう一方の端で「ホスト」から作動するために「仮想の表示」で交信するのに使用されるプロトコルを設計しようとしています。
Irby, et. al. [Page 1] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [1ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
We will adopt the terminology that the human user, sitting at the
display, is the "user" and the application program is the
"server".
私たちは用語を採用するつもりです。表示に座る人間のユーザは「ユーザ」です、そして、アプリケーション・プログラムは「サーバ」です。
We wish to stress the fact that within a single application, a single terminal should be useable both as an "interactive graphics" terminal AND as an "interactive control" terminal. Thus, the graphics protocol must allow for teletype-like operations.
ただ一つのアプリケーションの中では、単一の端末が「インタラクティブグラフィックス」端末として「対話的なコントロール」端末としてuseableであるはずであるという事実を強調したいと思います。 したがって、グラフィックスプロトコルはテレタイプのような操作を考慮しなければなりません。
The need for two sets of connections for running graphics programs over the Net (according to our understanding) is centered about the issue of handling (being able to recover gracefully from) berserk programs (and perhaps achieving greater bandwidth through the net).
ネット(私たちの理解に従って)の上で画像プログラムを動かすための2セットの接続の必要性は狂暴なプログラムを扱う(できます優雅に回復する)問題に関して中心に置かれます(恐らくネットを通したより大きい帯域幅を達成して)。
We recognize this problem but also think one should be able to run graphics programs using only one set of telnet connections. Also, it seems obvious that even though one is running a graphics program, one must expect to be able to handle "unescorted" characters (not embedded in a command or response message) being sent to his terminal.
私たちは、この問題を認識しますが、1セットのtelnet接続だけを使用することで画像プログラムを動かすことができるべきであるとまた思います。 また、人が画像プログラムを動かしていますが、彼の端末に送るのにおいて"非エスコート"のキャラクタ(コマンドか応答メッセージに埋め込まれていない)を扱うことができると予想しなければならないのは明白に見えます。
Consequently, we are proposing that the graphics protocol be implemented within telnet using 8-bit BEGIN-GRAPHICS-COMMAND and END-GRAPHICS-COMMAND characters or the 8-bit transparent mode of the new telnet. This means that one will be able to run graphics programs with one, two, or more sets of telnet connections.
その結果、私たちは、グラフィックスプロトコルがtelnetの中で8ビットのBEGIN-GRAPHICS-COMMANDとEND-GRAPHICS-COMMANDキャラクタか新しいtelnetの8ビットの透過モードを使用することで実行されるよう提案しています。 これは、1つが1、2セット以上のtelnet接続で画像プログラムを動かすことができることを意味します。
We also strongly propose that any site which is interested in supporting display terminals for use in network graphics would be prudent to implement local control over the display (such as IGNORE- GRAPHICS-COMMANDS, RESET-TO-TTY-MODE commands from the user to the using host). Failure to take such precautions may very well lead to burned out tubes!
また、私たちは、ネットワークグラフィックスにおける使用のためにディスプレー装置を支持したがっているどんなサイトも表示(IGNORE- GRAPHICS-COMMANDS、ユーザから使用しているホストまでのRESET-TO-TTY-MODEコマンドなどの)の上の現場制御を実行するために慎重であるよう強く提案します。 そのような注意を払わない場合、焼け出されているチューブに非常によく通じるかもしれません!
Basic concepts
基本概念
The model
モデル
The model we are adopting consists of an application program
manipulating a (remote) display file. This file may be
"segmented" or "structured", in which case it may be manipulated
independently from the display itself.
私たちが採用しているモデルは(リモート)の表示ファイルを操作するアプリケーション・プログラムから成ります。 このファイルは、「区分される」か、または「構造化されるかもしれません」、その場合、それが表示自体から独自に操られるかもしれません。
For structured display files an "update display" command causes
the display file to get mapped onto the display in whatever
fashion is appropriate for the display.
構造化された表示ファイルに関しては、「アップデート表示」コマンドで、いかなる表示に、適切なファッションでも表示ファイルを表示に写像します。
Irby, et. al. [Page 2] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [2ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Part of this protocol deals with commands issued to the (remote)
display file editor. This editor creates and changes the display
file at the user host.
このプロトコルの一部が(リモート)の表示ファイルのエディタに発行されたコマンドに対処します。 このエディタは、ユーザー・ホストで表示ファイルを作成して、変えます。
Structured Display Files
構造化された表示ファイル
A structured display file consists of named subpictures, each
containing any number of named units. There are two types of
units, primitive units and call units. The effect of a unit is
independent of its name or creation within the subpicture.
それぞれいろいろな命名されたユニットを含んでいて、構造化された表示ファイルは命名された「副-絵」から成ります。 2つのタイプの単位、原始のユニット、および呼び出しユニットがあります。 ユニットの効果は「副-絵」の中でその名前か創造から独立しています。
Primitive units contain drawing instructions and associated
coordinates that may generate visible information on the
display screen. Drawing instructions and coordinates can occur
only in primitive units.
原始のユニットはディスプレイの画面で目に見える情報を発生させるかもしれない指示を引き起こして、関連座標を含んでいます。 指示と座標を引き起こすのは原始のユニットだけに起こることができます。
Call units give the display structure a subroutine capability.
A call unit invokes the display of another subpicture. In
other words, a call unit allows one subpicture to contain
instances of other subpictures. As well as providing for
subroutine-style control transfer, call units can be used to
establish display parameters and maintain parameter
transparency. For example, a call unit can be used to call a
subpicture with a translation and relative intensity setting.
On return from the called subpicture, these parameters are
restored to their original values.
呼び出しユニットはサブルーチン能力を表示構造に与えます。 呼び出しユニットは別の「副-絵」の表示を呼び出します。 言い換えれば、呼び出しユニットで、1枚の「副-絵」が他の「副-絵」の例を含むことができます。 サブルーチンスタイルコントロール転送に備えることと同様に、表示パラメタを確立して、パラメタ透明を維持するのに呼び出しユニットを使用できます。 例えば、翻訳と相対的な強度設定がある「副-絵」を呼ぶのに呼び出しユニットを使用できます。 呼ばれた「副-絵」からのリターンのときに、これらのパラメタはそれらの元の値に回復します。
A subpicture is an ordered list of units which can be any
mixture of primitive and call units. Each subpicture begins
with a header and terminates with the subpicture end unit. The
subpicture end unit is a single unique unit in a display
structure linked to the end of each subpicture.
「副-絵」は原始と呼び出しユニットのどんな混合物であるかもしれないユニットの規則正しいリストです。 各「副-絵」は、ヘッダーと共に始まって、「副-絵」のエンド単位で終わります。 「副-絵」のエンド単位はそれぞれの「副-絵」の端までリンクされた表示構造の単一の特定のユニットです。
In order to understand how control passes through a structure,
one can think of the display elements as follows: subpictures
are subroutines and units are linked blocks of in-line code.
When all of the units contained in a subpicture have been
executed, the subpicture end unit returns control to wherever
the subpicture was called from. A primitive unit contains
display code and transfer to the next unit. A call unit
contains a subroutine call to a subpicture and a transfer to
the next unit in line.
コントロールがどのように構造を通り抜けるかを理解するために、人は以下の表示要素を考えることができます: 「副-絵」はサブルーチンです、そして、ユニットは繋がっているブロックのインラインコードです。 優に「副-絵」に含まれたユニットが実行されたとき、「副-絵」のエンド単位はどこでも、「副-絵」が呼ばれたところにコントロールを返します。 原始のユニットは次のユニットへの表示コードと転送を含んでいます。 呼び出しユニットは並んで次のユニットへの「副-絵」と転送にサブルーチン呼出しを含んでいます。
Irby, et. al. [Page 3] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [3ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Segmented Display Files
区分された表示ファイル
A segmented display file consists of named segments, each
containing any number of primitive units. The only operations
available for segmented display file is to add new, delete old, or
replace old segments (updating the actual display happens
automatically). The effect of a unit is independent of its name
or creation order within the subpicture.
それぞれいろいろな原始のユニットを含んでいて、区分された表示ファイルは命名されたセグメントから成ります。 区分された表示ファイルに利用可能な唯一の操作は、新しい状態で加えるか、老人を削除するか、または古いセグメントを取り替える(実際の表示をアップデートするのは自動的に起こります)ことです。 ユニットの効果は「副-絵」の中でその名前か創造命令から独立しています。
Hosts
ホスト
Since a given terminal may be under partial control of several
different hosts, all further discussion of names, coordinates,
display files, etc. should be taken as relative to each individual
host.
与えられた端末が数人の異なったホストの部分的なコントロールの下にあるかもしれないので、それぞれの個々のホストに比例して名前、座標、表示ファイルなどのすべてのさらなる議論を取るべきです。
That is, each host believes it has a display file, naming, and
coordinate space and a set of state parameters entirely under its
control; its only evidence of resource sharing is that the
terminal may appear to be of different sizes at different times.
すなわち各ホストは、完全にコントロールの下で州のパラメタの表示ファイル、命名、コーディネートしているスペース、およびセットを持っていると信じています。 リソース・シェアリングに関する唯一の証拠は端末がいろいろな時間に、異なったサイズがあるように見えるかもしれないということです。
(We feel that in principle it should be processes within hosts,
rather than hosts, that enjoy these properties, but it does not
seem feasible to construct a process identification scheme that
all hosts will find acceptable.)
(私たちは原則として、それがホストよりむしろホストの中の過程であるべきであり、これらの特性を楽しんでくださいが、すべてのホストが許容できるのがわかる過程識別計画を構成するのが可能に思えないと感じます。)
Subpictures
Subpictures
A subpicture has a name and zero or more units.
「副-絵」には、名前とゼロか、より多くのユニットがあります。
Subpicture names are arbitrary, globally unique, fixed-length
identifiers (subpicture names are chosen by the host).
Subpicture名は任意の、そして、グローバルにユニークな固定長識別子(「副-絵」の名はホストによって選ばれている)です。
Each unit (displayable component) has a name, which is local to
the subpicture.
各ユニット(表示可能の部品)には、名前があります。(それは、「副-絵」にローカルです)。
A unit may be a "primitive unit", such as a string or a vector, or
a "call unit", which implies displaying a (possibly transformed)
copy of another subpicture.
ユニットはストリングかベクトルなどの「原始のユニット」、または「呼び出しユニット」(表示を含意する)が別の「副-絵」の(ことによると変成する)のコピーであったならそうするかもしれません。
The display data are organized into a re-entrant tree (acyclic
graph) by the call units.
表示データは呼び出しユニットによってリエントラント木(非循環のグラフ)に組織化されます。
A unit may be "visible" or "invisible".
ユニットは、「目に見える」か「目に見えないかもしれません」。
Irby, et. al. [Page 4] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [4ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
A particular instance of a subpicture (the result of a call-
unit) appears on the screen precisely if it and all subpictures
on the logical path to it from the root of the tree are
"visible".
まさに木の根からのそれへの論理パスのそれとすべての「副-絵」が「目に見える」なら、「副-絵」(呼び出しユニットの結果)の特定の例はスクリーンに現れます。
Primitive units
原始のユニット
Strings
ストリング
A string is a horizontal line of characters with its own mode
and X,Y origin relative to the origin of the subpicture.
五弦はそれ自身のモードとX(「副-絵」の起源に比例したY原点)があるキャラクタの水平な線です。
Note: intensity is always relative.
以下に注意してください。 強度はいつも相対的です。
Font and mode (e.g. blinking) information logically accompanies
each character. This is accomplished by means of embedded mode
and font specification characters and a "restore original
string mode and font" character.
字体とモード(例えば、瞬く)情報は各キャラクタに論理的に同伴します。 これは埋め込まれたモード、字体仕様キャラクタ、および「元のストリングモードと字体を回復してください」というキャラクタによって達成されます。
Note: Mode modifiers are non-displayable characters and do
not take up character positions on the screen.
以下に注意してください。 モード修飾語は、非表示可能キャラクタであり、スクリーンの欄を取りません。
Determining the space occupied on the screen by a string
requires knowledge of the font(s) being used; this is a
separate question which is dealt with later.
スクリーンでストリングで使用船腹を決定するのは使用される字体に関する知識を必要とします。 これは後で対処されている別々の問題です。
TTY units
TTYユニット
A tty unit is a rectangle that consists of a number of lines.
Within this unit the display acts as if it were an alpha-numeric
display, e.g.,
ttyユニットは多くの線から成る長方形です。 このユニットの中では、表示はまるでそれが例えばアルファベット数字式表示であるかのように行動します。
characters which would write beyond the right hand margin of
the rectangle cause an automatic line folding to take place
長方形原因の右手のマージンに行われるためには折りたたみの自動線を書くキャラクタ
ascii control characters CarriageReturn, LineFeed, FormFeed,
and BackSpaceCharacter, (HorizontalTab and VerticalTab?), are
interpreted appropriately
ASCII制御文字CarriageReturn、ラインフィード、FormFeed、BackSpaceCharacter(HorizontalTabとVerticalTab?)は適切に解釈されます。
other control characters are displayed in a terminal specific
manner, e.g. ^F, <^F>, etc.
端末の特定の方法、例えば、^F、<^F>などで他の制御文字を表示します。
display of the characters in the range 200-377 is left
unspecified at this point (truncated to 7 bits?, alternate
fonts?, alternate modes?)
範囲200-377でのキャラクタの表示はここに不特定のままにされます。(7にビットに先端を切らせて、字体を交替してください、そして、モードを交替してください)?
Irby, et. al. [Page 5] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [5ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
It is hoped that we can agree on a standardization of some
of the characters in this range to allow for such things as
greek letters, common mathematical symbols, super-scripting,
and sub-scripting.
私たちがgreek手紙、一般的な数学記号、超の原稿を書く、サブのおよび原稿を書くようなものを考慮するためにこの範囲での何人かのキャラクタの標準化に同意できることが望まれています。
linefolding that would cause characters to be written below the
rectangle (whether performed automatically or by a LineFeed
character, etc.) cause the text within the unit to be scrolled
upwards one line (storage tube may adopt a different scheme).
それをlinefoldingすると、1つの線が以下の書かれているキャラクタに長方形(自動的やラインフィードキャラクタなどによって実行されるか否かに関係なく)でユニットの中に上向きにテキストをスクロールする引き起こされるでしょう(蓄積管は異なった計画を採用するかもしれません)。
Characters are displayed in a teletype unit in one of two ways:
テレタイプユニットに2つの方法の1つでキャラクターを表示します:
Characters sent to the terminal that are not part of any
command (unescorted characters) are appended to appropriate
tty-units (see below --- USE-TTY-UNITS, TTY)
tty-ユニットを当てるためにどんなコマンド(キャラクタを非エスコートした)の一部ではなく、端末に送られたキャラクターも追加します。(以下を見てください、-、--、TTY、TTYユニットを使用してください)
By use of the APPEND-STRING-TO-UNITS command for structured
display files
APPEND-STRING-TO-UNITSコマンドの構造化された表示ファイルの使用で
The first character sent to a tty-unit appears as the first
character (at the left margin) of the top line. This is necessary
for a number of reasons, the most convincing of which is the
behavior characteristics of storage tubes and most real alpha-
numeric displays.
tty-ユニットに送られた最初のキャラクタはトップラインの最初のキャラクタ(左のマージンにおける)として現れます。 これが多くの理由(それを納得させるのが蓄積管の振舞いの特性とほとんどのアルファの本当の数値表示である大部分)に必要です。
Successive characters appear as successive characters within
the top line until either an explicit (e.g., linefeed) or
implicit (line overflow) line break occurs.
明白(例えば、ラインフィード)か暗黙の(行の溢れ)ラインブレイクが起こるまで先端の中の連続したキャラクタが立ち並ぶとき、連続したキャラクタは現れます。
When a line break occurs, the next character appears on the
second from the top line of the unit.
ラインブレイクが起こると、次のキャラクタは2番目の上にユニットのトップラインから現れます。
This continues until the bottom line of the tty-unit is
reached.
tty-ユニットの結論に達するまで、これは続きます。
At this point, a line break causes the lines within the unit
to scroll up one line.
ここに、ラインブレイクで、ユニットの中の線は1つの線にスクロールします。
Note: Storage scopes may use a different technique for
scrolling.
以下に注意してください。 格納範囲は、スクロールするのに異なったテクニックを使用するかもしれません。
Dots
ドット
A dot unit consists of an initial X0,Y0 followed by a series of
points X,Y which describe a series of dots.
ドットユニットは初期のX0から成ります、とY0が一連のドットについて説明する一連のポイントX、Y続きました。
Each dot unit logically carries mode information such as
blinking, relative intensity, etc.
それぞれのドットユニットは瞬く相対的な強度などのモード情報を論理的に運びます。
Irby, et. al. [Page 6] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [6ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Lines
線
A line unit consists of an origin X0,Y0 followed by a series of
points X,Y which describes a series of straight lines connected
tail-to-head (i.e. a polygon).
回線接続装置は起源X0から成ります、とY0が一連のポイントX続いて、一連の直線について説明するYが上に立つテール(すなわち、多角形)を接続しました。
Each line unit logically carries mode information such as
blinking, dotted vs. solid, invisible.
各回線接続装置は固体に対して点を打たれた目に見えない瞬くことなどのモード情報を論理的に運びます。
Other kinds of lines, such as conic sections, may belong in the
primitive set.
原始のセットには他の種類の円すい曲線などの線があるかもしれません。
Special points
特別なポイント
This primitive unit consists of a series of points, which will
be displayed joined by lines in the best available manner.
この原始のユニットは一連のポイントから成ります。(ポイントは最も良い利用可能な方法で線によって接合されていた状態で表示されるでしょう)。
The intent is to use Flegal's algorithms to produce a smooth
curve.
意図は滑らかなカーブを生産するのにFlegalのアルゴリズムを使用することです。
Device-specific
装置特有です。
This primitive unit consists of any number of device specific
commands. The device type may be obtained through an
interrogation command.
この原始のユニットはいろいろな装置の特定のコマンドから成ります。 査問命令で装置タイプを得るかもしれません。
Call units
ユニットに電話をしてください。
In addition to the name of the referenced subpicture, a call unit
may include the following transformations:
参照をつけられた「副-絵」の名前に加えて、呼び出しユニットは以下の変化を含むかもしれません:
Master/instance rectangle: specifies a rectangle in the
caller's space into which a specified rectangle of the callee's
space is to be imaged. This provides independent scaling in
each coordinate as well as translation and clipping.
マスター/例の長方形: 像を描かれる訪問される人のスペースの指定された長方形がことである訪問者のスペースで長方形を指定します。 これは翻訳と切り取りと同様に各座標に独立しているスケーリングを提供します。
Rotation. It may be desirable to combine this with scaling
using the familiar idea of homogeneous transformation.
回転。 線形変換の身近な考えを使用するスケーリングにこれを結合するのは望ましいかもしれません。
Intensity and color control. In principle, a call could
specify intensity increments (positive or negative) for each
color.
強度と色は制御されます。 原則として、呼び出しは強度増分(肯定しているか否定している)を各色に指定するかもしれません。
It is assumed that best effort will be used in scaling and
rotation of text. We recommend replacing it by a line when all
else fails.
そんなにベストエフォート型であると思われて、テキストのスケーリングと回転に使用されるということです。 私たちは、すべてほかのときにそれを線に取り替えるのが失敗することを勧めます。
Irby, et. al. [Page 7] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [7ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Initial state
初期状態
After the initial telnet connection is established, the first
graphics command issued by the applications program should be a
request for either a structured display file or for a segmented
display file.
初期のtelnet接続が確立された後に、アプリケーションプログラムで発行された最初のグラフィックスコマンドは構造化された表示ファイルか区分された表示ファイルに関する要求であるべきです。
The response to this request should be whether or not the
requested display file was allocated and other parameters about
the virtual display, e.g. screen size, character sizes, whether
or not color is available, etc.
この要求への応答は、要求された表示ファイルを割り当てたか、そして、仮想の表示に関する他のパラメタであるべきです、例えば、画面サイズ、キャラクタサイズ、色が利用可能などであるか否かに関係なく
Before the display file is allocated, the terminal should appear
as, and simulate to the best of its ability, a Network Virtual
Terminal (NVT).
表示ファイルを割り当てる前に端末が現れるはずである、できる限りシミュレート、Network Virtual Terminal(NVT)。
Any graphic commands issued before the allocation of a display
file will be ignored.
表示ファイルの配分の前に発行されたどんなグラフィックコマンドも無視されるでしょう。
After requesting commands and receiving a structured display file,
the following structure will exist:
コマンドを要求して、構造化された表示ファイルを受け取った後に、以下の構造は存在するでしょう:
There will exist a subpicture, referred to as the ICP
SUBPICTURE, whose rectangular extent corresponds to the extent
of the virtual display allocated to this host.
ICP SUBPICTUREと呼ばれた長方形の範囲がこのホストに割り当てられた仮想の表示の範囲に対応する「副-絵」は存在するでしょう。
There will exist a tty-unit, referred to as the ICP TTY-UNIT,
in the ICP SUBPICTURE, where rectangular extent corresponds to
the extent of the virtual display allocated to this host.
ICP TTY-UNITと呼ばれたtty-ユニットは存在するでしょう、ICP SUBPICTUREで。そこでは、長方形の範囲がこのホストに割り当てられた仮想の表示の範囲に対応します。
This tty-unit will consist of n lines, where n is terminal
dependent and available through a query command.
このtty-ユニットはn線から成るでしょう。そこでは、nが質問コマンドで依存して利用可能な端末です。
This tty-unit will be instituted for the display of
unescorted characters.
このtty-ユニットは非エスコートされたキャラクタの表示のために設けられるでしょう。
There will be in effect an implicit call on the ICP SUBPICTURE.
事実上、暗黙の呼び出しがICP SUBPICTUREにあるでしょう。
This call is not accessible to the applications program.
この呼び出しはアプリケーションプログラムにアクセスしやすくはありません。
The applications program causes the display of information by:
アプリケーションプログラムは以下で情報表示を引き起こします。
1) creating primitive units in the ICP SUBPICTURE
1) ICP SUBPICTUREで原始のユニットを作成すること。
2) creating call units, to created subpictures, in the ICP
SUBPICTURE
2) ICP SUBPICTUREで呼び出しユニットを作成された「副-絵」に作成すること。
Irby, et. al. [Page 8] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [8ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
3) using the TTY command to make visible/invisible the ICP
TTY-UNIT (or change its location or size)
3) 目に見えるか目に見えなくするTTYコマンドを使用するのは、ICP TTY-UNITです。(その位置かサイズを変えてください)
After requesting and receiving a segmented display file, the
following structure will exist:
区分された表示ファイルを要求して、受け取った後に、以下の構造は存在するでしょう:
There will exist a segment, referred to as the ICP SEGMENT.
ICP SEGMENTと呼ばれたセグメントは存在するでしょう。
There will exist a tty-unit, referred to as the ICP TTY-
UNIT, in the ICP SEGMENT, whose rectangular extent
corresponds to the extent of the virtual display allocated
to this host.
ICP TTY- UNITと呼ばれたtty-ユニットは存在するでしょう、長方形の範囲がこのホストに割り当てられた仮想の表示の範囲に対応するICP SEGMENTで。
This tty-unit will consist of n lines, where n is terminal
dependent and available through a query command.
このtty-ユニットはn線から成るでしょう。そこでは、nが質問コマンドで依存して利用可能な端末です。
This tty-unit will be instituted for the display unescorted
characters.
このtty-ユニットは表示の非エスコートされたキャラクタのために設けられるでしょう。
The applications program causes the display of information by:
アプリケーションプログラムは以下で情報表示を引き起こします。
1) creating primitive units in the ICP SEGMENT
1) ICP SEGMENTで原始のユニットを作成すること。
2) creating new segments
2) 新しいセグメントを作成すること。
3) using the TTY command to make visible/invisible the ICP
TTY-UNIT (or to relocate it or change its size)
3) 目に見えるか目に見えなくするTTYコマンドを使用するのは、ICP TTY-UNITです。(それを移動させるか、またはサイズを変えるために)
Display editing primitives
基関数を編集する表示
General editing primitives
一般編集基関数
REQUEST-DISPLAY-FILE (file-type)
要求表示ファイル(ファイルの種類)
file-type is either structured or segmented.
ファイルの種類は、構造化されるか、または区分されます。
This command requires a response.
このコマンドは応答を必要とします。
Segmented display file editing
区分された表示ファイル編集
SEGMENT (Segment)
セグメント(セグメント)
If the segment Segment already exists, then it is cleared; if
it did not exist then it is created.
セグメントSegmentが既に存在しているなら、それは晴れます。 存在しなかったなら、それは作成されます。
Pictures are displayed within segments by the use of the
primitive unit command listed below.
セグメントの中にコマンドが以下に記載した原始のユニットの使用で絵を表示します。
Irby, et. al. [Page 9] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [9ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
DELETE-SEGMENT(Segment)
セグメントを削除します。(セグメント)
If the segment exists, then it is deleted.
セグメントが存在しているなら、それは削除されます。
Primitive Units
原始のユニット
All unit operations cause immediate display on the screen.
すべてのユニット、操作はスクリーンで即座の表示を引き起こします。
STRING-UNIT(Segment,Mode,X-Origin,Y-Origin,Text)
ストリングユニット(セグメント、モード、X-起源、Y-起源、テキスト)
Writes the specified string unit.
指定されたストリングユニットを書きます。
Mode refers to relative intensity, blinking, reverse video,
color, etc.
モードは相対的な強度、瞬く反転表示、色などについて言及します。
Errors: Segment does not exist.
誤り: セグメントは存在していません。
LINE-UNIT(Segment,Type,Mode,X0,Y0,X1,Y1, ..., Xn,Yn)
回線接続装置(セグメント、タイプ、モード、X0、Y0、X1、Y1、…、Xn、Yn)
Draws the specified line segments.
指定された線セグメントを描きます。
Type refers to solid, dashed, dotted, etc.
タイプは固体の、そして、投げつけられて、点を打たされたなどについて言及します。
Errors: Segment does not exist; illegal mode.
誤り: セグメントは存在していません。 不法なモード。
DOT-UNIT(Segment,Mode,X0,Y0,X1,Y1, ..., Xn,Yn)
ドットユニット(セグメント、モード、X0、Y0、X1、Y1、…、Xn、Yn)
Draws the specified dots.
指定されたドットを描きます。
Errors: Segment does not exist; illegal mode.
誤り: セグメントは存在していません。 不法なモード。
SPECIAL-POINTS-UNIT(Segment,Mode,X1,Y1, ..., Xn,Yn)
特別番組はユニットを向けます。(セグメント、モード、X1、Y1、…、Xn、Yn)
Draws the special-points curve.
特別なポイントカーブを描きます。
The terminal should attempt to connect the specified points in
the nicest way possible (e.g. Flegal's spline curve algorithm,
straight line segments).
端末は、可能な最も良い方法(例えば、Flegalのスプライン曲線アルゴリズム、まっすぐな線セグメント)で規定点を接続するのを試みるはずです。
Errors: Segment does not exist; illegal mode.
誤り: セグメントは存在していません。 不法なモード。
TTY-UNIT(Segment,Mode,Rectangle,Lines)
TTY-ユニット(セグメント、モード、長方形、線)
Creates a unit which will behave as a tty-simulation area with
"lines" lines distributed within the specified rectangle.
tty-シミュレーション領域として線が指定された長方形の中で分配した「線」で反応するユニットを作成します。
Unescorted characters will be echoed in this unit in addition
to any other units they are being sent to.
Unescortedキャラクタはこのユニットでそれらが送られるいかなる他のユニットに加えて言葉を繰り返されるでしょう。
Irby, et. al. [Page 10] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [10ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Errors: Segment does not exist.
誤り: セグメントは存在していません。
DEVICE-SPECIFIC-UNIT(Segment,device commands)
装置の特定のユニット(セグメント、装置コマンド)
Creates a unit of device specific commands.
装置の特定のコマンドのユニットを作成します。
TTY(parameters)
TTY(パラメタ)
parameters are:
パラメタは以下の通りです。
position rectangle, visible/invisible, number of lines, mode
of characters
位置の長方形、目に見えない目に見える/、数の線、キャラクタのモード
This refers to the ICP TTY simulation.
これはICP TTYシミュレーションを示します。
RESET()
リセット()
delete all segments, except ICP SEGMENT, and all units of ICP
SEGMENT, except ICP TTY-UNIT
ICP TTY-UNITを除いて、ICP SEGMENT、およびすべてのユニットのICP SEGMENT以外のすべてのセグメントを削除してください。
resets all nodes to their initial state (i.e., the state that
existed immediately after a REQUEST-DISPLAY-FILE command)
それらの初期状態にすべてのノードをリセットします。(すなわち、REQUEST-DISPLAY-FILEコマンド直後存在した状態)
Structured display file editing
構造化された表示ファイル編集
SUBPICTURE(Subpicture, rectangle)
SUBPICTURE(Subpicture、長方形)
Creates a new subpicture with name "Subpicture". "rectangle"
is the coordinates of a diagonal of the subpicture's virtual
screen (i.e. its coordinate system.)
名前"Subpicture"と共に新しい「副-絵」を作成します。 「長方形」は「副-絵」の仮想のスクリーンの対角線の座標です。(すなわち、座標系。)
If a subpicture named "Subpicture" already exists, it is
cleared and the new coordinate rectangle takes precedence.
"Subpicture"という「副-絵」が既に存在しているなら、それは晴れます、そして、新しいコーディネートしている長方形は優先します。
DELETE-SUBPICTURE(Subpicture)
SUBPICTUREを削除します。(Subpicture)
Deletes the subpicture named "Subpicture". Call units
referring to Subpicture are also deleted.
"Subpicture"という「副-絵」を削除します。 また、Subpictureについて言及する呼び出しユニットが削除されます。
CLEAR-SUBPICTURE(Subpicture)
明確なSUBPICTURE(Subpicture)
Deletes all units of the subpicture Subpicture, but does not
delete the subpicture.
subpicture Subpictureのすべてのユニットを削除しますが、「副-絵」は削除しません。
Irby, et. al. [Page 11] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [11ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Primitive Units
原始のユニット
All the operations for creating units are transparent to the
prior existence of the designated unit, i.e. they function as
"replace" as well as "create".
ユニットを作成するためのすべての操作が指定されたユニットの先の存在にわかりやすい、すなわち、それらは「作成」と同様に「取り替え」として機能します。
STRING-UNIT(Subpicture,Unit,Target-Key,Mode,X-Origin,Y-
origin,Text)
ストリングユニット(Subpicture、ユニット、目標キー、モード、X-起源、Yの起源、テキスト)
Replaces the unit by a string unit.
ユニットごとに、取り替えます。
Mode specifies the mode of the characters (e.g. blinking,
underlined, etc).
モードはキャラクタ(例えば、明滅していて、アンダーラインを引かれたなど)のモードを指定します。
Target-Key is used in conjunction with the TARGET-SENSITIVE
command and target input. It may also be sent via the SET-
TARGET-KEY COMMAND.
目標キーはTARGET-SENSITIVEコマンドと目標入力に関連して使用されます。 また、SET- TARGET-KEY COMMANDを通してそれを送るかもしれません。
Errors: Subpicture does not exist; X-Origin or Y-Origin is
outside the subpicture's virtual coordinate system.
誤り: Subpictureは存在していません。 「副-絵」の仮想の座標系の外にX-起源かY-起源があります。
We explicitly do not require an error if the string
extends beyond the right-hand edge of the subpicture;
however, the results are not defined.
ストリングが「副-絵」の右手の縁を超えて広がるなら、私たちは明らかに誤りを必要としません。 しかしながら、結果は定義されません。
LINE-UNIT(Subpicture,Unit,Target-Key,Type,Mode,X0,Y0,X1,Y1,
..., Xn,Yn)
回線接続装置(Subpicture、ユニット、目標キー、タイプ、モード、X0、Y0、X1、Y1、…、Xn、Yn)
Replaces the unit by a line unit.
ユニットを回線接続装置に取り替えます。
Errors: Subpicture does not exist illegal mode; some X or
Y is outside the subpicture.
誤り: Subpictureが不法な状態で存在していない、モード。 「副-絵」の外にいくつかのXかYがあります。
DOT-UNIT(Subpicture,Unit,Target-Key,Type,Mode,X0,Y0,X1,Y1, ...,
Xn,Yn)
ドットユニット(Subpicture、ユニット、目標キー、タイプ、モード、X0、Y0、X1、Y1、…、Xn、Yn)
Replaces the unit by a dot unit.
ユニットごとに、取り替えます。
Errors: Subpicture does not exist; illegal mode; some X or Y
is outside the subpicture.
誤り: Subpictureは存在していません。 不法なモード。 「副-絵」の外にいくつかのXかYがあります。
SPECIAL-POINTS-UNIT(Subpicture,Unit,Target-Key,Type,Mode,X1,Y1,
..., Xn,Yn)
特別番組はユニットを向けます。(Subpicture、ユニット、目標キー、タイプ、モード、X1、Y1、…、Xn、Yn)
Replaces the unit by a special-points unit.
特別なポイント単位ユニットを取り替えます。
Errors: Subpicture does not exist; illegal mode; some X or Y
is outside the subpicture.
誤り: Subpictureは存在していません。 不法なモード。 「副-絵」の外にいくつかのXかYがあります。
Irby, et. al. [Page 12] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [12ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
CALL-UNIT(Subpicture,Unit,Target-Key,Called-
Subpicture,Parameters)
呼び出しユニット(Subpicture、ユニット、目標主要で、呼ばれたSubpicture、パラメタ)
Replaces the unit by a call unit.
ユニットごとに、取り替えます。
Parameters:
パラメタ:
Master-Instance rectangles
マスター例の長方形
rotation
回転
mode
モード
Errors: Subpicture does not exist; Called-Subpicture does
not exist; parameter errors.
誤り: Subpictureは存在していません。 呼ばれたSubpictureは存在していません。 パラメタ誤り。
TTY-UNIT(Subpicture, unit, mode, rectangle, lines)
TTY-ユニット(Subpicture、モード(長方形)が裏打ちするユニット)
Creates a unit which will behave as a tty-simulation area
with "lines" lines distributed within the specified
rectangle.
tty-シミュレーション領域として線が指定された長方形の中で分配した「線」で反応するユニットを作成します。
Errors: Subpicture does not exist.
誤り: Subpictureは存在していません。
DEVICE-SPECIFIC-UNIT(Subpicture, Unit, Target-Key, device,
commands)
装置の特定のユニット(Subpicture(Unit、Target-キー、装置)は命令します)
Creates a unit of device specific commands. The action of
the commands should leave alone (or at least restore) any
global modes, e.g., the standout mode (see below).
デバイスの特定のコマンドのユニットを作成します。 コマンドの動作が単独でいなくなるべきである、(少なくとも、回復、)、どんなグローバルなモード、例えば、一匹おおかみモード(下を見ます)。
APPEND-STRING-TO-UNIT(Subpicture, Unit, Text)
ストリングをユニットに追加してください。(Subpicture、ユニット、テキスト)
Appends the specified text to the specific commands. This only
makes sense if the specified unit is a string or tty unit.
指定されたテキストを特定のコマンドに追加します。 これは指定されたユニットがストリングかttyユニットである場合にだけ理解できます。
Errors: Subpicture does not exist, unit does not exist, not a
string or tty unit.
誤り: Subpictureは存在していなくて、またユニットはストリングかttyユニットでない存在していません。
DELETE-UNIT(Subpicture, Unit)
ユニットを削除します。(Subpicture、ユニット)
Deletes a unit.
ユニット削除します。
Irby, et. al. [Page 13] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [13ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
VISIBLE-UNIT(Subpicture, Unit, Flag)
目に見えるユニット(Subpicture、ユニット、旗)
Makes the Unit visible or invisible as specified by Flag. If a
unit which is target sensitive is made invisible, it is no
longer target sensitive. However, in the absence of a
subsequent modifying target sensitive command, the unit becomes
target sensitive again if it should be made visible.
Flagによる指定されるように目に見えるか目に見えないUnitを作ります。 目標敏感なユニットを目に見えなくするなら、もう目標敏感ではありません。 しかしながら、それを目に見えるようにするなら、その後の変更目標がないとき敏感なコマンド、ユニットは再び目標敏感になります。
Errors: Subpicture does not exist, unit does not exist.
誤り: Subpictureは存在していなくて、またユニットは存在していません。
SET-TARGET-KEY(Subpicture, Unit, Target-Key)
目標キーを設定してください。(Subpicture、ユニット、目標キー)
Sets the target key for the specified unit to the specified
value.
指定されたユニットに、規定値に主要な目標を設定します。
SET-STANDOUT-MODE(mode)
一匹おおかみモードを設定してください。(モード)
Sets the mode that will be used to make text and/or units stand
out to blinking, underlining, etc.
使用されるモードに瞬くアンダーラインを引くのにテキスト、そして/または、ユニットを際立たせるように設定します。
If the terminal does not support the specified mode, the
terminal should make a best effort or use another method to
make things stand out.
端末が指定されたモードをサポートしないなら、端末は、aをベストエフォート型にするはずであるか、またはいろいろなことを際立たせる別のメソッドを使用するはずです。
STANDOUT-UNIT(Subpicture, unit, yesno)
際立ったユニット(Subpicture、ユニット、yesno)
makes the specified unit stand out (according to the mode set
by SET-STANDOUT-MODE) or not, according to "yesno". If the
unit which is to stand out is a call-unit, the instance of the
subpicture which is the result of the call (all the way to the
terminal nodes) is made to stand out.
"yesno"に従って、指定されたユニットを際立たせます(SET-STANDOUT-MODEによって設定されたモードによると)。 際立つことであるユニットが呼び出しユニットであるなら、要求(いっぱいに端末のノードまで)の結果である「副-画像」のインスタンスは際立たされます。
STANDOUT-TEXT(Subpicture, unit, begin-char-count, end-char-count,
yesno)
際立ったテキスト(Subpicture、ユニット、炭のカウントが始まっている終わりの炭のカウント、yesno)
Unit must refer to a string unit.
ユニットはストリングユニットについて言及しなければなりません。
Makes the specified text stand out (according to the mode set
by SET-STANDOUT-MODE) or not, according to "yesno".
"yesno"に従って、指定されたテキストを際立たせます(SET-STANDOUT-MODEによって設定されたモードによると)。
UPDATE-STRUCTURED-DISPLAY()
アップデートの構造化されたディスプレイ()
This causes any changes that have been made to the display
file, since the last update or since ICP, to be reflected on
the screen.
これはディスプレイファイル、アップデートまたはICP以来スクリーンに反映されるために行われているどんな変更も引き起こします。
Irby, et. al. [Page 14] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [14ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
TTY(parameters)
TTY(パラメタ)
parameters are:
パラメタは以下の通りです。
position rectangle, visible/invisible, number of lines, mode
of characters
位置の長方形、目に見えない目に見える/、数の系列、キャラクタのモード
This refers to the ICP TTY simulation
これはICP TTYシミュレーションを示します。
USE-TTY-UNITS(Subpicture1, unit1, ..., Subpicturen, unitn)
TTYユニットを使用してください。(Subpicture1、unit1、…、Subpicturen、unitn)
Unescorted characters are to be appended only to the specified
tty units.
Unescortedキャラクタは指定されたttyユニットだけに追加されることになっています。
Errors: Subpicture, unit does not exist.
誤り: Subpicture、ユニットは存在していません。
RESET(How)
リセット(どのように)
Case How Of
どのようにをケースに入れるか。
= Permanent
= 永久的
Immediately resets the terminal to its initial ICP state
すぐに、初期のICP状態に端末をリセットします。
= Temporary
= 一時的
Immediately resets the terminal to its initial ICP state
without destroying the previous state.
前のを破壊しないで、すぐに、初期のICP状態に端末をリセットします。
= Restore state saved from last RESET(Temporary).
= 最後のRESET(一時的な)から節約された状態を回復してください。
Direct Feedback
ダイレクトフィードバック
It seems extremely desirable, given network speeds, to allow the using host to perform direct feedback to the user without intervention from the application program in the serving host. This is already done in telnet with local echoing. We propose extending this capability to graphics by allowing "dragging" (attaching a subpicture's origin to the position of the cursor), "tracking" (following the movement of the mouse, stylus, or light pen with a distinctive mark on the screen), "inking" (plotting the trail of the cursor on the screen) and "rubber banding" (a straight line attached to a fixed point on one end the cursor location on the other).
ネットワーク速度を考えて、それは、使用しているホストが給仕のホストでアプリケーション・プログラムから介入なしでユーザにダイレクトフィードバックを実行するのを許容するために非常に望ましく思えます。 ローカル・エコーイングでtelnetで既にこれをします。 私たちは、「ドラッギングすること」を許容することによってグラフィックスへのこの能力を広げるよう提案します(「副-画像」の発生源をカーソルの位置に付けて)、「追跡している」(特有のマークがスクリーンにある状態で、マウス、スタイラス、またはライトペンの動きに続きます)、(スクリーンにカーソルの道を記入します)、「ゴムの組になること」を「インクで書い」て(直線が片端で定点に付いた、もう片方のカーソル位置)
These should be seen as allowable extensions of the protocol rather than as requirements. There should, however, be commands available in the protocol for determining their existence and controlling them.
これらは要件としてというよりむしろプロトコルの許容できる拡大と考えられるべきです。 しかしながら、プロトコルでそれらの存在を決定して、それらを制御するのに利用可能なコマンドがあるべきです。
Irby, et. al. [Page 15] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [15ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Data input primitives
データ入力基本要素
Input Control
入力コントロール
TARGET-SENSATIVE(key1, ..., keyn)
目標-SENSATIVE(key1、…、keyn)
Arms the units which have the specified keys for target
selection.
目標選択のための指定されたキーを持っているユニットを軍備します。
SET-INPUT-MODE(Device, parameters)
セット入力モード(デバイス、パラメタ)
Selects the mode in which a logical device shall produce input
and under what conditions.
論理的なデバイスが入力とどんな条件のもとで生産されるものとするモードを選択します。
the logical devices are specified below as well as their
possible input formats and conditions.
論理的なデバイスはそれらの可能な入力フォーマットと状態と同様に以下で指定されます。
Errors: no such device.
誤り: そのようなデバイスでない。
Keyboard input
キーボード入力
The keyboard has only one input mode, in which it sends a
character whenever a key is struck.
キーボードには、1つの入力モードしかありません。(キーが打たれるときはいつも、それはそれでキャラクタを送ります)。
Binary devices
バイナリ・デバイス
Unless otherwise specified, binary devices act as an extension of
the keyboard and produce 8-bit characters which are not
distinguishable from keyboard characters by the serving host.
別の方法で指定されない場合、バイナリ・デバイスは、給仕のホストでキーボードの拡大として機能して、キーボードの文字から区別可能でない8ビットのキャラクタを生産します。
The algorithm for translating binary devices into characters is
not specified, but something like the NLS accumulation
algorithm for mouse-keyset chords is intended.
バイナリ・デバイスをキャラクタに翻訳するためのアルゴリズムは、指定されませんが、マウス-keyset和音のためのNLS蓄積アルゴリズムのように意図します。
Binary devices may also input binary data (according to their
up/down states), which is transmitted on state changes. Examples
of this type of device are function keys and overlay cards, mouse
and keyset (used independently or together), pen-up/pen/down,
light pen buttons, etc.
また、バイナリ・デバイスはバイナリ・データ(それらの上/下に州に従って)を入力するかもしれません。(それは、州の変化の上で伝えられます)。 このタイプのデバイスに関する例はファンクションキーです、そして、上にペン/ペン/下がっているオーバレイカード、マウス、およびkeyset(独自か一緒に使用される)はペンボタンなどを点灯します。
Coordinate input
入力を調整してください。
Coordinates may be sent according to any subset of the following
criteria: with every character in some designated set (e.g.
control characters, or all characters); with every binary device
state change input; after some time interval has elapsed; after a
position change P > (y1-y0) ^2+(x1-x0)^2, etc.
以下の評価基準のどんな部分集合に応じても、座標を送るかもしれません: すべてのキャラクタがいくつかで任命されている状態で、(例えば、制御文字、またはすべてのキャラクタ)を設定してください。 あらゆるバイナリ・デバイスで、変化入力を述べてください。 いつか後に、間隔は経過しました。 位置の変化P>(y1-y0)^(x1-x0)^2など2+の後に
Irby, et. al. [Page 16] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [16ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Coordinates may be sent in either or both of "X-Y" or "target"
format.
"X-Y"か「目標」形式のどちらかか両方で座標を送るかもしれません。
X-Y format is just the location of the cursor relative to the
screen region assigned to the host.
X-Y形式はただホストに割り当てられたスクリーン領域に比例したカーソルの位置です。
Target format is the "call stack" (logical path from the root
unit - the ICP SUBPICTURE - to the closest unit) plus the
target-key of that unit plus the count of the closest character
within the string or the closest line segment or dot or special
point if appropriate.
適切であるなら、目標形式は、「呼び出しスタック」(根の単位(ICP SUBPICTURE)から最も近いユニットまでの論理パス)とそのユニットの目標キーとストリングの中の最も近いキャラクタ、最も近い系列セグメント、ドットまたは特別なポイントのカウントです。
Target input is unavailable for segmented display files.
目標入力は区分されたディスプレイファイルを入手できません。
In the event of overlapping target sensitive units, it is
not specified which of the units selected will be returned
as the hit unit.
目標の敏感なユニットを重ね合わせることの場合、ヒットユニットとして選択されたユニットのどれを返すかは指定されません。
Time input
時間入力
Since hosts may wish to consider two events happening sufficiently
close together to be simultaneous, or to keep detailed interaction
statistics, it must be possible to request time information to be
sent with some reasonable subnet of other types of input.
ホストが、十分近くで一緒に起こる2つのイベントが同時であるか、または詳細な相互作用統計を保つと考えたがっているかもしれないので、他のタイプの入力の何らかの妥当なサブネットと共に送られるよう時間情報に要求するのは可能であるに違いありません。
Interrogations
査問
It must be possible for the serving host to discover its environment (e.g. screen size, available devices) and to read back state information (display file).
給仕のホストが環境(例えば、サイズを上映してください、利用可能なデバイス)を発見して、州の情報(ディスプレイファイル)を読み返すのは可能であるに違いありません。
This is very desirable both for debugging and for redirecting a
displayed image to another device (e.g. a plotter).
デバッグと別のデバイス(例えば、陰謀者)に表示されたイメージを向け直すには、これは非常に望ましいです。
Environment
環境
Terminal parameters: screen size and resolution, available input
devices, terminal type (for device specific control), number of
lines in the ICP TTY-UNIT.
終値パラメタ: ICP TTY-UNITでサイズと解決、利用可能な入力装置、端末のタイプ(デバイスの特定の制御装置のための)、数の系列を上映してください。
Character parameters: available character sizes, special (non-
ASCII) characters, font characteristics, sub- and super-scripting
facilities.
キャラクターパラメタ: そして、有効なキャラクタサイズ、特別な(非ASCIIの)キャラクタ、フォントの特性、サブ、超スクリプティング施設。
State
状態
Display file or display file components.
ファイルかディスプレイファイルの部品を表示してください。
Irby, et. al. [Page 17] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [17ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Cursor Position
カーソル位置
It should be possible for the application program to read the
cursor position at any time.
アプリケーション・プログラムがいつでもカーソル位置を読むのは、可能であるべきです。
Display File Support
ディスプレイファイルサポート
It should be possible to find out if this user process supports
only segmented or structured display files, or both.
このユーザ・プロセスが、区分されたか構造化された唯一のディスプレイがファイル、または両方であるとサポートするかどうか見つけるのは可能であるべきです。
Command support
コマンドサポート
It should be possible to get a matrix from the user process
which indicates which commands are implemented. This is a
necessity to find out which, if any, of the direct feedback
features are supported, and might be nice to allow for, e.g.,
the possibility of a text only or graphics only subset of the
protocol to be implemented.
どのコマンドが実装されるかを示すユーザ・プロセスからマトリクスを得るのは可能であるべきです。 これは、どれを見つけるかためにもしあれば特徴がサポートされるダイレクトフィードバックについて考慮するために良いかもしれなく、例えば、テキストだけかグラフィックスだけの可能性が実装されるプロトコルの部分集合です。良く、部分集合です。
Encoding Principles
プリンシプルズをコード化します。
Commands will have the format : BGC OPCODE DATA EGC where:
コマンドには、形式があるでしょう: BGC OPCODE DATA EGC、どこ:
BGC (Begin Graphics Command) places the telnet connection into a
"read graphics command" mode,
BGC(Graphics Commandを始める)は「グラフィックスコマンドを読んでください」というモードにtelnet接続を置きます。
OPCODE DATA is the specific graphics command and data, and
そしてOPCODE DATAが特定のグラフィックスコマンドとデータである。
EGC (End Graphics Command) restores the telnet connection to its
normal state.
EGC(終わりのGraphics Command)はtelnet接続を正常な状態に復元します。
Note: This may all have to be bracketed by telnet Begin-8-bit-
transparent-mode and End-8-bit-transparent-mode commands.
以下に注意してください。 これはBegin-8telnetビットの見え透いたモードの、そして、End8が透過モードに噛み付いているコマンドですべて腕木を付けさせるかもしれません。
Numbers in general will have have 7-bits of significance in each byte -- if the high order of a byte is on, then the significant bits from the next byte should be concatenated onto the low-order end of the bits collected so far, etc..
数で、一般に、1バイトの注文がある高値、今までのところの集められたビットの下位の端の次のバイトからの重要なビットが連結されるべきであるその時などなら各バイトにおける、意味の7ビットを持つでしょう。
Subpicture names - shall be 14-bit numbers, assigned by the serving host.
Subpicture名--給仕のホストによって割り当てられた14ビットの数でしょう。
Unit names - shall be 14-bit numbers, assigned by the serving host.
ユニット名--給仕のホストによって割り当てられた14ビットの数でしょう。
Strings - shall be 8-bit characters, with an escape convention to represent changes of font and mode.
ストリング--フォントとモードの変化を表すエスケープコンベンションに伴う8ビットのキャラクタでしょう。
Irby, et. al. [Page 18] RFC 553 Draft design for a text/graphics protocol 14 July 1973
etイルビー、アル。 [18ページ] RFC553Draftはテキスト/グラフィックスプロトコルのために1973年7月14日を設計します。
Since the channel is 8-bits wide, there is room for many more than
128 displayable characters. However, the interpretation of codes
200B and above is not standardized!
チャンネルが幅8ビットであるので、ずっと多くの余地が128の「ディスプレイ-可能」キャラクタよりあります。 しかしながら、コード200Bと上の解釈は標準化されません!
Coordinates should be as described in RFC 493.
座標がRFC493で説明されるようにあるべきです。
Rectangles - shall be specified by the coordinates of the endpoints of one of the diagonal.
長方形--対角線の1つの終点の座標で、指定されるでしょう。
Encoding
コード化
The actual encoding of this protocol is forthcoming. Since we expect some changes to come about because of the upcoming Network Graphics Group Meeting, we have postponed the actual encoding until after this meeting.
このプロトコルの実際のコード化は用意されています。 いくつかの変化が今度のNetwork Graphics Group Meetingで生じると予想して、私たちはこの後会うまで実際のコード化を延期しました。
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Via Genie, 12/1999]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via GenieによるオンラインRFCアーカイブへの12/1999]
Irby, et. al. [Page 19]
etイルビー、アル。 [19ページ]
一覧
スポンサーリンク
