[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Metadata: Unify text compression method attributes
From:       Martin.vGagern () gmx ! net (Martin von Gagern)
Date:       2008-12-08 13:46:07
Message-ID: 493D251F.5090708 () gmx ! net
[Download RAW message or body]

Hi!

As it seems that my previous PNG metadata patches are going somewhere,
and also that serious feature changes require a lot of time, I now want
to discuss a thing I noticed when working on the PNG metadata.

Consider a PNG file with compressed text chunks. How would they be
expressed in Metadata?
standard metadata: compression="zip"
png metadata zTXt: compressionMethod="deflate"
png metadata iTXt: compressionFlag="TRUE" compressionMethod="0"

All the time the underlying compression method is the same.
I suggest the following changes:

1. add "deflate" to the list of allowed values for the compression
attribute in the standard metadata format.
Rationale: to me, "zip" and "deflate" are different things. This
corresponds to the difference between ZipOutputStream and
DeflaterOutputStream in java.util.zip. I don't know whether there is in
fact any image format actually using "zip", or if the meaning is
"deflate" in every instance. If so, the "zip" value might be replaced.

2. change the combination of compressionFlag and compressionMethod for
iTXt chunks to a single compression attribute with enumerated values,
including the values "none" and "deflate".
Rationale: Having to deal with integer constants defined in the PNG
specification is cumbersome and contrary to implementation elsewhere in
the metadata formats. Using "none" as one of the values gets rid of the
separate compressionFlag and thus avoids dealing with strange cases
where compressionFlag is "FALSE" and the compressionMethod attrribute is
missing, unallowed, or whatever.

As both these changes break compatibility, I guess they both should be
included in a version bump of the metadata formats from 1.0 to 1.1.
Large parts of the metadata handling code would be unaffected by this
change, only a few places would require case distinctions.

If you agree with my opinions, I would start working on an appropriate
patch. If you have different suggestions, let me know. If there is
something else that would require a bump of metadata versions, now would
be a good time to collect this information.

Greetings,
 Martin von Gagern

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20081208/b434df08/attachment.bin 

[prev in list] [next in list] [prev in thread] [next in thread]