RFC94 日本語訳
0094 Some thoughts on Network Graphics. E. Harslem, J.F. Heafner. February 1971. (Format: TXT=13516 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group E. Harslem Request for Comments: 94 J. Heafner NIC: 5725 3 February 1971
Harslemがコメントのために要求するワーキンググループE.をネットワークでつないでください: 94 J.Heafner NIC: 5725 1971年2月3日
Some Thoughts on Network Graphics
ネットワークグラフィックスに関するいくつかの考え
Purpose
目的
This note states some of our initial reactions to NWG/RFC #86, whose purpose was to provide a basis for discussion and development of Network graphics.
この注意はNetworkグラフィックスの議論と開発の基礎を提供する目的がことであったNWG/RFC#86への私たちの初期の反応のいくつかを述べます。
The method of operation described in Note 86 was to interpret data structures to produce graphic order codes for display. This method has proven satisfactory in the past and we favor this approach. The Note 86 proposal is directed toward a particular concept of operation (i.e., minimal graphics terminal connected to computational facilities at remote sites); our remarks embrace extended operations that include smart programs at each end of the connection as well as the minimal terminal.
Note86で説明された操作のメソッドはディスプレイのためにグラフィックオーダーコードを作成するためにデータ構造を解釈することでした。 このメソッドは過去に満足できると判明しました、そして、私たちはこのアプローチを支持します。 Note86提案は操作の特定の概念に向けられます(すなわち、最小量のグラフィックス端末はリモートサイトのコンピュータの施設に接続しました)。 私たちの所見は最小量の端末と同様に接続の各端のときにきびきびしたプログラムを含んでいる拡大手術を迎え入れます。
The proposal in Note 86 should be broadened to include the description of more complex entities and it should be raised to a level of describing more general things. In this note, we first criticize the limitations imposed by the details of Note 86; then suggest some supplementary ingredients to extend its scope; and lastly, we suggest an alternate approach that reduces Network conversations (where possible) to symbol manipulation rather than gross detail.
Note86での提案は、より複雑な実体の記述を含むように広くされるべきです、そして、それは、より一般的なものについて説明するレベルに上げられるべきです。 この注意では、私たちは最初に、Note86の細部によって課された制限を批評します。 次に、いくつかの補っている成分を示して、範囲を広げてください。 そして、最後に、私たちはNetworkの会話(可能であるところ)を総計の詳細よりむしろ記号処理に抑える代替のアプローチを勧めます。
Comments on the Detailed Restrictions of Note 86
注意86の詳細な制限のコメント
The detailed constraints enumerated in Note 86 restrict many interesting features of the Rand display hardware that we consider necessary (from a human factors standpoint) to some current applications. They likewise restrict other nodes whose ARPA- sponsored research is dependent upon the use of sophisticated hardware. For example, the point, vector, and character capability of Note 86 excludes line type mode, intensity control, and many other attractive control operations; the maximum symbol sizes are too small for our large character size; the origin of all of our symbols is specified as the "centroid" of the symbol rather than the lower left corner of a virtual rectangle encompassing the symbol; under mode control for plotting purposes, the beam may not be advanced to the next character position; a 7-bit ASCII is insufficient; etc. In short, the five list items of Note 86 are not expressive enough; for example, there is nothing to allow one to position and open a graphic
Note86で列挙された詳細な規制は私たちがいくつかの現在のアプリケーションに必要であると(人間の要素見地からの)考えるRandディスプレイハードウェアの多くのおもしろい特徴を制限します。 彼らは同様に、ARPA委託研究が精巧なハードウェアの使用に依存している他のノードを制限します。 例えば、Note86のポイント、ベクトル、およびキャラクタ能力は系列タイプモード、輝度調節、および多くの他の魅力的な制御機能を除きます。 私たちの大きいキャラクタサイズには、最大のシンボルサイズは小さ過ぎます。 私たちのシンボルのすべての発生源はシンボルを包含する仮想の長方形の左下隅よりむしろシンボルの「図心」として指定されます。 企み目的のためのモードコントロールの下では、次の欄的にビームに達しないかもしれません。 7ビットのASCIIは不十分です。 など 要するに、Note86の5つのリスト項目は十分表現していません。 例えば、何もグラフィックを置いて、開くために1つを許容するものがありません。
Harslem, et. al. [Page 1] RFC 94 Some Thoughts on Network Graphics February 1971
et Harslem、アル。 [1ページ]RFC94はネットワークグラフィックス1971年2月に関するいくつかの考えです。
compare "window". The problem was not treated of supplying parameters identifying structure for match, etc. that are not actual display commands.
「窓」を比較してください。 問題は、マッチのために構造を特定する実際の表示命令でないパラメタなどを供給しながら、扱われませんでした。
Perhaps some necessary information gathering (i.e., the display hardware descriptions and the characteristics of every node) is preliminary to the generation of a detailed specification. It is important that, without delay, a mechanism be defined for gathering and collating this information in such a way that it doesn't deter progress on Network graphics development.
恐らく何らかの必要事項集会(すなわち、ディスプレイハードウェア記述とあらゆるノードの特性)が仕様詳細の世代に予備です。 即刻、集会のために定義されて、そのような方法でこの情報を照合するそれが思いとどまらせないメカニズムがNetworkグラフィックス開発のときに進歩をするのは、重要です。
Some General Extensions to the Note 86 Proposal
注意86提案へのいくつかの一般拡大
1. DISPLAY LANGUAGE CAPABILITIES SHOULD ENCOMPASS THE UNION OF CURRENT AND ANTICIPATED NETWORK GRAPHICS HARDWARE. Our experience in exploring interactive graphics communication techniques for use by researchers and non-programmers indicates that this is not just a "motherhood". The utility of such applications programs depends highly upon incorporating sophisticated graphics hardware. In absence of those features, some programs simply won't be used.
1. ディスプレイ言語能力は現在の、そして、予期されたネットワークグラフィックスハードウェアの組合を取り囲むべきです。 研究者による使用のためにインタラクティブグラフィックスコミュニケーションのテクニックと非プログラマを探る私たちの経験は、これが「母性」であるだけではないと示します。 そのようなアプリケーションプログラムに関するユーティリティは精巧なグラフィックスハードウェアを組み込むのに非常によります。 それらの特徴の欠如では、いくつかのプログラムは絶対に使用されないでしょう。
2. THE DATA STRUCTURE SHOULD ALLOW LOGICAL AS WELL AS PICTORIAL REPRESENTATION OF THE USER'S PROBLEM. This close coupling of the meaning of a picture with the actual picture is desirable from a processing program's point of view, especially if a user is to interact with the picture. We have found this an efficient way to operate with the GRAIL Project and its derivatives here at Rand. This technique is included in a recently proposed graphics language generated by Bob Anderson (Rand) and Ben Wegbreit (Harvard).
2. データ構造はユーザの問題の論理的で絵の表現を許容するべきです。 実際の画像がある画像の意味のこの近いカップリングは処理プログラムの観点から望ましいです、特にユーザが画像と対話するつもりであるなら。 私たちは、これがここ、Randで聖杯Projectとその派生物で作動する効率的な方法であることがわかりました。 このテクニックはボブ・アンダーソン(底ならし革)とベンWegbreit(ハーバード)によって生成された最近提案されたグラフィックス言語に含まれています。
3. TRANSMIT DEFINITIONS OF GRAPHICS AND THEN INSTANCES OF THEIR USE. The attempt here is to raise the level of "conversation" between programs (where possible) and to reduce processing overhead. For example, if one wishes to draw lots of resistors, why not graphically define a resistor once and then transmit instances by giving the definition name accompanied by attributes? A typical form of an instance is shown below.
3. グラフィックスの定義を伝えて、次に、彼らの使用のインスタンスを伝えてください。 ここの試みは、プログラム(可能であるところ)の間の「会話」のレベルを上げて、処理のオーバーヘッドを減らすことになっています。 例えば、人が多くの抵抗体を描きたいなら、なぜ一度グラフィカルに抵抗体を定義して、次に、属性で伴走という定義名を与えることによって、インスタンスを伝えませんか? インスタンスの典型的な書式は以下に示されます。
Item Name (position, size, intensity, scaling, labeling, rotation, etc.)
項目名(ラベルして、サイズ、強度が回転などをスケーリングすることでの位置
There are many examples of this approach such as the recent work by William Newman (Utah) and many earlier studies at MIT.
ウィリアム・ニューマン(ユタ)による近作などのこのアプローチに関する多くの例と多くの以前の研究がMITにあります。
4. PARTITION THE DISPLAY STRUCTURE FOR 1) STATIC VS. DYNAMIC INFORMATION, AND 2) CONTEXT. As opposed to refreshing an entire picture whose domain is the entire screen, we have found it useful
4. 1のために)ディスプレイ構造を仕切ってください。 静的 動的情報、AND2) 文脈。 ドメインが全体のスクリーンである全体像をリフレッシュすることと対照的に、私たちは、それが役に立つのがわかりました。
Harslem, et. al. [Page 2] RFC 94 Some Thoughts on Network Graphics February 1971
et Harslem、アル。 [2ページ]RFC94はネットワークグラフィックス1971年2月に関するいくつかの考えです。
to give the processing routine (that wishes to draw a picture) knowledge of only of a named rectangular portion of the CRT and an accompanying display structure. With our particular hardware we can then update only the dynamic part of a picture rather than regenerating the entire display structure. Just as important, we can logically assign areas of the CRT to different concurrent processing routines. Coupled with the logical/pictorial representation noted in 2) above, this is a powerful technique. Named partitions also naturally accommodate those applications requiring multiple CRTs.
CRTの命名された長方形の部分と付随のディスプレイ構造だけについて処理ルーチン(それは絵を描きたがっている)知識を与えるために。 そして、私たちの特定のハードウェアで、私たちは全体のディスプレイ構造を作り直すよりむしろ画像のダイナミックな部分しかアップデートできません。 ちょうど同じくらい重要であることで、私たちは異なった同時処理ルーチンにCRTの領域を論理的に割り当てることができます。 2で注意した論理的に結びつけられたか、絵の表現) 上では、これが効果的な方法です。 また、命名されたパーティションは自然に複数のCRTを必要とするそれらのアプリケーションを収容します。
5. THE INTERPRETER COULD BE CONTEXT-DRIVEN THUS NOT RESTRICTING ITS OUTPUT TO A SINGLE SET OF CRT ORDER CODES. By providing cataloged descriptions such as the "forms" discussed in Note #83, the interpreter could reconfigure data destined for files, etc., as well as a display. The gain here in terms of adapting to a users' Network needs is large; the price paid in terms of implementing this increment of the interpreter is probably small.
5. インタプリタはその結果、出力を1セットのCRTオーダーコードに制限しないことにおいて文脈駆動であるかもしれません。 Note#83で議論した「フォーム」などのカタログに載せられた記述を提供することによって、インタプリタはファイルなどのために運命づけられたデータを再構成できるでしょう、ディスプレイと同様に。 ここのユーザのNetworkの必要性に合わせることに関する利得は大きいです。 インタプリタのこの増分を実装することに関して支払われた価格はたぶんわずかです。
An Alternate Proposal
代替の提案
Note 86 mentions the case of a terminal at a node with a minimal HOST connected to a remote computationally-oriented node. The data standard, which Note 86 suggests transmitting over the Network is rather gross detail. Also, the standard language is rather inexpressive -- encompassing only a few simple notions.
最小量のHOSTがリモート計算上指向のノードに接続される状態で、注意86はノードで端末のケースについて言及します。 データの規格であり、どのNote86が、Networkの上を伝わるのを示すかは、かなり総計の詳細です。 また、ほんのいくつかの簡単な概念を包含して、標準語もかなり無表情です。
An alternative approach is to consider the situation of communication between non-minimal nodes (nodes with substantial memory and computing power). Here the Network standard data should be a high- level macro form representing the instances of gross detail with the power to deal with sophisticated graphics devices. That is, the standard language would be rich enough to express all the special features of Network display devices.
代替的アプローチは非最小量のノード(かなりの記憶とパワーを計算するノード)のコミュニケーションの状況を考えることです。 ここで、Networkの標準のデータは精巧なグラフィックスデバイスに対処するパワーで総計の詳細のインスタンスを表す高値レベルマクロフォームであるべきです。 すなわち、標準語はNetworkディスプレイ装置のすべての特徴を言い表すほど豊かでしょう。
This suggestion presents two problems. First, how can a terminal handle commands from a remote program of which its hardware is incapable? The answer is that the remote program to which it is connected is too sophisticated for the terminal -- the connection is invalid. A terminal should NORMALLY only connect to a program that addresses no more than its hardware capabilities. This concept allows a standard under which a simple terminal and a simple program can communicate (exactly the proposal of Note 86), yet a sophisticated terminal can talk to a sophisticated program in a high-level language, or it can talk to a simple program, all within the same Network standard.
この提案は2つの問題を提示します。最初に、端末はハードウェアが不可能であるリモートプログラムからコマンドをどのように扱うことができますか? 答えは端末には、それが接続されているリモートプログラムが精巧過ぎるということです--接続は無効です。 端末は接続するべきです。NORMALLYはそれがハードウェア能力だけであると扱うプログラムに接続するだけです。 この概念が簡単な端末と簡単なプログラムが伝えることができる規格(まさにNote86の提案)を許容するとしかし、高性能の端末が高位言語における精巧なプログラムと話すことができますか、または簡単なプログラムと話すことができます、同じNetwork規格の中で。
Harslem, et. al. [Page 3] RFC 94 Some Thoughts on Network Graphics February 1971
et Harslem、アル。 [3ページ]RFC94はネットワークグラフィックス1971年2月に関するいくつかの考えです。
The second problem is that a minimal host might not have sufficient facilities to translate from a powerful Network standard language into the simple, detailed order codes of its terminals.
2番目の問題は最小量のホストが強力なNetwork標準語から端末の簡単で、詳細なオーダーコードに翻訳できるくらいの施設を持っていないかもしれないということです。
When required, the needs of a minimal site would be handled by another Network node providing data reconfiguration services, AN ESSENTIAL PART OF THIS PROPOSAL. The reconfiguration would be done on the basis of "forms" specifying translation form the Network standard to the specific non-standard data format required by the minimal node (i.e., tailored specifically to its hardware). Whether it would be graphic order codes or some intermediate form would depend on the processing power and requirements of the minimal node.
必要であると、最小量のサイトの必要性はデータ再構成サービス(AN ESSENTIAL PART OF THIS PROPOSAL)を備える別のNetworkノードで扱われるでしょう。 「フォーム」に基づいて、最小量のノード(すなわち、特にハードウェアに仕立てられる)で特定の標準的でないデータの形式へのNetwork規格が必要とした翻訳フォームを指定しながら、再構成するでしょう。 それがグラフィックオーダーコードかそれとも何らかの中間的フォームであるだろうかが最小量のノードの処理能力と要件に依存するでしょう。
Fig. 1 shows a schematic diagram of the key elements of such a reconfiguration facility. Fig. 2 shows the use of that facility by a local display handler and its use as an intermediary by two remote nodes requiring different degrees of external data reconfiguration.
図1はそのような再構成施設の主要な要素の回路図を示しています。 図2は仲介者として異なった度合いの外部のデータ再構成を必要とする2つの遠隔ノードで地元のディスプレイ操作者によるその施設の使用とその使用を示しています。
Harslem, et. al. [Page 4] RFC 94 Some Thoughts on Network Graphics February 1971
et Harslem、アル。 [4ページ]RFC94はネットワークグラフィックス1971年2月に関するいくつかの考えです。
Network | ^ | | | | v | +--------------+ | A Network | Local | Process |---> Files, Programs, | Invoking the |<--- CRTs, etc. | Interpreter | +--------------+ | ^ | | | | v | +--------------+ +--------------+ (A user can access | | | User's | the logical |-->| Interpreter | | Semantic | representation of | | | | Routines | his problem.) | +--------------+ +--------------+ | | ^ | ^ | | | | | | | | | | | v | v | | +-------------------+ | | | | | Primitive | | | Data Structure | | | Operators | | | | | +-------------------+ | | ^ | | | +--------------+ | | | Data Base of | v | | "Forms" for | +------------------+ | Reconfigu- | | Data Structure | | ration | | Base: | +--------------+ | 1 - Pictorial | | 2 - Logical | +------------------+
ネットワーク| ^ | | | | v| +--------------+ | ネットワーク| ローカル| プロセス|--->ファイル、プログラム| 呼び出し| <、-、-- CRTなど | インタプリタ| +--------------+ | ^ | | | | v| +--------------+ +--------------+、(缶がアクセスするユーザ| | | ユーザのもの| 論理的| -->| インタプリタ| | 意味|、| | | | ルーチン| 彼の問題の表現)。 | +--------------+ +--------------+ | | ^ | ^ | | | | | | | | | | | v| v| | +-------------------+ | | | | | 原始| | | データ構造| | | オペレータ| | | | | +-------------------+ | | ^ | | | +--------------+ | | | データベース| v| | 「形成します」。| +------------------+ | Reconfigu| | データ構造| | 割り当て| | 以下を基礎づけてください。 | +--------------+ | 1--画報| | 2--、論理的| +------------------+
Fig. 1. Data Reconfiguration Service
図1。 データ再構成サービス
Harslem, et. al. [Page 5] RFC 94 Some Thoughts on Network Graphics February 1971
et Harslem、アル。 [5ページ]RFC94はネットワークグラフィックス1971年2月に関するいくつかの考えです。
Host Providing Host Providing Computational Facility Reconfiguration Service +--------------------+ STANDARD +-----------------------------+ | | FORMAT | +----------+ +-----------+ | | |------------|--| Inter- |-| Display | | | | (of Macro | /| preter | | Handler | | | | Form Data) |//+----------+ +-----------+ | +--------------------+ //--------------------|-------+ // | /( +-----------+ / \ | Terminal | / \ +-----------+ / \ / \ / \ NON-STD. / \ NON-STD. (Terminal Order Codes) / \ (Detailed Data) / \ / \ / \ / \ / \ / \ | | +-------|-------+ +-------|-------+ | | | | +-----------+ | Minimum | | | | | Display | | Minimum Host | | | | | Handler | | Host | | | | +-----------+ | +-------|-------+ +-------|-------+ | | +-----------+ +-----------+ | Terminal | | Terminal | +-----------+ +-----------+
コンピュータの施設再構成サービス+を提供するホストを提供するホスト--------------------+ 規格+-----------------------------+ | | 形式| +----------+ +-----------+ | | |------------|--| 相互|-| ディスプレイ| | | | (Macro|/|preter| | 操作者| | | | フォームDataの) |//+----------+ +-----------+ | +--------------------+ //--------------------|-------+ // | /( +-----------+ / \ | Terminal | / \ +-----------+ / \ / \ / \ NON-STD. / \ NON-STD. (Terminal Order Codes) / \ (Detailed Data) / \ / \ / \ / \ / \ / \ | | +-------|-------+ +-------|-------+ | | | | +-----------+ | Minimum | | | | | Display | | Minimum Host | | | | | Handler | | Host | | | | +-----------+ | +-------|-------+ +-------|-------+ | | +-----------+ +-----------+ | Terminal | | Terminal | +-----------+ +-----------+
Fig. 2. Use of Data Reconfiguration Service
図2。 データ再構成サービスの使用
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Sergio Kleiman]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][セルジオKleimanによるオンラインRFCアーカイブへの]
Harslem, et. al. [Page 6]
et Harslem、アル。 [6ページ]
一覧
スポンサーリンク