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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
