RFC125 日本語訳

                         NETWORK WORKING GROUP

作業部会をネットワークでつないでください。

                        REQUEST FOR COMMENT: 125

コメントのために以下を要求してください。 125

                                NIC 5841

NIC5841

                             APRIL 18, 1971

1971年4月18日

                             JOHN McCONNELL

ジョンMcCONNELL

                          AMES RESEARCH CENTER
                       MOFFETT FIELD, CALIFORNIA

エームズ研究センターモフェットFIELD、カリフォルニア

Response to RFC #86, Proposal for Network Standard Format for a graphics
data stream.

RFC#86への応答、グラフィックスデータ・ストリームのためのNetwork Standard FormatのためのProposal。

Category         D.6
RFCs obsoleted   None
RFCs updated     86

時代遅れにされたNone RFCsがアップデートしたカテゴリD.6 RFCs、86

                                                                [Page 1]

The basic approach of transmitting an intermediate, device independent
language which is translated into specific device codes at the
receiving host is sound. It appears to be the only approach that will
allow thought to be centered on picture descriptions. Ames Research
Center has adopted this approach in tying its graphic facilities, of
various types, and on various computers together. At present, we are
in the design phase and expect our package to be running in about six
months. The main objections to the structure as it now exists, is that
it takes no cognizance of the many features available on graphics
devices. Since these features will always be changing with new
devices, a set of option or mode primitives should be defined which
are logically separate from the drawing primitives provided in RFC 86.
The mode primitives will act upon the drawing primitives to modify
their actions. The scope of a mode primitive extends until a new mode
primitive resets an option. The use of mode primitives will allow the
network standard stream interpreter to treat them as null operations
if the features are missing at a particular host, or to perform more
detailed interpretation of the following data stream to achieve
results. The drawing primitives may also then keep a standard format
which need not be changed to incorporate new features.

[1ページ] 中間介在物を伝える基本的なアプローチ、受信ホストにおける特定のデバイス・コードに翻訳される装置の独立している言語は健全です。 絵の記述のときに中心に置かれるのが、考えを許す唯一のアプローチであるように見えます。 エームズ研究センターは様々なタイプのグラフィック施設を結んで、様々なコンピュータで取る際にこのアプローチを一緒に取りました。 現在のところ、私たちは、設計段階にいて、私たちのパッケージが駆け込むことであるとおよそ6カ月の予想します。 それとしての構造への主な反論は、現在、存在して、グラフィックス装置で利用可能な多くの特徴の認識を全く取らないということです。 これらの特徴がいつも新しい装置を交換するので、1セットのオプションかモード基関数が定義されるべきです(基関数がRFC86に供給した図面から論理的に別々です)。 モード基関数は、彼らの動作を変更するために描いている基関数に作用するでしょう。 新型基関数がオプションをリセットするまで、モード基関数の範囲は広がっています。 特徴が特定のホストでなくなるなら、ネットワークの標準の流れのインタプリタがモード基関数の使用でヌル操作としてそれらを扱うことができるでしょうか、または達成する以下のデータ・ストリームの、より詳細な解釈を実行するのは結果として生じます。 また、そして、描いている基関数は新機能を取り入れるために変えられる必要はない標準書式を保つかもしれません。

Overall modes which primitives could control would be intensity
levels, or color selections for objects, in addition blinking of
objects should be provided. For vectors, the additional facility for
drawing dashed lines is necessary.

基関数が制御できた総合的なモードは、強度レベル、または物のための色の選択でしょう、物について瞬くことが提供されるべきである添加で。 ベクトルに、図面が線を投げつけたので、追加の便宜供与が必要です。

Character strings require another set of specification. The convention
for the beam is usually that it is in the center of the rectangular
area defining a character's boundaries. The beam position is usually
undefined at the finish of drawing a character string. A strong
exception is taken to the exclusion of form control characters from
strings. If included in the character string, they could provide for
shifting from upper to lower case, subscripting, superscripting, and
underscoring, as well as tab and other "carriage" motion functions.
The appropriate characters could be extracted at interpretation time
to provide the necessary information to display more complex strings.
To allow the facility for generating ALGOL-like delimiters, such as
"then", a convention for canonical character string should be adopted.
I believe the Multics conventions described in reference 1 will
suffice.

