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 Wed, 12 Dec 2007 10:56:26 GMT
Thanks for your feedback!

Passing additional information to an image converter (like font info) is
not a problem. This is already available in the package by passing a Map
of key/value pairs through the image pipeline. But carrying the font
information from the FO stage all the way to the renderer where the
MathML docs are finally processed is a different topic and does not
touch the image package.

On 12.12.2007 11:41:27 Max Berger wrote:
> 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
> > 


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