RFC472 日本語訳

Network Working Group                                        Steve Bunch
RFC # 472                                                    ILL-ANTS
NIC # 14801                                                  March, 1973

1973年のNIC#14801行進の病気のアリのネットワークワーキンググループスティーブBunch RFC#472

    Illinois' reply to Maxwell's Request for Graphics Information,
                          NIC Document 14925.

Graphics情報のためのマクスウェルのRequest、NIC Document14925へのイリノイの回答。

This is a reply to Craig Maxwell's (UCLA-NMC) "Request for graphics
information" of 3/7/73.  Further details can be obtained by contacting
me directly.

これはクレイグ・マクスウェルの(UCLA-NMC)に関する回答3/7/73の「グラフィックス情報に関する要求」です。 直接私に連絡することによって、詳細を得ることができます。

To date, our work in graphics has been primarily centered about support
for several applications groups.  To make the generation of beam-
oriented graphics as painless as possible for these groups, our policy
for supporting this type of graphics has been to emulate as closely as
possible the CALCOMP plotter support package on the host machine, but
with NGP0 output.  (Presently, before the resulting NGP can be sent to
some of our peripherals, e.g., Gould 4800, it must be converted to
device specifics.  With the advent of ANTS MARK II and a PDP-11/45, all
conversions will be handled locally, so all graphics flowing into our
system will be NGP).  We find this approach very labor-saving, even at
the present slightly kludgey level.

これまで、グラフィックスにおける私たちの仕事はいくつかのアプリケーショングループのサポートに関して主として中心に置かれました。 このタイプのグラフィックスをサポートするための私たちの方針は、ビームの指向のグラフィックスの世代をできるだけこれらのグループにおいて無痛にするためには、ホスト・マシンの上でできるだけ密接にCALCOMP陰謀者支援パッケージを見習いますが、NGP0出力で見習うことです。 (例えば、現在の、私たちの周辺機器のいくつかに結果として起こるNGPを送ることができる前のグールド4800、装置詳細にそれを変換しなければなりません。 ANTS MARK IIとPDP-11/45の到来で、すべての変換が局所的に扱われるので、私たちのシステムに流れるすべてのグラフィックスがNGPになるでしょう。). 私たちは、現在のわずかにkludgeyなレベルでさえこのアプローチがまさしくその省力化であることがわかりました。

We also have some grey-scale work taking place on our GOULD and IMLAC.
One group is processing satellite pictures on Illiac and will soon need
grey-scale output, another is producing natural-resource maps, and a
third is generating holograms.  No standardization plans have been made
for grey scale work, but if an acceptable standard is established, we
will most likely use it.

また、私たちは、私たちのグールドとIMLACで行われながら、何らかの灰色のスケールを働かせます。 1つのグループが、Illiacの上の処理衛星の絵であり、すぐ灰色のスケール出力を必要とするでしょう、そして、別のものは天然資源地図を製作しています、そして、3分の1はホログラムを発生させています。標準化プランは全く灰色のスケール仕事のために立てられていませんが、許容できる規格が確立されるなら、私たちはたぶんそれを使用するつもりです。

A small group, including myself, is currently planning an interactive
graphics system.  The system will use multiple hosts, possibly using a
remote E&S machine for rotation, scaling, etc.  We have a number of
large hurdles that have to be jumped before we can do anything, though.
Several of these are not graphics-specific, such as process-controlled
FTP, inter-process coordination among hosts, and others.  We had
intended to let efficiency dictate the format of intermediate results
shipped via the Net, with standardization being applied where it is
helpful for minimizing effort.  Since the system will be highly
interactive and will also manipulate grey-scale data, we will need a
higher level of graphics protocol to handle the user interface.  A
"proto-prototype" system is being used now to do some simple
manipulations of meteorological data (e.g., contouring, 3-D plotting)

