rfc2083.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

         When the unit specifier is 0, the pHYs chunk defines pixel
         aspect ratio only; the actual size of the pixels remains
         unspecified.

         Conversion note: one inch is equal to exactly 0.0254 meters.

         If this ancillary chunk is not present, pixels are assumed to
         be square, and the physical size of each pixel is unknown.

         If present, this chunk must precede the first IDAT chunk.

         See Recommendations for Decoders: Pixel dimensions (Section
         10.2).

      4.2.6. sBIT Significant bits

         To simplify decoders, PNG specifies that only certain sample
         depths can be used, and further specifies that sample values
         should be scaled to the full range of possible values at the
         sample depth.  However, the sBIT chunk is provided in order to
         store the original number of significant bits.  This allows



Boutell, et. al.             Informational                     [Page 22]

RFC 2083            PNG: Portable Network Graphics            March 1997


         decoders to recover the original data losslessly even if the
         data had a sample depth not directly supported by PNG.  We
         recommend that an encoder emit an sBIT chunk if it has
         converted the data from a lower sample depth.

         For color type 0 (grayscale), the sBIT chunk contains a single
         byte, indicating the number of bits that were significant in
         the source data.

         For color type 2 (truecolor), the sBIT chunk contains three
         bytes, indicating the number of bits that were significant in
         the source data for the red, green, and blue channels,
         respectively.

         For color type 3 (indexed color), the sBIT chunk contains three
         bytes, indicating the number of bits that were significant in
         the source data for the red, green, and blue components of the
         palette entries, respectively.

         For color type 4 (grayscale with alpha channel), the sBIT chunk
         contains two bytes, indicating the number of bits that were
         significant in the source grayscale data and the source alpha
         data, respectively.

         For color type 6 (truecolor with alpha channel), the sBIT chunk
         contains four bytes, indicating the number of bits that were
         significant in the source data for the red, green, blue and
         alpha channels, respectively.

         Each depth specified in sBIT must be greater than zero and less
         than or equal to the sample depth (which is 8 for indexed-color
         images, and the bit depth given in IHDR for other color types).

         A decoder need not pay attention to sBIT: the stored image is a
         valid PNG file of the sample depth indicated by IHDR.  However,
         if the decoder wishes to recover the original data at its
         original precision, this can be done by right-shifting the
         stored samples (the stored palette entries, for an indexed-
         color image).  The encoder must scale the data in such a way
         that the high-order bits match the original data.

         If the sBIT chunk appears, it must precede the first IDAT
         chunk, and it must also precede the PLTE chunk if present.

         See Recommendations for Encoders: Sample depth scaling (Section
         9.1) and Recommendations for Decoders: Sample depth rescaling
         (Section 10.4).




Boutell, et. al.             Informational                     [Page 23]

RFC 2083            PNG: Portable Network Graphics            March 1997


      4.2.7. tEXt Textual data

         Textual information that the encoder wishes to record with the
         image can be stored in tEXt chunks.  Each tEXt chunk contains a
         keyword and a text string, in the format:

            Keyword:        1-79 bytes (character string)
            Null separator: 1 byte
            Text:           n bytes (character string)

         The keyword and text string are separated by a zero byte (null
         character).  Neither the keyword nor the text string can
         contain a null character.  Note that the text string is not
         null-terminated (the length of the chunk is sufficient
         information to locate the ending).  The keyword must be at
         least one character and less than 80 characters long.  The text
         string can be of any length from zero bytes up to the maximum
         permissible chunk size less the length of the keyword and
         separator.

         Any number of tEXt chunks can appear, and more than one with
         the same keyword is permissible.

         The keyword indicates the type of information represented by
         the text string.  The following keywords are predefined and
         should be used where appropriate:

            Title            Short (one line) title or caption for image
            Author           Name of image's creator
            Description      Description of image (possibly long)
            Copyright        Copyright notice
            Creation Time    Time of original image creation
            Software         Software used to create the image
            Disclaimer       Legal disclaimer
            Warning          Warning of nature of content
            Source           Device used to create the image
            Comment          Miscellaneous comment; conversion from
                             GIF comment

         For the Creation Time keyword, the date format defined in
         section 5.2.14 of RFC 1123 is suggested, but not required
         [RFC-1123].  Decoders should allow for free-format text
         associated with this or any other keyword.

         Other keywords may be invented for other purposes.  Keywords of
         general interest can be registered with the maintainers of the
         PNG specification.  However, it is also permitted to use
         private unregistered keywords.  (Private keywords should be



Boutell, et. al.             Informational                     [Page 24]

RFC 2083            PNG: Portable Network Graphics            March 1997


         reasonably self-explanatory, in order to minimize the chance
         that the same keyword will be used for incompatible purposes by
         different people.)

         Both keyword and text are interpreted according to the ISO
         8859-1 (Latin-1) character set [ISO-8859].  The text string can
         contain any Latin-1 character.  Newlines in the text string
         should be represented by a single linefeed character (decimal
         10); use of other control characters in the text is
         discouraged.

         Keywords must contain only printable Latin-1 characters and
         spaces; that is, only character codes 32-126 and 161-255
         decimal are allowed.  To reduce the chances for human
         misreading of a keyword, leading and trailing spaces are
         forbidden, as are consecutive spaces.  Note also that the non-
         breaking space (code 160) is not permitted in keywords, since
         it is visually indistinguishable from an ordinary space.

         Keywords must be spelled exactly as registered, so that
         decoders can use simple literal comparisons when looking for
         particular keywords.  In particular, keywords are considered
         case-sensitive.

         See Recommendations for Encoders: Text chunk processing
         (Section 9.7) and Recommendations for Decoders: Text chunk
         processing (Section 10.11).

      4.2.8. tIME Image last-modification time

         The tIME chunk gives the time of the last image modification
         (not the time of initial image creation).  It contains:

            Year:   2 bytes (complete; for example, 1995, not 95)
            Month:  1 byte (1-12)
            Day:    1 byte (1-31)
            Hour:   1 byte (0-23)
            Minute: 1 byte (0-59)
            Second: 1 byte (0-60)    (yes, 60, for leap seconds; not 61,
                                      a common error)

         Universal Time (UTC, also called GMT) should be specified
         rather than local time.