文字列はもう1セットに仕様を要求します。 通常、ビームへのコンベンションはそれがキャラクタの境界を定義する長方形エリアの中心にあるということです。 通常、ビーム位置は文字列を描く終わりで未定義です。 ストリングからのフォーム制御文字を除外して強い例外を取ります。 文字列に含まれているなら、彼らはケースを下ろすためには上側からの移行に備えるかもしれません、添字付け、タブと他の「キャリッジ」動きと同様に機能を「スーパー-原稿を書」いて、強調して。 より複雑なストリングを表示するために必要事項を提供する解釈時に適切なキャラクタを抽出できました。 「その時」などのALGOLのようなデリミタを発生させるための施設を許容するために、正準な文字列のためのコンベンションは採用されるべきです。 私は、Multicsが1が満足させる参照で説明されたコンベンションであると信じています。

Additional options for character strings should include a size
specification and an orientation selection. As many devices, have
hardware character generators that are fixed, some of these options
may not be desirable to implement as subroutines.

文字列のための追加オプションはサイズ仕様とオリエンテーション選択を含むべきです。 同じくらい多くの装置、固定ハードウェア文字発生機構を持ってください、そして、これらのオプションのいくつかがサブルーチンとして実行するのにおいて望ましい必要はありません。

Another area that should be looked at further is the additional
symbols available which are not specified in ASCII. Some means of

それがさらに見られるべきである別の領域はASCIIで指定されない利用可能な追加シンボルです。 いくつかの手段

                                                                [Page 2]

defining them should be provided within the argument string itself,
again Multics has allowed the specification of arbitrary characters by
entering their octal equivalents. The convention should use a control
character code followed by a l6-bit list name which specifies the
sub-list defining the character. The other alternative is to allow
8-bit characters and allow the interpreter to choose a sub-list if the
character is not realizable with a hardware generator.

それらを定義する[2ページ]は一方、議論ストリング自体の中では、Multicsが彼らの8進同等物に入ることによって気紛れな質の仕様を許容したかどうかということであるべきです。 コンベンションは制御文字コードを使用するべきです、続いて、キャラクタを定義しながらサブリストを指定するl6-ビットリスト名を使用します。 もう片方の代替手段は、キャラクタがハードウェアジェネレータで実現可能でないなら、8ビットのキャラクタを許容して、インタプリタがサブリストを選ぶのを許容することです。

The special form control characters to be used are:

使用されるべき特別なフォーム制御文字は以下の通りです。

    a. BS    - backspace
    b. LF    - for new line
    c. SO/Sl - shift case
    d. DC2   - superscript following characters
    e. DC4   - subscript following characters
    f. DC3   - special non-ASCII character follows
    g. Tab   - position to next tab. May be predefined or specified.

a。 BS--バックスペースキーを押して印字位置を一字分戻ってください。b。 LF--復帰改行cに。 SO/Sl--ケースdを移動させてください。 DC2--上付き文字の次のキャラクタe。 DC4--添字の次のキャラクタf。 DC3--特別な非ASCII文字はgの後をつけます。 タブで移動してください--次にタブで移動する立場。 事前に定義されるか指定されるかもしれなくなってください。

Another construct should be added to those proposed in RFC 86. This is
the display list pointer (NGDLP). It will have as a value the next
drawing primitive to be executed. The value is a displacement from the
head of a list. With no mode setting primitives, this value is one to
one with the drawing primitives transmitted in the NGDS. The NGDLP is
needed for consistency for execution of the nested list structure.
Whenever an execute list primitive is encountered, the current value
of the NGDLP is saved along with the list name and current origin
value. When execution of a list is finished, the last values saved are
restored.

別の構造物はRFC86で提案されたものに加えられるべきです。 これは表示リストポインタ(NGDLP)です。 それで、次の図面は、実行されるために値として原始的になるでしょう。 値はリストのヘッドからの置換えです。 モード設定基関数がなければ、この値は、基関数がNGDSで送った図面がある1〜1です。 NGDLPが入れ子にされたリスト構造の実行に一貫性に必要です。 リストを実行してください。いつ、原始的であるのは、遭遇しています、NGDLPの現行価値がリスト名と現在の起源値と共に節約されるということであるか。 リストの実行が終わっているとき、節約された最終値は回復します。

An include list primitive would allow the treatment of a sub-list to
be equivalent to a macro instead of a subroutine. This would be
necessary to avoid changes to all sub-pictures on the screen due to
the manipulation of a sub-list. The include primitive should have as
parameters such specifications as size, intensity, orientation,
blinking, etc. After a sub-list has been included in another list, it
is no longer distinguished as a separate entity.

