Re: CALL for DISCUSSION: cOMp/cOMP/coMp/coMP: compression wrapper chunks

It seems to me that adding explanation both creates an impression of
complexity and confuses about the meaning.  The entire definition was
contained in the one paragraph at the start:

   The data of each chunk contains another chunk of the corresponding
   chunk type as described in ISO-PNG "5.3 Chunk layout" except that
   the original "Chunk Data" is compressed as described below and the
   CRC is omitted.

So a simplified re-wording of the proposal which also removes the
unnecessary complexity of special chunks for compressing private
chunks is:

   The cOMp chunk contains a compressed safe-to-copy ancillary chunk.
   The cOMP chunk contains a compressed unsafe-to-copy ancillary chunk.

   The data of each chunk contains another chunk of the corresponding
   chunk type encoded as described in ISO-PNG "5.3 Chunk layout" except
   that the original "Chunk Data" is compressed the CRC is omitted.

   The compressed "Chunk Data" consists of a compression method byte
   followed by the bytes of the original "Chunk Data" compressed with that
   method.  Only method byte 0 is defined and this shall indicate that Zlib
   compressed data follows, as defined in RFC-1950.

   The compressed chunk shall not be a chunk defined in ISO-PNG except
   that sPLT may be compressed.  A decoder shall discard a cOMp chunk
   containing an unsafe-to-copy original chunk and a cOMP chunk containing
   a safe-to-copy original chunk.

John Bowler

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot