xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Berger <...@berger.name>
Subject Re: FOP's new image package in Commons?
Date Wed, 12 Dec 2007 10:41:27 GMT
Jeremias,

IMO XMLGraphics is definitely the place to be. I would very much like to
see the API here, as it should be generic - in this case the
jeuclid-fop-plugin would become a jeuclid-xmlgraphics-plugin (which
would allow us to mix svg / mathml, an interesting thought).

However, this would make some tasks more difficult - for example
inheriting the font style / size from the environment (still a tbd for
the jeuclid plugin), which is something that would have to be
generalized enough.

If the size is an issue: Maybe the xmlgraphics commons can be split up
into multiple jars? this could be done depending on the actual use, e.g.
what batik actually uses and what fop uses.

my c2 cts

Max


On Mit, 2007-12-12 at 11:20 +0100, Jeremias Maerki wrote:
> 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: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
> 

Mime
View raw message