自分を含む小さいグループは現在、インタラクティブグラフィックスシステムを計画しています。 回転、スケーリングなどにことによるとリモートE&Sマシンを使用して、システムは複数のホストを使用するでしょう。 私たちはもっとも、私たちが何でもできる前に跳ばれなければならない多くの大きいハードルを持っています。 これらの数個が過程で制御されたFTPや、ホストの中の相互の過程コーディネートや、他のものなどのようにグラフィックス特有ではありません。 私たちは効率にネットで出荷された中間結果の書式を決めさせるつもりでした、標準化が努力を最小にするのにおいて、それが役立っているところに適用されている状態で。 システムが非常に対話的であり、また、灰色のスケールデータを操るので、私たちはユーザーインタフェースを扱うために、より高いレベルのグラフィックスプロトコルを必要とするでしょう。 「proto-原型」システムは、現在、気象データのいくつかの簡単な操作をするのに使用されています。(例えば、輪郭3Dが企んで、

Bunch                                                           [Page 1]

RFC 472        Reply to Request for Graphics Information      March 1973

1973年の情報行進のときにグラフィックスのために要求する房[1ページ]のRFC472回答

with an IMLAC passively displaying the NGP0 pictures created.  Soon, I
hope to finish an IMLAC program that will handle some interaction with
the mouse/keyset.  I have decided to implement the following (outgoing)
commands.

IMLACが絵が作成したNGP0を受け身に表示していて。 すぐ、私は、マウス/keysetとのいくつかの相互作用を処理するIMLACプログラムを完成させることを望んでいます。 私は、以下の(送信する)のコマンドを実行すると決めました。

    MOVE  beam to mouse position

MOVEはマウス位置に発します。

    DRAW  from last to present beam position.

最終から現在までのDRAWは位置を発します。

    TEXT  at present beam position.

TEXTは現在のところ、位置を発します。

    UNDO  the last command (to facilitate freehand drawing and
          backspacing in TEXT).

最終が命令する(自在画の図面とTEXTでバックスペースキーを押して印字位置を一字分戻るのを容易にする)UNDO。

Other commands may be implemented as needed to do what people want to
do, at least until an adequate interaction standard comes along.

他のコマンドは人々がしたがっていることをするために必要に応じて実行されるかもしれません、適切な相互作用規格が少なくともやって来るまで。

Note that there is implicit in the UNDO command the assumption that
the other end of the line possesses a certain amount of memory and
intelligence.  Two possible philosophies for standardizing interaction
are that (1) all "nodes" ("generators" or "users" of data) understand
some set of commands and possess at least a certain amount of
intelligence, and (2) a distinction is made between "displays" and
"computers" (quotes because the line is fuzzy).  I favor the first for
its generality, but I suggest that the lowest level of interactive
graphics might want to use the second for ease of implementation with
unintelligent devices, e.g., COMPUTEK 400's.  (I do not mean to
imply in (1) that the actual "computer" would not have a larger
vocabulary than the actual "display" --this is inevitable with higher
level capabilities in the protocol).

電話の向こう側には、あるメモリー容量と知性があるという仮定が「取り消し」コマンドで暗黙であることであることに注意してください。 相互作用を標準化するための2つの可能な哲学が(1) すべての「ノード」(データの「ジェネレータ」か「ユーザ」)が何らかのセットのコマンドを理解していて、少なくともある量の知性を持って、「表示」と「コンピュータ」の間で区別を(2) するということである、(線があいまいであるので引用する、) 一般性のための1番目を支持しますが、私は、最も低いレベルの対話的なグラフィックスが無知な装置(例えば、COMPUTEKのもの400)による実現の容易さに2番目を使用したがっているかもしれないことを提案します。 (私は、(1)で実際の「コンピュータ」には実際の「表示」より大きいボキャブラリーがないのを含意するのを意図しません--さらに高い平らな能力がプロトコルにある状態で、これは必然です。)

Since we have almost no local computing power for applications work,
all our graphics computation is done remotely (our work has been
primarily at UCSD (B6700), USC-ISI (TENEX), and UCLA-CCN (360)).
Because we do our work at scattered sites and are basically economic
of labor (pronounced "lazy"), we have a lot to gain by standards and
will be glad to cooperate as much as possible with standardization
efforts.

私たちがアプリケーションのための地方のコンピューティングパワーをほとんど全く働かせないので、離れて私たちのすべてのグラフィックス計算をします。(私たちの仕事が主としてUCSD(B6700)、USC-ISI(TENEX)、およびUCLA-CCN(360))にありました。 私たちが点在しているサイトで仕事して、労働(「怠惰である」と断言される)で基本的に経済であり、規格で獲得するいろいろな事を持って、標準化の努力にできるだけ協力するでしょう。

Steve Bunch

スティーブBunch

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社9/99]

Bunch                                                           [Page 2]

房[2ページ]