RFC549 日本語訳
0549 Minutes of Network Graphics Group meeting, 15-17 July 1973. J.C.Michener. July 1973. (Format: TXT=23367 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Anonymous Request for Comments: 549 Center for Advanced Computation, U of Ill NIC: 17795 15-17 July 1973
コメントを求めるワーキンググループの匿名の要求をネットワークでつないでください: 549 高度な計算のためのセンター、病気のNICのU: 17795 1973年7月15-17日
MINUTES OF NETWORK GRAPHICS GROUP MEETING
ネットワークグラフィックスグループ会議の議事録
Sunday evening, 15 July
日曜日の晩、7月15日
The meeting came to order around 1930, Jim Michener presiding. After introductions, an agenda was constructed for the rest of the meeting.
ジム・ミッチェナーが司会して、ミーティングは1930をこき使うようになりました。 序論の後に、議題はミーティングの残りのために構成されました。
Elaine Thomas distributed copies of an Alternative Network Graphics Protocol for attendees to read overnight prior to discussion.
出席者が議論の前に夜通し読むように、エレイン・トーマスはAlternative Network Graphicsプロトコルのコピーを分配しました。
Because some individuals were absent who had definitely indicated that they were coming Monday morning, the meeting was adjourned at 2030 after deciding to meet at 0930 the next morning.
だれが、彼らが月曜日の朝来る予定であるのを確実に示していなかったか何人かの個人がいたので、ミーティングは0930年の会うと決めた後翌朝に2030年に休会されました。
Monday Morning/Afternoon, 16 July
月曜日の朝/午後、7月16日
The meeting was called to order at 0930
ミーティングは0930年に秩序正しくするように頼まれました。
Jim Michener distributed an outline of a paper describing desirable facilities for the use of two dimensional input devices with a hierarchically structured display program.
ジム・ミッチェナーは階層的で構造化されたディスプレイプログラムによる二次元入力装置の使用のために望ましい施設について説明する論文のアウトラインを分配しました。
Ken Victor distributed copies of RFC 553: A Proposed Network Text/Graphics Protocol. (LJOURNAL,17810,)
ケンビクタはRFC553のコピーを分配しました: 提案されたネットワークテキスト/グラフィックスは議定書を作ります。 (LJOURNAL、17810)
Ken Pogran described the history of the NGG and how the "levels" approach of RFC 493 came about. In particular, the "level 0" protocol was an attempt to define something to experiment with, but with the thought that it should be possible to imbed "level 0" meaningfully in any later protocol.
ケンPogranはNGGの歴史について説明しました、そして、「レベル」にRFC493についてどうアプローチするかは生じました。 特に、「0インチの平らなプロトコルは考えにもかかわらず、「あらゆる後のプロトコルで意味深長に0インチを平らにしてください。」を埋め込むのが可能であるべきであるという考えで実験することを定義する試みでした。
Reports of Network Graphics Experiences
ネットワークグラフィックス経験のレポート
Jon Jervert described the installation at CAD/CAM (Fort Monmouth).
They have a spectrum of display terminals and have tried several
via a Telnet connection to MIT-DMCG. They experienced
unacceptable slowness with a 300 Baud bandwidth.
ジョンJervertはCAD・CAM(Fortモンマス)でインストールについて説明しました。 彼らは、ディスプレー装置のスペクトルを持って、MIT-DMCGとのTelnet接続で数個を試みました。 彼らはのろさを300Baud帯域幅と共に容認できない経験しました。
Austin Henderson described an Air Traffic Control experiment in
which the simulator receives codes describing changes in state and
generates descriptions of the air space (region) being controlled
オースチンヘンダーソンはシミュレータが状態で変化について説明するコードを受け取って、制御されていて、エアスペース(領域)の記述を生成するAir Traffic Control実験について説明しました。
[Page 1]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[1ページ]
and aircraft position and velocity. These descriptions are highly
encoded--they are not pictures in any general sense. The rate at
which the simulation proceeded was adequate.
航空機位置と速度。 これらの記述は非常にコード化されます--それらはどんな一般的な意味で画像ではありません。 シミュレーションが続いた速度は適切でした。
Jim Michener described the results of an experiment in which the
E&S LDS-1 at MIT-DMCG was used to generate stylus inking input for
a character recognition program at SDC. The experiment was
plagued with difficulties including bugs in SDC's NCP and
scheduling of experimental/debugging sessions. When the
experiment was finally terminated (due to planned extensive
hardware modifications at DMCG) a clear understanding had not yet
emerged, but apparently network transmission delays had been
experienced of up to 20 seconds.
ジム・ミッチェナーはMIT-DMCGのE&S LDS-1がSDCの文字認識プログラムのために入力されたスタイラスのインクで書くことを生成するのに使用された実験の結果について説明しました。 実験はSDCの実験的であるかデバッグしているセッションのNCPとスケジューリングでバグを含むことにおける苦労で悩まされました。 実験が最終的に終えられたとき(DMCGでの計画された大幅なハードウェア変更のため)、明確な理解はまだ現れていませんでしたが、明らかに、ネットワーク送信遅れは最大20秒について経験されました。
Dan Cohen described an Aircraft Flight Simulator which interacts
with a user at the Harvard PDP-1. The simulation takes place on a
PDP-10. Network traffic is approximately 200 bits from the PDP-1
to the PDP-10 and several thousand bits in the opposite direction.
It has been found that at least 5 updates are required per second
to give the "pilot" an adequate feeling of control. The Harvard
PDP-10 and one at BBN have been used, the latter at 6 AM to avoid
loading problems.
ダン・コーエンはハーバードPDP-1でユーザと対話するAircraftフライト・シミュレータについて説明しました。 シミュレーションはPDP-10で行われます。 ネットワークトラフィックは、PDP-1からPDP-10までのおよそ200ビットと逆方向への数1,000ビットです。 少なくとも5つのアップデートがコントロール適切な感を「パイロット」に与えるのに1秒単位で必要であることが見つけられました。 BBNのハーバードPDP-10と1つが使用された、問題をロードするのを避ける午前6時の後者。
John Pickens described UCSB's status regarding output in level 0
Network Graphics Protocol (NGP-0).
ジョン・ピケンズはレベル0Network Graphicsプロトコル(NGP-0)における出力に関するUCSBの状態について説明しました。
Steve Bunch reported that he has an Imlac monitor which accepts
NGP-0 directly. Programs have been developed at CCN (using
subroutine packages modeled after plotter packages) which build
files containing pictures in NGP-0. Other programs output the
pictures either to a Gould plotter or a storage display (in device
specific code) or to an Imlac (in NGP-0 form).
スティーブBunchは、彼には直接NGP-0を受け入れるImlacモニターがあると報告しました。 NGP-0に画像を含んでいて、ファイルを造るCCN(陰謀者パッケージに倣われたサブルーチンパッケージを使用する)でプログラムを開発してあります。 他のプログラムはグールド陰謀者かストレージディスプレイ(デバイスの特定のコードの)、または、Imlacに画像を出力しました(NGP-0では、形成してください)。
Steve Holmgren briefly described a Fancy Arpa Network Graphics
System (FANGS) under development at UCSD.
スティーブ・ホルムグレンは簡潔に、UCSDの開発中のFancy Arpa Network Graphics System(FANGS)について説明しました。
Discussion of Modifications in the Graphics Protocol
グラフィックスプロトコルにおける、変更の議論
David Egli reported that he and Jim Foley (of Univ. of North
Carolina) thought that the graphics protocol should have the
ability to replace items, and that 3 dimensional data should be
allowable. Jim Foley also thinks that a subpicture call should be
able to specify a rate of rotation, scaling, and translation, in
addition to initial values for these.
デヴィッドEgliは彼とジム・フォーリー(ノースカロライナの大学の)が、グラフィックスプロトコルには商品を置き換える能力があるべきであると考えて、3つの次元データが許容できるべきであると報告しました。 また、ジム・フォーリーは、「副-画像」呼び出しが回転、スケーリング、および翻訳の速度を指定できるべきであると考えます、これらのための初期の値に加えて。
An extended coffee break followed to allow perusal of the
documents distributed.
延ばされたコーヒー中断は、配付資料の熟読を許すために続きました。
[Page 2]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[2ページ]
Elaine Thomas summarized her protocol proposal for a
hierarchically structured, editable display file.
エレイン・トーマスは階層的で構造化されて、編集可能なディスプレイファイルのための彼女のプロトコル提案をまとめました。
Discussion related to the levels approach of RFC 493 concluded
that levels were inappropriate; we would henceforth think in terms
of negotiable options.
議論は、レベルが不適当であるとRFC493のアプローチが結論づけたレベルに話しました。 私たちは今後は、交渉可能なオプションで考えるでしょう。
Ken Victor stressed that NLS was particularly desirous of being
able to make use of the graphics protocol; that was the reason for
their developing RFC 553.
ケンビクタは、NLSが特にグラフィックスプロトコルを利用できるのを願ってやまないと強調しました。 それはそれらの展開しているRFC553の理由でした。
Ken Pogran observed that a structures display system as is being
proposed is more a distributed graphics system than a protocol,
and that he thought this a good idea. General consensus agreed
with him.
ケンPogranは、提案されるような構造ディスプレイ・システムがプロトコルより分配されたグラフィックスシステムであり、彼が、これが名案であると考えたのを観測しました。 全体的な合意は彼に同意しました。
Jim Michener described proposals for input. He emphasized the
necessity of transmitting position information in figure
coordinates as opposed to screen coordinates or top level figure
coordinates.
ジム・ミッチェナーは入力のための提案について説明しました。 彼は画面座標か最高平らな図座標と対照的に図座標の位置の情報を伝えるという必要性を強調しました。
Bob Sproul described two different ways in which a graphics
application in a serving host can communicate to a using host
controlling a display device.
ボブSproulは給仕のホストのグラフィックスアプリケーションがディスプレイ装置を制御している使用しているホストに伝えることができる2つの異なった方法を述べました。
If the using host has complex enough software or hardware, a
structured definition of the display may be sent.
使用しているホストに十分複雑なソフトウェアかハードウェアがあるなら、ディスプレイの構造化された定義を送るかもしれません。
A structured display definition consists of figures (also
called pictures or groups) which consist of units. A unit
is either a call to another figure or a collection of one or
more text or graphic commands. (Other special purpose units
may exist, also.) Figures and units have names and may be
created, replaced and deleted (and other things).
構造化されたディスプレイ定義はユニットから成る数字(また、画像かグループと呼ばれる)から成ります。 ユニットは、別の図への呼び出しか1つ以上のテキストかグラフィックコマンドの収集のどちらかです。 (また、他の専用ユニットは存在するかもしれません。) 数字とユニットは、名前を持って、作成されて、取り替えられて、削除されるかもしれません(そして、他のもの)。
A simpler scheme for the using host is that transformed segmented
display information be sent across the network.
使用しているホストの、より簡単な体系はネットワークの向こう側に変成している区分されたディスプレイ情報を送るということです。
Segments have names and can be individually created, replaced and
deleted.
セグメントは、名前を持って、個別に作成して、取り替えられて、削除できます。
Either the application works directly in terms of segments, or it
works in terms of a structures display definition and software at
the serving host has the responsibility of evaluating the
transformations and the sub-figure calls.
変換を評価する給仕のホストのディスプレイ定義とソフトウェアが責任を持っている構造に関して働いています、そして、アプリケーションが直接セグメントに関して動作するか、またはサブ図は電話をします。
[Page 3]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[3ページ]
It seems likely that such transformation software might have to
exist at the serving host anyway if that host has any graphics
terminals of small to moderate capability.
能力を加減するのはそのホストが何か小さいことのグラフィックス端末を持っているならそのような変換ソフトウェアが給仕のホストにとにかく存在しなければならないかもしれなそうなように思えます。
It was agreed to restrict our attention to the simpler
"transformed-segmented" scheme, and delay consideration of the
"hierarchically structured" scheme until another meeting.
別のミーティングまで、より簡単な「変成して区分された」体系に関する私たちの留意、および「階層的では、構造化された」体系の遅れの考慮を制限するためにそれは同意されました。
It seemed to the meeting that a significant number of
applications would need nothing more powerful than a segmented
scheme.
多くのアプリケーションがない区分された体系ほど強力なものは必要とするようにミーティングに思えました。
One desirable mechanism is an "end batch of updates" command. It
can help optimize the use of a storage terminal and it can let a
user program causes fixes to occur on a refresh tube all at once.
1つの望ましいメカニズムが「アップデートの終わりのバッチ」コマンドです。 それは、ストレージ端末の使用を最適化するのを助けることができます、そして、フィックスがプログラムで起こるユーザにaでチューブを一気にリフレッシュさせることができます。
After lunch, Ira Cotton pointed out that it would be easy enough to allow NGP-0 to be upward compatible with a segmented, transformed scheme. Bob Sproul agreed and said that that was a good argument for sending only device independent data on the net. (This idea was modified in discussion on Tuesday.)
昼食の後に、イラCottonは、それがNGP-0が区分されて、変成している体系と互換性があった状態で上向きであることを許容するほど簡単であると指摘しました。 ボブSproulは、それがデバイスの独立しているデータだけをネットに送るための良い議論であると同意して、言いました。 (この考えは火曜日に議論で変更されました。)
Ken Victor discussed TTY units, a mechanism for displaying characters which are "unescorted" i.e., are not part of a graphics "text" command. In particular they are for spontaneous messages from the operating system (like "out of funds" or "going down in 5 min"). General discussion was undecided on whether TTY units should really be part of a graphics protocol. (This was later decided affirmatively.)
ケンビクタはTTYユニットについて議論して、"非エスコート"であるキャラクタを見せるためのメカニズムはすなわち、グラフィックスの一部が「テキスト」でないというコマンドです。 それらは特に、オペレーティングシステム(「金を切らして」好きである、または「5分で、落ちる」)からの自然発生的なメッセージのためのものです。 一般議論はTTYユニットが本当にグラフィックスプロトコルの一部であるべきであるかどうかに関して未定でした。 (これは後で肯定的に決められました。)
It was noted that unescorted characters coming from the serving
host could probably be handled, but that those coming from the
using host might not be.
たぶん給仕のホストから来る非エスコートされたキャラクタは扱うことができましたが、使用しているホストから来るものがそうでないことに注意されませんでした。
Discussion of Network Connection for Graphics
グラフィックスのためのネットワーク接続の議論
A graphics connection may start out with a Telnet connection. We will request a DO GRAPHICS telnet option.
グラフィックス接続はTelnet接続と共に始めるかもしれません。 私たちはDO GRAPHICS telnetオプションを要求するつもりです。
Multiplexing on the Telnet connection vs using a separate connection pair.
Telnet接続のときに、別々の接続組を使用することに対して多重送信します。
Dan Cohen stated that his Flight Simulator uses a second pair.
ダン・コーエンは、彼のフライト・シミュレータが2番目の組を使用すると述べました。
Alex McKenzie pointed out that some hosts have only "read and
block" input commands, not "read and continue". This means we
cannot demand to have separate connection pairs with graphics on
one and telnet-type information on the other.
アレックス・マッケンジーは、「読んで、続くこと」ではなく、ホストがいる或るものが入力コマンドを「読んで、妨げるだけである」と指摘しました。 これは、私たちが、別々の接続組がもう片方の1のグラフィックスとtelnetタイプ情報と共にあるのを要求できないことを意味します。
[Page 4]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[4ページ]
Jim Hansen called for a show of hands of preferences: NLS was the
only site against using multiple connection. Several sites were
against multiplexing graphics information on the Telnet
connection. Issues included:
ジム・ハンセンは好みの挙手を求めました: 複数の接続を使用することに対するNLSは唯一のサイトでした。 いくつかのサイトがTelnet接続のマルチプレクシンググラフィックス情報に反対していました。 問題は:だった
It is easier to merge two streams at the user than to split one
into two. The latter requires "smart" programming.
ユーザの2つのストリームを合併するのは1つを2に分けるより簡単です。 後者は「賢い」プログラミングを必要とします。
TIP users may lose if multiple connections are required.
複数の接続が必要であるなら、TIPユーザは損をするかもしれません。
It should be possible to do it on one connection.
1つの接続のときにそれをするのは可能であるべきです。
In summary: two connections are better than one, the number
shall be negotiated over the Telnet connection.
概要で: 2つの接続が1より良い、数はTelnet接続の上で交渉されるものとします。
Ira Cotton asked for a discussion of connection initiation other
than via a Telnet connection. It was agreed that we did not know
enough at this time to specify this and that it was a matter for
experimentation.
イラCottonはTelnet接続以外の接続開始の議論を求めました。 私たちが、このとき、これを指定するのを十分知らないで、それが実験のための問題であるのに同意されました。
Someone commented that what we have is a Network Virtual Graphics Terminal which has a Network Virtual Keyboard and a Network Virtual Printer (in the Telnet sense) and a Network Virtual Display Unit. The printer and the display unit may be the same.
だれかが、私たちが持っているものがNetwork Virtual KeyboardとNetwork Virtual Printer(Telnet意味における)を持っているNetwork Virtual Graphics TerminalとNetwork Virtual Display Unitであると論評しました。 プリンタとディスプレイ装置は同じであるかもしれません。
Ira Cotton announced that Jim Foley (of Univ. of North Carolina) is planning to have a workshop on machine independent graphics under the auspices of SIGGRAPH in Washington D.C. around mid-April (cherry blossom time).
持っているジム・フォーリー(ノースカロライナの大学の)がワークショップを計画している発表されたイラCottonは4月中旬(桜の花時間)頃にワシントンDCのSIGGRAPHの前兆で独立しているグラフィックスを機械加工します。
Discussion of Graphics Input
グラフィックス入力の議論
Dan Cohen summarized the use of input in his flight simulator:
since it comprises only approximately 200 bits in toto, all
switches, knobs, and stylus position are transmitted. This takes
place about five times per second.
ダン・コーエンは彼のフライト・シミュレータにおける入力の使用をまとめました: トトでおよそ200ビットだけを包括するので、すべてのスイッチ、ノブ、およびスタイラス位置は送られます。 これは1秒におよそ5回行われます。
Austin Henderson described the input facilities on the LL TX-2.
オースチンヘンダーソンはLL TX-2で入力施設について説明しました。
Attentions are enabled. What information will be desired when
a particular attention occurs is described at the time the
attention is enabled.
こころづくしは可能にされます。 注意が可能にされるとき、特別の注意が起こるとき、どんな情報が望まれるかは説明されます。
When an attention occurs, the system records the desired
information in a queue for the application program.
注意が起こると、システムは必要な情報をアプリケーション・プログラムのための待ち行列に記録します。
When the application program is next scheduled it examines the
queue and responds as it sees fit.
アプリケーション・プログラムが予定されていた状態で次であるときに、それは、待ち行列を調べて、適していると決めるように応じます。
[Page 5]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[5ページ]
It was generally agreed to adopt the TX-2 strategy. Input devices
will not be enabled unless the server does so.
一般に、テキサス-2戦略を採用するためにそれは同意されました。 サーバがそうしないと、入力装置は可能にされないでしょう。
No restriction is placed on any "lies" the using host wishes to
make regarding disguising one device as another.
どんな制限も置かれて、いずれではも、使用が「横たわっている」という別のものに1台のデバイスを変装することに関してするホスト願望ではありません。
Network connections for input follow the same rules as for output.
入力のためのネットワーク接続は出力のように同じ規則に従います。
What input attentions are implemented at the using host may be
determined by the serving host in response to an inquiry.
こころづくしを入力したことは使用のときに実装されて、ホストが問い合せに対応して給仕のホストによって決心されるかもしれないということです。
Inking will be provided by the using host (but only one inking
input can be specified at a time; no buffering ahead shall be done
by the using host).
インクで書くことは使用しているホストによって提供されるでしょう(一度に、入力をインクで書く1つしか指定できません; 使用しているホストは先でバッファリングしないものとします)。
Tracking means the feedback of the current two dimensional input
device position to the user.
追跡はユーザの現在の二次元入力装置位置のフィードバックを意味します。
This is automatically turned on by Inking, Positioning, and
Targeting (hitting) attentions.
これはInking、Positioning、およびTargeting(当たり)こころづくしによって自動的につけられています。
What data are reported at the time of an attention is specified by the application at the server when the attention is enabled.
注意が可能にされるとき、どんなデータが注意時点で報告されるかはサーバにおけるアプリケーションで指定されます。
Types of attentions were listed and also what additional optional information could be specified with each.
こころづくしのタイプを記載しました、そして、それぞれでどんな追加任意情報も指定できますか?
Deactivating Inputs was discussed.
Inputsを非活性化するのと議論しました。
It is possible for the application to explicitly deactivate an
attention.
アプリケーションが明らかに注意を非活性化するのは、可能です。
When an attention is enabled it shall be possible to specify when
it should be deactivated. Three modes were mentioned: Never
turned off (until the application explicitly does so), turned off
when it occurs (self-destruct), turned off when any attention
occurs.
注意が可能にされるとき、それがいつ非活性化されるべきであるかを指定するのは可能でしょう。 3つのモードが言及されました: 起こるとき(自爆してください)、オフ(アプリケーションが明らかにそうするまで)で、ターンされているのに決して離れてターンされていません、いつからターンされて、どんな注意も起こります。
The need for a synchronization message was agreed upon.
同期メッセージの必要性は同意されました。
It was agreed that the serving host - using host relationship would be one of master - slave. Among other things, the using host would never volunteer input information which the serving host (application) had not asked for.
同意された、それ、給仕のホスト--関係が使用するホストを使用して、マスター--奴隷には1つがありますか? 特に、使用しているホストは給仕のホスト(アプリケーション)が求めていなかった入力情報を決して、進んで提供しません。
It was decided to meet the next morning at 0830
それは、0830年に翌朝に会うために決められました。
The meeting adjourned about 1830
1830年頃に休会されたミーティング
[Page 6]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[6ページ]
Monday Evening, 16 July
月曜日の晩、7月16日
About 2030 seven of us met in Ken Victor's room
2030年頃に、私たち7人はケンビクタの部屋で会いました。
Bob Sproul led the meeting and kept track of the various aspects of the protocol.
ボブSproulはミーティングを導いて、プロトコルの種々相の動向をおさえました。
Protocol topics which had been discussed during the day's meeting were covered again. Most aspects were firmed up based on the day's discussions. Several topics were identified for discussion in the morning.
1日のミーティングの間に議論していたプロトコル話題は再びカバーされていました。 ほとんどの局面が1日の議論に基づいて堅かったです。 いくつかの話題が朝の議論のために特定されました。
Operations on and attributes of segments were defined.
セグメントの操作と属性は定義されました。
The server should be able to enquire for various information from the using host.
サーバは使用しているホストからの様々な情報について面会を求めることができるべきです。
Whether the using host has all the features implemented (which the
application needs).
使用しているホストはすべての特徴を実装させるのであるかどうか(アプリケーションが必要とする)
What input devices the human has at his disposal.
人間は彼の自由にどんな入力装置を持っていますか?
What sort of terminal is being used, not so as to send device
specific code to it, but so that the application does not try to
use some graphics programming technique on a terminal which can
not handle it (e.g., some sort of dynamics on a storage tube).
どういう端末が使用されているかので、デバイスの特定のコードをそれに送るのではなく、アプリケーションはそれ(例えば、蓄積管の上のある種の力学)を扱うことができない端末でテクニックをプログラムしながら、いくつかのグラフィックスを使用しようとしません。
The server may request that the using host report what segments have been defined, their status, and what is contained in then. This is good for debugging, and also provides a limited facility of building a picture then dumping it to some storage medium other than a graphics device.
サーバは、使用しているホストがどんなセグメントが定義されたか、そして、それらの状態、およびその時含まれていることを報告するよう要求するかもしれません。 これは、デバッグに良く、また、グラフィックスデバイス以外のいくらかの記憶媒体にそれをどさっと落としながら、その時画像を築き上げる限られた施設を提供します。
It was pointed out that the effect of multiple changes in the display (replacing, inserting and deleting segments) should occur "all at once" when an "end batch of updates" command is received by the using host.
「アップデートの終わりのバッチ」コマンドが使用しているホストによって受け取られるとき、ディスプレイ(セグメントを取り替えて、挿入して、削除する)における複数の変更箇所の効果が「一気に」起こるべきであると指摘されました。
For a refreshed display, this means keeping old and new copies of
segments until the "batch" command is received.
壮快なディスプレイのために、これは、「バッチ」コマンドが受け取られているまで古くて新しいコピーのセグメントを保つことを意味します。
This rule may be waived if storage limitations dictate.
ストレージ制限が命令するなら、この規則は放棄されるかもしれません。
[Page 7]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[7ページ]
There was considerable discussion on input. It was felt to be the least firm of any aspects of the protocol.
入力についてのかなりの議論がありました。 それはプロトコルのどんな局面の最少の会社であるとも感じられました。
The meeting broke up around 0030?
およそ0030への一文無しのミーティング?
Tuesday Morning/Afternoon, 17 July
火曜日の朝/午後、7月17日
Bob Sproul presented the results of the previous evening's discussion to the whole meeting.
ボブSproulはその前の晩の議論の結果を全体のミーティングに提示しました。
The features required of a graphics user program under the proposed protocol were divided into three classes:
提案されたプロトコルの下でグラフィックスユーザ・プログラムで必要な特徴は3つのクラスに分割されました:
Required features included segment manipulation, primitive
graphics output operations, and response to queries from the
server regarding what is implemented at the using host, what input
devices the human has available, etc.
必要な特徴は使用しているホスト、人間が利用可能にするすべての入力装置などで実装されることに関するサーバからのセグメント操作、原始のグラフィックス出力操作、および質問への応答を含んでいました。
Optional features included TTY units, reporting the contents of a
segment back to the server at his request.
彼の要求によるサーバにセグメントのコンテンツの報告を持ちかえって、オプション機能はTTYユニットを含んでいました。
Experimental features included Input.
実験特徴はInputを含んでいました。
It was assumed that after some experience, experimental
features would become either required or optional.
何らかの経験の後に実験特徴が必要であるか、または任意になると思われました。
A full list of required, optional, and experimental features will
be issued as a supplement to the description of the protocol.
補足として必要で、任意の、そして、実験している特徴に関する完全リストをプロトコルの記述に発行するでしょう。
A graphics server program need only implement those features which applications at that site make use of.
グラフィックスサーバプログラムはそのサイトのアプリケーションが利用するそれらの特徴を実装するだけでよいです。
There was some discussion regarding how and when the graphics protocol should be published.
グラフィックスプロトコルが発表されるべきであるどのように、時についての何らかの議論があったか。
The protocol is still regarded as experimental, and we wouldn't
want any site to assume otherwise, to their later dismay.
プロトコルはまだ実験的であると見なされています、そして、私たちは別の方法で後の彼らの驚愕のことに仮定するどんなサイトも欲しいと思わないでしょう。
Some worry was expressed about finally presenting this protocol to
the Network Community in a form that would not frighten too many
people.
何らかの心配が、あまりに多くの人々を怯えさせないフォームにおよそ最終的にこのプロトコルをNetwork Communityに提示しながら、言い表されました。
Ira Cotton advised us to include a glossary.
イラCottonは、私たちが用語集を入れるようにアドバイスしました。
Bob Sproul will put an initial version (skeleton) of a description
of the graphics protocol for transformed-segmented scheme into NLS
and will invite everybody in the group to edit it (in normal NLS
fashion).
ボブSproulは、変成して区分された体系のためにグラフィックスプロトコルの記述の初期のバージョン(骸骨)をNLSに置いて、グループのみんながそれ(正常なNLSファッションによる)を編集するよう誘うでしょう。
[Page 8]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[8ページ]
When one does editing normally, one's ident, the date and the
time are associated with each statement one touches. This
information can be seen via the viewspec (capital) K.
1つが通常編集するとき、人のident、期日、および時間は1つが触れる各声明に関連しています。 viewspec(首都)Kでこの情報を見ることができます。
There was some discussion of whether Level 0 NGP could be imbedded in the Transformed-segmented graphics protocol.
Transformedによって区分されたグラフィックスプロトコルでLevel0NGPを埋め込むことができたかどうかに関する何らかの議論がありました。
One unfortunate part of NGP-0 was that an End-Picture the is not
explicitly required in order to see something. If it were
required, then it could act like an end-batch-of-updates command.
NGP-0の1つの不幸な部分、それがEnd-画像であった、明らかに、何かを見るために、必要ではありません。 それが必要であるなら、アップデートの終わりのバッチコマンドのように行動できるでしょうに。
UCSB assumes that NGP-0 works like a storage tube. They append
a new function plot to an existing picture never having sent an
End-Picture operation.
UCSBは、NGP-0が蓄積管のように働いていると仮定します。 End-画像操作を一度も送ったことがなくて、彼らは新しい機能陰謀を既存の画像に追加します。
This ability to append in a storage tube fashion struck the
processors of refresh tubes as quite a drawback, because of
implementation difficulties.
ファッションがプロセッサの心を打った蓄積管の中で追加するこの能力はかなりの欠点としてチューブをリフレッシュします、実装困難のために。
It was decided to allow a using site to have NGP-0 compatibility,
but not to require it.
それは、使用サイトにはNGP-0の互換性がそれを必要とするのではなく、あるのを許容するために決められました。
At least the NGP-0 opcodes would not be reused.
少なくともNGP-0 opcodesは再利用されないでしょう。
Except for the End-Picture problem, and possibly also a coordinate system problem (coordsys), NGP-0 can be imbedded in the transformed- segmented protocol with the entire NGP-0 picture corresponding to a single segment.
End-画像問題、およびことによるとまた、座標系問題(coordsys)を除いて、ただ一つのセグメントに対応する全体のNGP-0画像で変成している区分されたプロトコルでNGP-0を埋め込むことができます。
The following sites hope to achieve implementations of the experimental segmented protocol:
以下のサイトは、実験区分されたプロトコルの実装を達成することを望んでいます:
UCSB hopes to have a server running for OLS and Signal Analysis
(speech processing).
UCSBは、OLSとSignal Analysis(スピーチ処理)に立候補するサーバを持っていることを望んでいます。
SRI-ARC hopes to have NLS operate in this protocol.
SRI-ARCは、NLSをこのプロトコルで作動させることを望んでいます。
MIT-DMCG may have some simple serving programs.
MIT-DMCGには、いくつかの簡単な給仕プログラムがあるかもしれません。
Several people plan to implement user programs, at least as far as
the required features go.
数人は、必要な特徴が行くのと少なくとも同じくらい遠いユーザ・プログラムを実装するのを計画しています。
(coordsys) A discussion arose concerning what coordinate system should be used in sending graphics output primitives from the server to the user.
(coordsys) どんな座標系が送付グラフィックス出力基関数で使用されるべきであるかに関して議論はサーバからユーザまで起こりました。
The following problems were addressed:
以下の問題は扱われました:
[Page 9]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[9ページ]
What happens if the display segment terminal screen area to be
used by the application is not rectangular?
アプリケーションで使用されるべきセグメントのディスプレイ端末画面領域が長方形でないなら、何が起こりますか?
What happens if the basic unit delta X is not the same as the
unit delta y? The application might want a 45 degree line to
really be at 45 degrees.
原単位デルタXがユニットデルタyと同じでないなら、何が起こりますか? アプリケーションは、45度合い系列が本当に45の度合いにある必要があるかもしれません。
Various answers to the first question:
1日の様々な答えは質問されます:
Use the largest square within the rectangle (centered?, adjusted
to the left, top, right, or bottom?)
長方形の中で最も大きい正方形を使用してください。(先端を左に調整されて、まさしく中心に置くか、または底に達します)?
Use the smallest square surrounding the rectangle. (How is the
rectangle positioned in the square?)
長方形を囲む最も小さい正方形を使用してください。 (長方形は正方形でどのように置かれますか?)
NGP-0 standard coordinates (-1/2 to +1/2) used and mapped into the
whole rectangle.
全体の長方形に使用されて、写像されたNGP-0の標準の座標(-1/2対+1/2)。
The user reports left, bottom, right, and top physical coordinates
and the server sends coordinates within the range given.
ユーザレポートは、いなくなって、右へ底に達して、物理的な座標を上回っています、そして、サーバは与えられた範囲の中で座標を送ります。
This is compatible with the attitude that the transformed (!)
segmented graphics data are sent.
これは変成している(!)がデータが送られるグラフィックスを区分したという態度と互換性があります。
It is also saves the using host (which might be an Imlac) from
doing a multiply.
また、使用が主催するセーブ(Imlacであるかもしれない)がaをするので増えるということです。
John Pickens observed that if a graphics server for a finicky application transmits characters as strokes, then the application is assured of having the characters positioned in exactly the right place (e.g., for a numeric label on a tic mark on the axis of a graph. If characters are sent as text (not strokes) positioning is not necessarily guaranteed.
ジョン・ピケンズは、気むずかしいアプリケーションのためのグラフィックスサーバがストロークとしてキャラクタを伝えるならアプリケーションがちょうど適当な場所にキャラクタを置かせるのを保証されるのを観測しました。例えば、aの軸でのチックマークの上の数値ラベルに関しては、グラフ化してください。(テキスト(ストロークでない)としてキャラクタを送るなら、必ず位置決めを保証するというわけではありません。
Ken Victor and Jim Michener will look into ways of keeping the NGG apprised of progress (in terms of what sites have experimental/operational graphics protocol servers or user programs) using a pointer file in the NIC.
ケンビクタとジム・ミッチェナーはNICの指針ファイルを使用することで進歩(どんなサイトでは実験用の、または、操作上のグラフィックスプロトコルサーバかユーザ・プログラムがあるかに関する)をNGGに知らせ続ける方法を調べるでしょう。
The next NGG meeting is tentatively scheduled for the first Sunday in February 73, at 8PM. It will either be at the NIC or partly there and partly at Xerox PARC.
次のNGGミーティングは午後8時に試験的に2月73日における最初の日曜日に予定されています。 一部NICにおいて、または、そこと一部ゼロックスPARCにそれはあるでしょう。
The meeting was adjourned at 1500.
ミーティングは1500年に休会されました。
[Page 10]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[10ページ]
Appendix: Meeting Participants/ Affiliation/ Online mailing address/ Attendance (S=Sunday, M=Monday day, E=Monday Evening, T=Tuesday)
付録: Participants/ Affiliation/のオンライン郵送先住所/出席を達成します。(S=日曜日、日、E=月曜日のEvening T=火曜日のM=月曜日)
Steve Bunch ILL-ANTS
BUNCH@ISI
SMT
スティーブ房の病気のアリの BUNCH@ISI SMT
Dan Cohen Harvard
DCOHEN@ISI or COHEN@HARVARD
SMET
ダンコーエンハーバード DCOHEN@ISI かコーエン@HARVARD SMET
Ira Cotton National Bureau of Standards
NBS-TIP@NIC attention Ira Cotton
SMET
イラCotton規格基準局の NBS-TIP@NIC 注意イラCotton SMET
John Day ILL-ANTS
S
ジョンデイ病気のアリのS
David Egli CAD/CAM (Fort Monmouth)
ECOM@BBN
SMT
デヴィッドEgli CAD/CAM(Fortモンマス) ECOM@BBN SMT
Jim Hansen ILL-ANTS
HANSEN@ISI
SMT
ジムハンセン病気のアリの HANSEN@ISI SMT
Jim Hart NASA/Ames
MT
ジム・ハート・NASA/エームズMT
Austin Henderson Lincoln Labs
DAH@TX2 or DAH@BBN
SMET
オースチンのヘンダーソンリンカーン研究室 DAH@TX2 か DAH@BBN SMET
Steve Holmgren ILL-ANTS
HOLMGREN@ISI
MT
スティーブホルムグレン病気のアリの HOLMGREN@ISI MT
John Jervert CAD/CAM (Fort Monmouth)
ECOM@BBN
SMT
ジョンJervert CAD/CAM(Fortモンマス) ECOM@BBN SMT
Alex McKenzie BBN
AAM in the journal or MCKENZIE@SRI-ARC
SMT
ジャーナルのアレックスマッケンジーBBN AAMか MCKENZIE@SRI-ARC SMT
James Michener MIT-DMCG
JCM in the journal or JCM@DMCG
SMET
ジャーナルのジェームスミッチェナーMIT-DMCG JCMか JCM@DMCG SMET
[Page 11]
RFC 549 Minutes of Network Graphics 15-17 July 1973
RFC549が書き留めるネットワークグラフィックス1973年7月15-17日の[11ページ]
John Pickens UCSB
JRP in the journal or UCSB@ISI (attn: John Pickens)
MT
ジャーナルか UCSB@ISI (attn: ジョン・ピケンズ)MTのジョンピケンズUCSB JRP
Ken Progran MIT-Multics
Pogran.CompNet at MIT-MULTICS
SMT
MIT-MULTICS SMTのケンProgran MIT-Multics Pogran.CompNet
Bob Sproul XEROX
SPROUL@MAXC
MET
ボブSproulゼロックス SPROUL@MAXC は会いました。
Elaine Thomas BBN
THOMAS@BBN
SMET
エレイントーマスBBN THOMAS@BBN SMET
Ken Victor SRI-ARC
VICTOR@NIC
SMET
ケンビクタ様アーク VICTOR@NIC SMET
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Via Genie ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via GenieによるオンラインRFCアーカイブへの]
[Page 12]
[12ページ]
一覧
スポンサーリンク
