On 13.12.2007 01:32:42 Cameron McCormack wrote: > Hi Jeremias. > > Jeremias Maerki: > > 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) > > Would this be a replacement for Batik’s > org.apache.batik.ext.awt.image.spi.* classes? They currently use an SPI > interface to provide access to codecs, which take a stream/URL and > return a org.apache.batik.ext.awt.image.renderable.Filter.
It could be one, yes, although I probably haven't caught all the details, yet. Filter is basically a RenderableImage which is useful for producing bitmap images. With the integration in the PDFTranscoder I was excited to see that those AbstractGraphicsNodes are much more powerful, i.e. it is easy to preserve the vector graphics of non-bitmap images as long as possible. But the images are automatically converted to bitmaps when needed (for filter effects, for example). See also: http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_ImagePackageRedesign/src/java/org/apache/fop/svg/PDFImageElementBridge.java?view=markup That way, you can already embed WMF and other vector graphic image formats using svg:image tags in SVG. Way cool, isnt' it? :-) > I’m all for rationalising the image handling code between Batik and FOP > so that as much commonality as possible can be factored out. > > I haven’t delved into Batik’s image code much, though, so I can’t be > sure what your image package might lack that Batik requires without > taking a fair chunk of time to go through the code (which I don’t have > at the moment). Perhaps Thomas is more familiar with the image code? > > > 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) > > How about PDF->Java2D? That could be neat. Yes, definitely. PDFBox has the beginnings of a PDF viewer, but that effort will take much more work. Jeremias Maerki --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
