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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

WEEK関数 通算週を求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る