You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

XML Graphics common components

The problem

The FOP codebase contains two Batik transcoders for PDF and PostScript which can be used independently of FOP and are distributed with Batik. The Batik team should be empowered to help maintain these transcoders, for example, after changes in Batik itself. Since Batik and FOP are both implementing an XML standard that creates graphical output there is some overlap between the two efforts. Last but not least, a Batik release didn't involve a FOP release until now which is something that must change.

The idea

The idea now is to create a common area where the parts of common interest between the two subprojects are jointly developed and maintained.

Benefits

  • Clear dependencies
  • More structured codebase
  • Easier for newbies to contribute to certain parts (They are afraid now of the big blob of code)
  • New (and now easily visible) use cases for certain components (examples: JPS services to allow Java applications to print to PDF and PS through Printables, PDF lib can be used independetly of FOP, etc.)
  • Faciliating collaboration with "competing" projects like FOray and Defoe, i.e. work together on undisputed parts of an XSL-FO processor.

The plan

(Subject of discussion. Input welcome.)

Common repository

For the joint operations we need a common repository. Since we are supposed to move to Subversion sooner or later we may just as well go for Subversion for the common repository, especially now that we've already got an SVN repo for the XML Graphics site.

TBD:

  • Everybody comfortable with going for SVN for this?
  • We could consider moving both Batik and FOP to SVN rather sooner than later which would have the added benefit of preserving history on any file moves (all files would be in the same repository, only in different directories).

Parts affected in FOP

directly:

  • PDF transcoder (org.apache.fop.svg)
  • PostScript transcoder (org.apache.fop.render.ps)

Dependencies:

  • PDF library (org.apache.fop.pdf, by PDF transcoder)
  • PS generation code (org.apache.fop.ps, by PS transcoder)
  • font support (org.apache.fop.fonts, by PDF lib, PDF and PS transcoders)

  • IO helpers (org.apache.fop.util, by PDF and PS transcoders) [1]

  • Image adapters (org.apache.fop.image, by PDF and PS transcoders)
  • Basic FOP exceptions (org.apache.fop.apps)

[1] Some of these classes could be candidates to go into Jakarta Commons IO.

External dependencies:

  • Avalon Framework
  • Jakarta Commons Logging
  • Jakarta Commons IO

Parts affected in Batik

The transcoders depend on several packages inside Batik. Obviously, we can't create a clean hierarchy without dependencies on Batik, at least for the PDF and PS transcoders. But we should do that for the parts where this is possible (PDF lib, fonts, images etc.).

Possible components coming from Batik:

  • ParsedURL (could be used by FOP, too. Benefits: RFC2397 data: URLs, automatic gzip decompression (SVGZ))
  • image codecs
  • ...

work items

  • Complete and discuss this plan and vote on it.
  • (Optional/Idea) Move Batik and FOP to Subversion.
  • Clean up dependencies.
  • Create basic exception classes so the dependency on org.apache.fop.apps disappears.
  • Create common repository.
  • Move affected parts (see above) over to their new location.
  • Create build system for all components. (TBD: one for all or one for each?)
  • Documentation for the new parts.
  • No labels