Boutell, et. al.             Informational                     [Page 25]

RFC 2083            PNG: Portable Network Graphics            March 1997


         The tIME chunk is intended for use as an automatically-applied
         time stamp that is updated whenever the image data is changed.
         It is recommended that tIME not be changed by PNG editors that
         do not change the image data.  See also the Creation Time tEXt
         keyword, which can be used for a user-supplied time.

      4.2.9. tRNS Transparency

         The tRNS chunk specifies that the image uses simple
         transparency: either alpha values associated with palette
         entries (for indexed-color images) or a single transparent
         color (for grayscale and truecolor images).  Although simple
         transparency is not as elegant as the full alpha channel, it
         requires less storage space and is sufficient for many common
         cases.

         For color type 3 (indexed color), the tRNS chunk contains a
         series of one-byte alpha values, corresponding to entries in
         the PLTE chunk:

            Alpha for palette index 0:  1 byte
            Alpha for palette index 1:  1 byte
            ... etc ...

         Each entry indicates that pixels of the corresponding palette
         index must be treated as having the specified alpha value.
         Alpha values have the same interpretation as in an 8-bit full
         alpha channel: 0 is fully transparent, 255 is fully opaque,
         regardless of image bit depth. The tRNS chunk must not contain
         more alpha values than there are palette entries, but tRNS can
         contain fewer values than there are palette entries.  In this
         case, the alpha value for all remaining palette entries is
         assumed to be 255.  In the common case in which only palette
         index 0 need be made transparent, only a one-byte tRNS chunk is
         needed.

         For color type 0 (grayscale), the tRNS chunk contains a single
         gray level value, stored in the format:

            Gray:  2 bytes, range 0 .. (2^bitdepth)-1

         (For consistency, 2 bytes are used regardless of the image bit
         depth.) Pixels of the specified gray level are to be treated as
         transparent (equivalent to alpha value 0); all other pixels are
         to be treated as fully opaque (alpha value (2^bitdepth)-1).






Boutell, et. al.             Informational                     [Page 26]

RFC 2083            PNG: Portable Network Graphics            March 1997


         For color type 2 (truecolor), the tRNS chunk contains a single
         RGB color value, stored in the format:

            Red:   2 bytes, range 0 .. (2^bitdepth)-1
            Green: 2 bytes, range 0 .. (2^bitdepth)-1
            Blue:  2 bytes, range 0 .. (2^bitdepth)-1

         (For consistency, 2 bytes per sample are used regardless of the
         image bit depth.) Pixels of the specified color value are to be
         treated as transparent (equivalent to alpha value 0); all other
         pixels are to be treated as fully opaque (alpha value
         (2^bitdepth)-1).

         tRNS is prohibited for color types 4 and 6, since a full alpha
         channel is already present in those cases.

         Note: when dealing with 16-bit grayscale or truecolor data, it
         is important to compare both bytes of the sample values to
         determine whether a pixel is transparent.  Although decoders
         may drop the low-order byte of the samples for display, this
         must not occur until after the data has been tested for
         transparency.  For example, if the grayscale level 0x0001 is
         specified to be transparent, it would be incorrect to compare
         only the high-order byte and decide that 0x0002 is also
         transparent.

         When present, the tRNS chunk must precede the first IDAT chunk,
         and must follow the PLTE chunk, if any.

      4.2.10. zTXt Compressed textual data

         The zTXt chunk contains textual data, just as tEXt does;
         however, zTXt takes advantage of compression.  zTXt and tEXt
         chunks are semantically equivalent, but zTXt is recommended for
         storing large blocks of text.

         A zTXt chunk contains:

            Keyword:            1-79 bytes (character string)
            Null separator:     1 byte
            Compression method: 1 byte
            Compressed text:    n bytes

         The keyword and null separator are exactly the same as in the
         tEXt chunk.  Note that the keyword is not compressed.  The
         compression method byte identifies the compression method used
         in this zTXt chunk.  The only value presently defined for it