xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: FOP's new image package in Commons?
Date Thu, 13 Dec 2007 06:49:12 GMT
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: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message