xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: FOP's new image package in Commons?
Date Tue, 18 Dec 2007 01:21:38 GMT
Hi Cameron, Jeremias,

    This is written pretty quickly just to get potential ideas comments 
out.
The Image package sounds nice in general.

> Jeremias Maerki:

> > 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)

Cameron McCormack <cam@mcc.id.au> wrote on 12/12/2007 07:32:42 PM:

> 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.

> I?m all for rationalising the image handling code between Batik and FOP
> so that as much commonality as possible can be factored out.

   Right this would be good.  However there are bits that are needed
for spec conformance.  In particular for PNG we need to be able to
override gamma correction for PNG images in order to apply ICC
Color profiles.

> > 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).

   This is nice.

> > - 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).

   Are we talking about in memory formats (RGB, 8bit, 16bit, Grey, etc.)
or disk formats?

   Is it 'push' oriented?  I ask because of the mention of Image consumer.
This can make filtering complex (basically you would have to cache the
entire image in memory).

> > - 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)

   Does the interface support tiling?

> > - Custom image loaders and converters can be dynamically plugged in.
> > - Image cache (using soft references)

   This is a needed feature however it often needs to be overridden
to fetch an image that has been rewritten/updated "in place".  So the
ability to flush the cache on an individual and/or group basis is 
important.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message