List Info

Thread: DO NOT REPLY Compatibility with GNU Classpath




DO NOT REPLY Compatibility with GNU Classpath
user name
2006-01-08 16:42:34
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=38
183>.
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

           Summary: [PATCH] Compatibility with GNU Classpath
           Product: Batik
           Version: 2.0
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: PatchAvailable
          Severity: enhancement
          Priority: P2
         Component: (RFE) Request For Extension
        AssignedTo: batik-devxmlgraphics.apache.org
        ReportedBy: jeremiasapache.org


As discussed and promised some time ago, I finally managed
to get everything
together and submit a patch to remove Batik's mandatory
dependency on
Sun-private classes in its codec classes. This patch
introduces adapter classes
to decouple the image decoding and encoding from the actual
codec library used.
The "internal codecs" as I called them are moved
to a new source directory
(sources-internal-codec), so their compilation can be made
optional in an IDE
and in the Ant build. In addition to adapter classes
handling image loading and
saving using these internal codecs, I've written
implementations that use the
Image I/O API that is available under JDK 1.4 (and later)
and in GNU Classpath.
Please note: So far I have not done any tests with GNU
Classpath (GCJ, IKVM or
whatever) for Batik.

A few implementation notes:
- 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.
- I've had endless loops in
ImageIO.getImageWritersByMIMEType() and
IIOMetadata.mergeTree() while trying to write TIFF images
through the Image I/O
API with the JAI Image I/O Tools in the classpath. (I think
TIFF is only
supported by Image I/O under a Sun JDK if the JAI Image I/O
Tools are available)
That means that there are probably a few bugs hidden in
there. I didn't go too
deep in order not to lose too much time.
- 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.
- I created a new batik-codec.jar in the Ant build that
contains the internal
codec classes. I hope I got the dependencies right there.

In addition to the above topic, the patch contains the
following changes:
- The TIFFTranscoder now supports specifying the compression
method through a
Transcoding hint (type String).
- 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.

Before applying the patch it is ESSENTIAL to do local SVN
copy operations
(versioned copies) for the following files:
sources/org/apache/batik/ext/awt/image/spi/*RegistryEntry.ja
va (-->
sources-internal-codec)
sources/org/apache/batik/ext/awt/image/codec/**/* (-->
sources-internal-codec)
resources/org/apache/batik/ext/awt/image/codec/properties
(-->
sources-internal-codec)

Please see the status-log.txt file in the ZIP I'll attach.
It shows how exactly
I moved these classes (Watch for the "+").

Attaching the patch in a minute...

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

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )