RFC797 日本語訳

0797 Format for Bitmap files. A.R. Katz. September 1981. (Format: TXT=3067 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                            A. Katz
Request for Comments: 797                                            ISI
                                                          September 1981

コメントを求めるワーキンググループA.キャッツ要求をネットワークでつないでください: 797 ISI1981年9月

                        FORMAT FOR BITMAP FILES

ビットマップ・ファイルのための形式

   This note describes a proposed format for storing simple bitmaps (one
   bit per pixel)  in a file.   These  files  may be very  large and the
   intent  is to use this format for short term storage and passing data
   between  closely  coupled  programs.   The data in the file should be
   stored in 8-bit bytes (octets).  Bitmaps may be any size.

この注意はファイルの簡単なビットマップ(1画素あたり1ビット)を格納するための提案された形式について説明します。 意図はこれらのファイルが非常に大きいかもしれなく、短期間格納と密接に結合したプログラムの間にデータを通過するのにこの形式を使用することです。8ビットのバイト(八重奏)でファイルのデータは格納されるべきです。 ビットマップはどんなサイズであるかもしれません。

   The first  4 octets  of the file  gives  the width  of each  line  (x
   direction),  and the next 4 octets should give the number of lines of
   the display  (length, y direction). After this is one octet for the x
   increment  and one octet for the y  increment.   Following  these  10
   octets  is the bitmap  itself.     The length  and width  fields  are
   stored most significant octet first.

ファイルの最初の4つの八重奏がそれぞれの線(x指示)の幅を与えます、そして、次の4つの八重奏が表示(長さ、y指示)の線の数を与えるべきです。 これがx増分のための1つの八重奏とy増分のために八重奏に1なった後に。 これらの10の八重奏に続くのは、ビットマップ自体です。 最初に、長さと幅の分野は格納された最も重要な八重奏です。

   The x and y increment  octets  tell how much space is between pixels.
   For an ordinary display, both these would be one.

xとy増分の八重奏は、画素の間には、どのくらいのスペースがあるかを言います。 普通の表示、これらがそうする両方に関しては1になってください。

   Each line of the display  should  be scanned  from left to right. The
   lines should start at the top and work down.  Each line in the bitmap
   should  end on an octet boundary.  If the width of the display is not
   divisable  by 8,  the rest of the last octet  should  be filled  with
   zeros on the right.

表示の各線は左から右までスキャンされるべきです。 線は、先端で始まって、徐々に下がるはずです。 ビットマップの各線は八重奏境界で終わるはずです。 表示の幅が8時までにdivisableでないなら、最後の八重奏の残りは右のゼロでいっぱいにされるべきです。

   Below  is a representation  of a bitmap  file  (each  square  is  one
   octet):

以下に、ビットマップ・ファイルの表現があります(各正方形は1つの八重奏です):

      ----------------------------------------------------------
      |    1     |    2     |    3     |     4     |     5     |
      |  width   |  width   |  width   |   width   |  length   |
      ----------------------------------------------------------

---------------------------------------------------------- | 1 | 2 | 3 | 4 | 5 | | 幅| 幅| 幅| 幅| 長さ| ----------------------------------------------------------

      ----------------------------------------------------------
      |     6    |     7    |     8    |     9     |     10    |
      |  length  |  length  |  length  |x-increment|y-increment|
      ----------------------------------------------------------

---------------------------------------------------------- | 6 | 7 | 8 | 9 | 10 | | 長さ| 長さ| 長さ|x-増分|y-増分| ----------------------------------------------------------

      ----------------------------------------------------------
      |   11     |   12     |   13     |    14     |   15
      |  data    |  data    |  data    |   data    |  data...
      ----------------------------------------------------------

---------------------------------------------------------- | 11 | 12 | 13 | 14 | 15 | データ| データ| データ| データ| データ… ----------------------------------------------------------

   For example,  bitmaps  from the RAPICOM  450 can be in  Fine  Detail,
   Quality,  or Express  Mode.   In Fine Detail mode the x-increment and
   y-increment  would be 1, for Quality mode, the x-increment would be 1
   and the y-increment would be 2, and for Express mode, the x-increment

例えば、RAPICOM450からのビットマップがすばらしいDetail、Quality、またはExpress Modeにあることができます。 すばらしいDetailモードで、x-増分とy-増分は1でしょう、Qualityモードのためにx-増分が1であるだろう、2であり、y-増分はExpressモードのための1でしょう、x-増分

Alan R. Katz                                                    [page 1]

アラン・R.キャッツ[1ページ]

   would  be 1 and the y-increment  would be 3.  For these bitmaps it is
   intended  that each scan line be repeated y-increment times when they
   are displayed.

1であるだろう、y-増分は3でしょう。 これらのビットマップに関しては、それぞれのスキャン線がそれらが表示される繰り返されたy-増分の回であることを意図します。

[page 2]                                                    Alan R. Katz

[2ページ] アラン・R.キャッツ

一覧

 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 

スポンサーリンク

PostgreSQLでERROR: duplicate key value violates unique constraint "hoge_pkey" DETAIL: Key (id)=(10) already exists.と出る場合

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

上に戻る