On 12.12.2007 16:45:13 Chris Bowditch wrote: > Jeremias Maerki wrote: > > > Another important point to consider here: > > The image package currently makes extensive use of Apache Commons > > Logging like the rest of FOP. XML Graphics Commons still doesn't use > > Commons Logging. With the migration of the PDF and EPS transcoders to > > Batik a lot more code with references to Commons Logging will be > > affected. Seems to me the right time to talk again about this dependency. > > Would it be so bad if Commons (and, as a consequence, Batik) added this > > new dependency? Is there some room for discussion and reevaluation? > > Good point. I would hate to lose logging from these areas of code in > addition to the bits we've already compromised on. Logging really helps > to debug awkward issues AND is currently used for user feedback > (although that should be changed at some point!) > > <snip/> > > >>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) > > If the image package uses Batik does that mean a dependency on Batik > from commons?
Sorry, I wasn't clear enough. No, I don't plan to move the SVG and WMF plugins. When the transcoders are moved to Batik, these plugins will go with them (or sooner if desired). Until then, they remain in FOP. > >>- Custom image loaders and converters can be dynamically plugged in. > >>- Image cache (using soft references) > > Good work Jeremias. The new image package is very comprehensive and the > idea of using it in other packages is a good one and therefore I would > vote +1 for such a change (pending a positive answer to my question > above :)) > > Thanks, > > Chris > Jeremias Maerki --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
