xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject FOP's new image package in Commons?
Date Wed, 12 Dec 2007 10:20:12 GMT
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