It is certainly true that javax.imageio is the direction to go in the future.
However, It is probably worth pointing out that you already include a PNG encoder/decoder with the FOP distribution, from Batik!
org.apache.batik.ext.awt.image.codec.PNGImageEncoder
org.apache.batik.ext.awt.image.codec.PNGImageDecoder
Let me know if you want/need more info (including pointers to where FOP does the image loading would be helpful as well).
Jeremias Maerki <[EMAIL PROTECTED]>
No apologies required!
Image IO (javax.imageio) support is not there, yet, I'm afraid. But if you created an implementation for Image IO then your idea would work. Shouldn't be very hard. Check the org.apache.fop.image package. You wouldn't need to use JIMI. Think of JIMI, JAI and ImageIO as equals. They all provide an API to access bitmap images.
On 23.01.2004 16:08:55 Dalibor Topic wrote:> A possible work-around is to establish a better plug-in concept for our > image lib adapters in HEAD (not 0.20.5) so interested parties can create > plug-ins outside of the ASF to use LGPL libraries.
I'm not very well aware of the differences between all the different image io APIs, so please excuse me if my next question is a typical newbie question. If, for example, we had javax.imageio support working for PNG images in GNU Classpath (and Kaffe), would/could FOP automatically use that, or would it still need to use JIMI?
The reasoning behind this being that PNG image support seems to be part of JDK 1.4 anyway, so it will be implemented in free runtimes eventually as well.