基関数がサブルーチンの代わりにマクロに相当しているのをサブリストの処理を許すインクルードリスト。 これが、サブリストの操作のためスクリーンの上のすべてのサブピクチャーへの変化を避けるのに必要でしょう。 インクルード基関数には、パラメタとしてサイズ、強度、オリエンテーション、瞬くような仕様があるべきです。 サブリストが別のリストに含まれている後に、それはもう別々の実体として区別されません。

To cut down on the volume of data being transferred, other commands to
be parsed by the stream interpreter should be added. These would allow
the manipulation of a list by the receiving host without a
retransmission.  The types of manipulations would include rescaling
the coordinates for shrinking or zooming, translation of the origin,
or rotation. Other manipulations to provide for displaying or not
displaying a list, or enabling of disabling light pen detections would
be desirable.

データ量におけるカットに移して、他の流れのインタプリタによって分析されるべきコマンドは加えられるべきです。 これらは「再-トランスミッション」なしで受信ホストによるリストの操作を許すでしょう。 操作のタイプは萎縮かズームのための座標、起源に関する翻訳を再スケーリングするか、回転を入れるでしょう。 表示するか、またはリスト、または軽いペン発覚を無効にするのを可能にすることを表示しないのに提供する他の操作は望ましいでしょう。

The problem of interaction with the displayed picture has yet to be
addressed, so this will be an attempt to elicit some more discussion

表示された絵との相互作用の問題がまだ記述されていないので、これはそれ以上の議論を引き出す試みでしょう。

                                                                [Page 3]

in this area. The use of a keyboard or function keys poses no problem
in that both can be handled as a standard message from the graphics
terminal. The use of devices that interact with the picture or the
screen such as light pens, mice, joysticks, or tablets presents a
different and more complex problem. This problem is the standard one
of making an association between the point selected and some
meaningful entity such as a list or a primitive. This association
should be made at the receiving host since the NGDS has been changed
in unknown ways.

この領域の[3ページ。] キーボードかファンクションキーの使用は、グラフィックス端末からの標準のメッセージとして両方を扱うことができるので、問題を全く引き起こしません。 装置の絵、光が書くスクリーン、ネズミ、ジョイスティック、またはタブレットと対話する使用は異なって、より複雑な問題を提示します。 この問題はリストか基関数などの選択されたポイントと何らかの重要な実体との協会を作る標準のものです。 この協会は、未知の方法でNGDSを変えたので、受信ホストで作られているべきです。

To allow the transmitting host to identify the object pointed at, the
stack of suspended lists and the current value of the NGDLP will
qualify the object to any level in a hierarchical structure. In
addition, normalized x,y coordinates should be returned, as well as a
character displacement if a string was pointed at. This structure will
serve a light pen device very well since the light pen mechanism
allows the determination of the currently executing primitive. Other
devices interact with the picture in an asynchronous fashion and the
association of an x,y pair to a structure is a more difficult problem.
This may require that the host generating the graphic data stream be
responsible for making that association. A further complication arises
when it is desired to use a light pen in an area where no beam motion
occurs, then some directive to periodically sweep the screen and
"find" the pen must be provided. This might be a sub-list which is
executed periodically for this function.

伝わっているホストが指し示された物、出場停止選手リストのスタック、およびNGDLPの現行価値を特定するのを許容するのが階層構造でどんなレベルも物に資格を与えるでしょう。 x、さらに、正常にされて、ストリングを指しているなら、形質置換と同様にy座標を返すでしょうに。 ライトペンメカニズムが現在原始的に実行していることの決断を許容するので、この構造はライトペン装置に非常によく役立つでしょう。 対向機器は絵と非同期なファッションとxの協会で対話して、構造へのy組は、より難しい問題です。 これは、図形データストリームを発生させているホストがその協会を作るのに責任があるのを必要とするかもしれません。 ビーム動きが全く起こらない領域でライトペンを使用するのが必要であるときに、さらなる複雑さは起こって、次に、定期的にスクリーンを掃いて、ペンを「見つける」ためには指示の或るものを提供しなければなりません。 これはこの機能のために定期的に実行されるサブリストであるかもしれません。

       [ This RFC was put into machine readable form for entry ]
        [ into the online RFC archives by Jerry Tenenbaum 4/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ジェリー・テネンバウム4/97によるオンラインRFCアーカイブへの]

---------------------------------------------------------------------------
Reference: Osanna, J., Sahzer, J.
           Remote Terminal Character Stream Processing of Multics
           Proceedings SJCC, 1970, p. 671

--------------------------------------------------------------------------- 参照: Osanna、J.、Sahzer、Multics Proceedings SJCC、1970、pのJ.Remote TerminalキャラクターStream Processing。 671

                                                                [Page 4]

[4ページ]