xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38183] - [PATCH] Compatibility with GNU Classpath
Date Tue, 10 Jan 2006 12:06:28 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38183>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38183





------- Additional Comments From jeremias@apache.org  2006-01-10 13:06 -------
(In reply to comment #4)
> Thanks!  a few comments:
> 
> > The "internal codecs" as I called them are moved to a new source 
> > directory (sources-internal-codec)
> 
>    I will probably not do this, I will move them all into a common
> package instead.

Ok, but that will make it more difficult to work with in an IDE. Now I can just
remove the sources-internal-codec from the source dir list and work with Batik
in a GNU-Classpath-compatible way. Sure, it's easy to keep the things apart in
the Ant build but having a clean separation helps a lot, especially in showing
the dependencies. I guess we're back to the same argument we had with XML
Graphics Commons.

> >- I've not reimplemented every single feature in the various image 
> > transcoders for the Image I/O API as is available for the internal 
> > codecs. Examples are Gamma/Chromaticity handling and background 
> > color in PNG.
> 
>    Hmm, gamma handling _is_ important for PNG (especially on decode).  
> This is why we moved from using the JDK decoder to our own local one. 
> Fortunately this is not the real problem area with the Batik
> codecs - so I will see what can be done.

I guessed as much. Thanks.

>    On Tiff it isn't the most important part.  It would be nice for
> some use cases.
> 
> > - I've experienced problems handling metadata and encoding parameters 
> > when writing JPEG images through Image I/O. The current code works 
> > for most use cases, though.
> 
>    This is a little more troubling, what sorts of problems?

The main problem is that the JPEG codec does not support setting the bitmap
resolution through the standard metdata format. Image I/O has a good concept for
handling metadata but the implementation is a catastrophe. Other problems mostly
involved IIOMetadata.setFromTree/mergeFromTree(). Settings get lost when merging
and stuff like that. A lot of trial and error was necessary to get this far and
I've found almost no helpful resources on the net.

> > - The TIFFTranscoder now supports specifying the compression 
> > method through a Transcoding hint (type String).
> 
>    Sounds good!
> 
> > - I've changed the code that prepares an XML parser to use JAXP in 
> > order to remove the mandatory dependency on Apache Xerces. I hope 
> > I did this the right way.
> 
>     This also looks good.
> 
> > You can forcibly disable the compilation of the Sun-dependant 
> > internal codecs if you create a file (called "build-local.properties")
> 
>     Is there any reason you didn't use 'build.properties' file?
> This file is only used for 'local' mods anyways (otherwise you would
> put them in the ant file wouldn't you?).

I like to separate build.properties from build-local.properties, because that
latter is normally in the ignores list, so people can override their build
settings without accidentally committing their special settings to the
repository. A build.properties can help a lot for specifying default behaviour
and serving as a template for a build-local.properties. See FOP where this is
done very cleanly.

BTW, I'm very surprised about the amount of attention this patch already got.
Looks like I picked something important. :-)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org


Mime
View raw message