xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "The Web Maestro" <the.webmaes...@gmail.com>
Subject Re: FOP's new image package in Commons?
Date Thu, 13 Dec 2007 06:46:14 GMT
On Dec 12, 2007 2:20 AM, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> 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

That sounds pretty good to me. I think XML Graphics is the place is the place.

In fact, I'm wondering if we don't put more emphasis on the Graphics
part of 'Apache XML Graphics Project' in our mission:

  The Apache XML Graphics Project is responsible for software
  licensed to the Apache Software Foundation  intended for the
  creation & maintenance of:

      * the conversion of XML formats to graphical output
      * related software components

As for dependencies, it doesn't surprise or disappoint me much that
Apache FOP and Apache Batik would require Apache XML Graphics Commons
(hence the name Commons). I guess it'd be nice if features and
functionality could somehow be compartmentalized, so projects (FOP,
Batik, as well as external projects) could load only what they need.

On the logging front, isn't it possible to code the Logging
dependencies such that you only load the Logging functionality if it's
needed/called?

-- 
Regards,

The Web Maestro
-- 
<the.webmaestro@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

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