Most of you may know that I'm working on a new image loading package for FOP. FOP needs to load all sorts of different image (bitmap, EPS, SVG, MathML and others we don't even need to know about). I'm soon finished with it so it can be merged into FOP Trunk (it's currently in a branch at [1]). The image package itself is basically ready. I'm only finishing the integration in FOP.
A month ago, I told Tonny Kohar of Kiyut about the new package, after I've seen their Ekspos Image Viewer [3]. He showed quite some interest and now asked me if I could provide the package as a separate library (i.e. without FOP balast). I've already decoupled the package from FOP as far as possible. Only some nits are left. While working on the integration in the PDFTranscoder (for optimized JPEG embedding using a specialized ImageElementBridge, for example), I noticed that Batik could actually profit from this library, too, i.e. Batik could support additional image formats. When the PDFTranscoder moves to Batik, we would need to move the image library to Commons anyway (or remove the optimized image functionality) as there are dependencies. My proposal now would be: I could move the new image package from org.apache.fop.image2 [2] (in the temporary branch) to Commons. The new package name needs to be discussed as there is already an org.apache.xmlgraphics.image. My proposal: org.apache.xmlgraphics.image.loader (in analogy to the writers) I see various points speaking for this approach: - Clear decoupling from FOP promoting a clean design - Easy reuse by other interested parties (such as Batik, Kiyut) - therefore a bigger chance for additional help from outside our project - Some work for the Transcoder move is already done - Value improvement for Commons Downsides: - Commons JAR grows in size (if Batik doesn't adopt it, more unused code for them in the JAR) Notes: - Some helper classes from FOP will also immediately have to migrate to Commons. But that would happen eventually, when I really have time to move the transcoders. And I will have time next year. That's for sure. :-) Can I get opinions, please (I'm particularly interested what the Batik committers think)? If I need to explain anything in more detail, just ask. ----- Key features of the package: - Image preloading: format detection and reading the intrinsic size of the image without loading the whole image into memory (works for most images). - Unified API for all kinds of images. - Image conversion facility: bitmap->Java2D, Java2D->bitmap, bitmap->PNG, WMF->Java2D, SVG->Java2D - Image consumers can simply tell the package what kind of images it supports and the image library tries to provide the image in the best possible format (possibly using automatic image conversion). - Currently supported: All bitmap formats supported by ImageIO codecs, SVG/WMF through Batik, EPS (only usable for PostScript output without a PostScript interpreter in the back) - Custom image loaders and converters can be dynamically plugged in. - Image cache (using soft references) [1] https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ImagePackageRedesign [2] http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_ImagePackageRedesign/src/java/org/apache/fop/image2/ [3] http://www.kiyut.com/products/ekspos/index.html Jeremias Maerki --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
