You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2005/08/24 09:17:29 UTC
[VOTE] Creation of XML Graphics Commons
It took a long time since the initial idea until today, but we finally
have a plan we can proceed with. So I'd like to call a formal vote for
the following plan:
Recent key amendments to the plan:
- Extraction of the dependencies on Avalon Framework and Commons Logging
for the components going into Commons while they are migrated.
- All migrated code goes under one source directory rather than a new
package structure for each component.
=======================================================================
http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
== 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. XML Graphics Commons will deliver a set of well-defined
libraries of which some might provide some supporting tools (such as the
TTFReader and the PFMReader, but which will eventually vanish when they
are not needed anymore). Other potentially reusable software like
utilities for build support, ant tasks, plugins for IDEs, test
frameworks and data files might also qualify for finding a home in XML
Graphics Commons.
=== 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
Folio, i.e. work together on undisputed parts of an XSL-FO processor.
== The plan ==
=== Common repository ===
For the joint operations we need a common repository. Since we now have
migrated both subprojects to Subversion we are in a good starting
position for this.
=== 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)
* RTF library (org.apache.fop.render.rtf.rtflib, based on user feedback, generally usable)
''[1] Some of these classes could be candidates to go into Jakarta Commons IO.''
'''External dependencies:'''
* Avalon Framework (for the configuration subpackage only) [2]
* Jakarta Commons Logging [3]
* Jakarta Commons IO
[2] There's enough opposition here that warrants a reevaluation. We'll
try to do without this.
[3] During the move it should be tried to remove this dependency, i.e.
no logging at all in the basic shared components.
=== 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 (org.apache.batik.util, could be used by FOP, too.
Benefits: RFC2397 data: URLs, automatic gzip decompression (SVGZ))
* image codecs (org.apache.batik.ext.awt.image.codec)
* Base64 encoder and decoder (org.apache.batik.util)
* SVGGraphics2D
* ...
=== Organization and naming ===
==== Naming the individual parts ====
''Apache XML Graphics Commons''
* xmlgraphics-commons-pdf (PDF library)
* xmlgraphics-commons-ps (PostScript generation and manipulation/post-processing code)
* xmlgraphics-commons-fonts (Font library)
* xmlgraphics-commons-codecs (Image codecs)
* xmlgraphics-commons-image-adapter (Image library adapters and analyzers)
* xmlgraphics-commons-utils (IO classes, Exception classes, ParsedURL)
* xmlgraphics-commons-java2d (Graphics2D implementation for PDF and PS, base for the Transcoders)
* xmlgraphics-commons-rtf (RTF library)
==== layout in SVN ====
http://svn.apache.org/repos/asf/xmlgraphics
+-- commons
+-- branches
+-- tags
+-- trunk
+-- src
+-- java (all shared components under this directory)
+-- org.apache.xmlgraphics
+-- codecs
+-- fonts
+-- image-adapters
+-- java2d (Graphics2D implementations, gradient/(pattern) extensions)
+-- pdf (PDF implementation)
+-- ps (PS implementation)
+-- svg (SVG implementation)
+-- pdf
+-- ps
+-- rtf
+-- utils
+-- java-1.4 (all JDK 1.4 dependant code under this directory)
+-- batik
+-- branches
+-- tags
+-- trunk
+-- fop
+-- branches
+-- tags
+-- trunk
+-- site
'''Notes:'''
* In this scenario, the PDF and PS transcoders are transferred to the
Batik subproject under their repository.
* Basic Graphics2D implementations and supporting code
(gradient/(pattern) classes) go into Commons (Batik only gets the
Transcoders)
* this layout has the effect that we have three major products (batik,
fop and xmlgraphics-commons), where axgc may have additional
(sub-)products for each individual components (if necessary).
* axgc builds some components individually (xmlgraphics-commons-pdf.jar,
xmlgraphics-commons-utils.jar etc.), as well as a collective
(xmlgraphics-commons.jar). A release is only done as a collective for
the whole of XML Graphics Commons.
* All releases are always coordinated on the project level (i.e. on
level Apache XML Graphics).
=== Notes on additional use cases for the separated components ===
* PDFDocumentGraphics2D and PSDocumentGraphics2D can be used to create
streamed print services for JPS which would allow arbitrary Java
applications to create PDF and PostScript by simply printing to JPS.
* The PDF library could be used to create PDF documents from scratch
(iText is probably better suited for that).
* The PDF library could be extended to modify existing documents (same
comment as above)
* The PS library code could be extended to support PostScript
post-processing.
* The RTF library is reported to be used separately. There is desire
for a separate JAR with only the RTF generation code.
=======================================================================
For the transition period it is probably best to start with copying (!)
the components over to Commmons, refactor there and then remove the
originals. It doesn't all have to happen in one batch. We can gradually
move components over. But we should see to it that we maintain SVN
history while moving, so the classes can be traced back to their origin.
Please cast your votes!
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
Re: [VOTE] Creation of XML Graphics Commons
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> It took a long time since the initial idea until today, but we finally
> have a plan we can proceed with. So I'd like to call a formal vote for
> the following plan:
<snip what="very thorough plan"/>
> Please cast your votes!
A big thanks to Jeremias for organising all this. You've been very
thorough as usual!
Anyway, heres my +1
Chris
---------------------------------------------------------------------
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
Re: [VOTE] Creation of XML Graphics Commons
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Jeremias Maerki schrieb:
> Please cast your votes!
+1
Christian
---------------------------------------------------------------------
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
Re: [VOTE] Creation of XML Graphics Commons
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Please cast your votes!
+1
J.Pietschmann
---------------------------------------------------------------------
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
[VOTE:RESULTS] Creation of XML Graphics Commons
Posted by Jeremias Maerki <de...@greenmail.ch>.
(cc PMC list for bookkeeping)
7 out of 8 PMC members have voted +1 for the creation of XML Graphics
Commons. One PMC member did not vote. An unanimous vote is required for
the creation of a subproject which is achieved here.
On 24.08.2005 09:17:29 Jeremias Maerki wrote:
> It took a long time since the initial idea until today, but we finally
> have a plan we can proceed with. So I'd like to call a formal vote for
> the following plan:
>
> Recent key amendments to the plan:
> - Extraction of the dependencies on Avalon Framework and Commons Logging
> for the components going into Commons while they are migrated.
> - All migrated code goes under one source directory rather than a new
> package structure for each component.
>
> =======================================================================
> http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
>
> == 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. XML Graphics Commons will deliver a set of well-defined
> libraries of which some might provide some supporting tools (such as the
> TTFReader and the PFMReader, but which will eventually vanish when they
> are not needed anymore). Other potentially reusable software like
> utilities for build support, ant tasks, plugins for IDEs, test
> frameworks and data files might also qualify for finding a home in XML
> Graphics Commons.
>
>
> === 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
> Folio, i.e. work together on undisputed parts of an XSL-FO processor.
>
> == The plan ==
>
> === Common repository ===
>
> For the joint operations we need a common repository. Since we now have
> migrated both subprojects to Subversion we are in a good starting
> position for this.
>
> === 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)
> * RTF library (org.apache.fop.render.rtf.rtflib, based on user feedback, generally usable)
>
> ''[1] Some of these classes could be candidates to go into Jakarta Commons IO.''
>
> '''External dependencies:'''
>
> * Avalon Framework (for the configuration subpackage only) [2]
> * Jakarta Commons Logging [3]
> * Jakarta Commons IO
>
> [2] There's enough opposition here that warrants a reevaluation. We'll
> try to do without this.
>
> [3] During the move it should be tried to remove this dependency, i.e.
> no logging at all in the basic shared components.
>
> === 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 (org.apache.batik.util, could be used by FOP, too.
> Benefits: RFC2397 data: URLs, automatic gzip decompression (SVGZ))
> * image codecs (org.apache.batik.ext.awt.image.codec)
> * Base64 encoder and decoder (org.apache.batik.util)
> * SVGGraphics2D
> * ...
>
> === Organization and naming ===
>
> ==== Naming the individual parts ====
>
> ''Apache XML Graphics Commons''
>
> * xmlgraphics-commons-pdf (PDF library)
> * xmlgraphics-commons-ps (PostScript generation and manipulation/post-processing code)
> * xmlgraphics-commons-fonts (Font library)
> * xmlgraphics-commons-codecs (Image codecs)
> * xmlgraphics-commons-image-adapter (Image library adapters and analyzers)
> * xmlgraphics-commons-utils (IO classes, Exception classes, ParsedURL)
> * xmlgraphics-commons-java2d (Graphics2D implementation for PDF and PS, base for the Transcoders)
> * xmlgraphics-commons-rtf (RTF library)
>
> ==== layout in SVN ====
>
> http://svn.apache.org/repos/asf/xmlgraphics
> +-- commons
> +-- branches
> +-- tags
> +-- trunk
> +-- src
> +-- java (all shared components under this directory)
> +-- org.apache.xmlgraphics
> +-- codecs
> +-- fonts
> +-- image-adapters
> +-- java2d (Graphics2D implementations, gradient/(pattern) extensions)
> +-- pdf (PDF implementation)
> +-- ps (PS implementation)
> +-- svg (SVG implementation)
> +-- pdf
> +-- ps
> +-- rtf
> +-- utils
> +-- java-1.4 (all JDK 1.4 dependant code under this directory)
> +-- batik
> +-- branches
> +-- tags
> +-- trunk
> +-- fop
> +-- branches
> +-- tags
> +-- trunk
> +-- site
>
>
> '''Notes:'''
>
> * In this scenario, the PDF and PS transcoders are transferred to the
> Batik subproject under their repository.
> * Basic Graphics2D implementations and supporting code
> (gradient/(pattern) classes) go into Commons (Batik only gets the
> Transcoders)
> * this layout has the effect that we have three major products (batik,
> fop and xmlgraphics-commons), where axgc may have additional
> (sub-)products for each individual components (if necessary).
> * axgc builds some components individually (xmlgraphics-commons-pdf.jar,
> xmlgraphics-commons-utils.jar etc.), as well as a collective
> (xmlgraphics-commons.jar). A release is only done as a collective for
> the whole of XML Graphics Commons.
> * All releases are always coordinated on the project level (i.e. on
> level Apache XML Graphics).
>
> === Notes on additional use cases for the separated components ===
>
> * PDFDocumentGraphics2D and PSDocumentGraphics2D can be used to create
> streamed print services for JPS which would allow arbitrary Java
> applications to create PDF and PostScript by simply printing to JPS.
> * The PDF library could be used to create PDF documents from scratch
> (iText is probably better suited for that).
> * The PDF library could be extended to modify existing documents (same
> comment as above)
> * The PS library code could be extended to support PostScript
> post-processing.
> * The RTF library is reported to be used separately. There is desire
> for a separate JAR with only the RTF generation code.
>
> =======================================================================
>
> For the transition period it is probably best to start with copying (!)
> the components over to Commmons, refactor there and then remove the
> originals. It doesn't all have to happen in one batch. We can gradually
> move components over. But we should see to it that we maintain SVN
> history while moving, so the classes can be traced back to their origin.
>
> Please cast your votes!
>
> 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
Re: [VOTE] Creation of XML Graphics Commons
Posted by Simon Pepping <sp...@leverkruid.nl>.
+1 from me.
Regards, Simon
On Wed, Aug 24, 2005 at 09:17:29AM +0200, Jeremias Maerki wrote:
> It took a long time since the initial idea until today, but we finally
> have a plan we can proceed with. So I'd like to call a formal vote for
> the following plan:
>
> Recent key amendments to the plan:
> - Extraction of the dependencies on Avalon Framework and Commons Logging
> for the components going into Commons while they are migrated.
> - All migrated code goes under one source directory rather than a new
> package structure for each component.
>
> =======================================================================
> http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
>
> == 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. XML Graphics Commons will deliver a set of well-defined
> libraries of which some might provide some supporting tools (such as the
> TTFReader and the PFMReader, but which will eventually vanish when they
> are not needed anymore). Other potentially reusable software like
> utilities for build support, ant tasks, plugins for IDEs, test
> frameworks and data files might also qualify for finding a home in XML
> Graphics Commons.
>
>
> === 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
> Folio, i.e. work together on undisputed parts of an XSL-FO processor.
>
> == The plan ==
>
> === Common repository ===
>
> For the joint operations we need a common repository. Since we now have
> migrated both subprojects to Subversion we are in a good starting
> position for this.
>
> === 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)
> * RTF library (org.apache.fop.render.rtf.rtflib, based on user feedback, generally usable)
>
> ''[1] Some of these classes could be candidates to go into Jakarta Commons IO.''
>
> '''External dependencies:'''
>
> * Avalon Framework (for the configuration subpackage only) [2]
> * Jakarta Commons Logging [3]
> * Jakarta Commons IO
>
> [2] There's enough opposition here that warrants a reevaluation. We'll
> try to do without this.
>
> [3] During the move it should be tried to remove this dependency, i.e.
> no logging at all in the basic shared components.
>
> === 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 (org.apache.batik.util, could be used by FOP, too.
> Benefits: RFC2397 data: URLs, automatic gzip decompression (SVGZ))
> * image codecs (org.apache.batik.ext.awt.image.codec)
> * Base64 encoder and decoder (org.apache.batik.util)
> * SVGGraphics2D
> * ...
>
> === Organization and naming ===
>
> ==== Naming the individual parts ====
>
> ''Apache XML Graphics Commons''
>
> * xmlgraphics-commons-pdf (PDF library)
> * xmlgraphics-commons-ps (PostScript generation and manipulation/post-processing code)
> * xmlgraphics-commons-fonts (Font library)
> * xmlgraphics-commons-codecs (Image codecs)
> * xmlgraphics-commons-image-adapter (Image library adapters and analyzers)
> * xmlgraphics-commons-utils (IO classes, Exception classes, ParsedURL)
> * xmlgraphics-commons-java2d (Graphics2D implementation for PDF and PS, base for the Transcoders)
> * xmlgraphics-commons-rtf (RTF library)
>
> ==== layout in SVN ====
>
> http://svn.apache.org/repos/asf/xmlgraphics
> +-- commons
> +-- branches
> +-- tags
> +-- trunk
> +-- src
> +-- java (all shared components under this directory)
> +-- org.apache.xmlgraphics
> +-- codecs
> +-- fonts
> +-- image-adapters
> +-- java2d (Graphics2D implementations, gradient/(pattern) extensions)
> +-- pdf (PDF implementation)
> +-- ps (PS implementation)
> +-- svg (SVG implementation)
> +-- pdf
> +-- ps
> +-- rtf
> +-- utils
> +-- java-1.4 (all JDK 1.4 dependant code under this directory)
> +-- batik
> +-- branches
> +-- tags
> +-- trunk
> +-- fop
> +-- branches
> +-- tags
> +-- trunk
> +-- site
>
>
> '''Notes:'''
>
> * In this scenario, the PDF and PS transcoders are transferred to the
> Batik subproject under their repository.
> * Basic Graphics2D implementations and supporting code
> (gradient/(pattern) classes) go into Commons (Batik only gets the
> Transcoders)
> * this layout has the effect that we have three major products (batik,
> fop and xmlgraphics-commons), where axgc may have additional
> (sub-)products for each individual components (if necessary).
> * axgc builds some components individually (xmlgraphics-commons-pdf.jar,
> xmlgraphics-commons-utils.jar etc.), as well as a collective
> (xmlgraphics-commons.jar). A release is only done as a collective for
> the whole of XML Graphics Commons.
> * All releases are always coordinated on the project level (i.e. on
> level Apache XML Graphics).
>
> === Notes on additional use cases for the separated components ===
>
> * PDFDocumentGraphics2D and PSDocumentGraphics2D can be used to create
> streamed print services for JPS which would allow arbitrary Java
> applications to create PDF and PostScript by simply printing to JPS.
> * The PDF library could be used to create PDF documents from scratch
> (iText is probably better suited for that).
> * The PDF library could be extended to modify existing documents (same
> comment as above)
> * The PS library code could be extended to support PostScript
> post-processing.
> * The RTF library is reported to be used separately. There is desire
> for a separate JAR with only the RTF generation code.
>
> =======================================================================
>
> For the transition period it is probably best to start with copying (!)
> the components over to Commmons, refactor there and then remove the
> originals. It doesn't all have to happen in one batch. We can gradually
> move components over. But we should see to it that we maintain SVN
> history while moving, so the classes can be traced back to their origin.
>
> Please cast your votes!
>
> 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
>
--
Simon Pepping
home page: http://www.leverkruid.nl
---------------------------------------------------------------------
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
Re: [VOTE] Creation of XML Graphics Commons
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jeremias Maerki wrote:
> Recent key amendments to the plan:
> - Extraction of the dependencies on Avalon Framework and Commons Logging
> for the components going into Commons while they are migrated.
> - All migrated code goes under one source directory rather than a new
> package structure for each component.
>
> =======================================================================
> http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
+1
---
Thomas DeWeese
>
> == 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. XML Graphics Commons will deliver a set of well-defined
> libraries of which some might provide some supporting tools (such as the
> TTFReader and the PFMReader, but which will eventually vanish when they
> are not needed anymore). Other potentially reusable software like
> utilities for build support, ant tasks, plugins for IDEs, test
> frameworks and data files might also qualify for finding a home in XML
> Graphics Commons.
>
>
> === 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
> Folio, i.e. work together on undisputed parts of an XSL-FO processor.
>
> == The plan ==
>
> === Common repository ===
>
> For the joint operations we need a common repository. Since we now have
> migrated both subprojects to Subversion we are in a good starting
> position for this.
>
> === 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)
> * RTF library (org.apache.fop.render.rtf.rtflib, based on user feedback, generally usable)
>
> ''[1] Some of these classes could be candidates to go into Jakarta Commons IO.''
>
> '''External dependencies:'''
>
> * Avalon Framework (for the configuration subpackage only) [2]
> * Jakarta Commons Logging [3]
> * Jakarta Commons IO
>
> [2] There's enough opposition here that warrants a reevaluation. We'll
> try to do without this.
>
> [3] During the move it should be tried to remove this dependency, i.e.
> no logging at all in the basic shared components.
>
> === 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 (org.apache.batik.util, could be used by FOP, too.
> Benefits: RFC2397 data: URLs, automatic gzip decompression (SVGZ))
> * image codecs (org.apache.batik.ext.awt.image.codec)
> * Base64 encoder and decoder (org.apache.batik.util)
> * SVGGraphics2D
> * ...
>
> === Organization and naming ===
>
> ==== Naming the individual parts ====
>
> ''Apache XML Graphics Commons''
>
> * xmlgraphics-commons-pdf (PDF library)
> * xmlgraphics-commons-ps (PostScript generation and manipulation/post-processing code)
> * xmlgraphics-commons-fonts (Font library)
> * xmlgraphics-commons-codecs (Image codecs)
> * xmlgraphics-commons-image-adapter (Image library adapters and analyzers)
> * xmlgraphics-commons-utils (IO classes, Exception classes, ParsedURL)
> * xmlgraphics-commons-java2d (Graphics2D implementation for PDF and PS, base for the Transcoders)
> * xmlgraphics-commons-rtf (RTF library)
>
> ==== layout in SVN ====
>
> http://svn.apache.org/repos/asf/xmlgraphics
> +-- commons
> +-- branches
> +-- tags
> +-- trunk
> +-- src
> +-- java (all shared components under this directory)
> +-- org.apache.xmlgraphics
> +-- codecs
> +-- fonts
> +-- image-adapters
> +-- java2d (Graphics2D implementations, gradient/(pattern) extensions)
> +-- pdf (PDF implementation)
> +-- ps (PS implementation)
> +-- svg (SVG implementation)
> +-- pdf
> +-- ps
> +-- rtf
> +-- utils
> +-- java-1.4 (all JDK 1.4 dependant code under this directory)
> +-- batik
> +-- branches
> +-- tags
> +-- trunk
> +-- fop
> +-- branches
> +-- tags
> +-- trunk
> +-- site
>
>
> '''Notes:'''
>
> * In this scenario, the PDF and PS transcoders are transferred to the
> Batik subproject under their repository.
> * Basic Graphics2D implementations and supporting code
> (gradient/(pattern) classes) go into Commons (Batik only gets the
> Transcoders)
> * this layout has the effect that we have three major products (batik,
> fop and xmlgraphics-commons), where axgc may have additional
> (sub-)products for each individual components (if necessary).
> * axgc builds some components individually (xmlgraphics-commons-pdf.jar,
> xmlgraphics-commons-utils.jar etc.), as well as a collective
> (xmlgraphics-commons.jar). A release is only done as a collective for
> the whole of XML Graphics Commons.
> * All releases are always coordinated on the project level (i.e. on
> level Apache XML Graphics).
>
> === Notes on additional use cases for the separated components ===
>
> * PDFDocumentGraphics2D and PSDocumentGraphics2D can be used to create
> streamed print services for JPS which would allow arbitrary Java
> applications to create PDF and PostScript by simply printing to JPS.
> * The PDF library could be used to create PDF documents from scratch
> (iText is probably better suited for that).
> * The PDF library could be extended to modify existing documents (same
> comment as above)
> * The PS library code could be extended to support PostScript
> post-processing.
> * The RTF library is reported to be used separately. There is desire
> for a separate JAR with only the RTF generation code.
>
> =======================================================================
>
> For the transition period it is probably best to start with copying (!)
> the components over to Commmons, refactor there and then remove the
> originals. It doesn't all have to happen in one batch. We can gradually
> move components over. But we should see to it that we maintain SVN
> history while moving, so the classes can be traced back to their origin.
>
> Please cast your votes!
>
> 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
>
---------------------------------------------------------------------
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
Re: [VOTE] Creation of XML Graphics Commons
Posted by Jeremias Maerki <de...@greenmail.ch>.
My +1, obviously.
On 24.08.2005 09:17:29 Jeremias Maerki wrote:
> It took a long time since the initial idea until today, but we finally
> have a plan we can proceed with. So I'd like to call a formal vote for
> the following plan:
>
> Recent key amendments to the plan:
> - Extraction of the dependencies on Avalon Framework and Commons Logging
> for the components going into Commons while they are migrated.
> - All migrated code goes under one source directory rather than a new
> package structure for each component.
>
> =======================================================================
> http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
>
> == 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. XML Graphics Commons will deliver a set of well-defined
> libraries of which some might provide some supporting tools (such as the
> TTFReader and the PFMReader, but which will eventually vanish when they
> are not needed anymore). Other potentially reusable software like
> utilities for build support, ant tasks, plugins for IDEs, test
> frameworks and data files might also qualify for finding a home in XML
> Graphics Commons.
>
>
> === 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
> Folio, i.e. work together on undisputed parts of an XSL-FO processor.
>
> == The plan ==
>
> === Common repository ===
>
> For the joint operations we need a common repository. Since we now have
> migrated both subprojects to Subversion we are in a good starting
> position for this.
>
> === 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)
> * RTF library (org.apache.fop.render.rtf.rtflib, based on user feedback, generally usable)
>
> ''[1] Some of these classes could be candidates to go into Jakarta Commons IO.''
>
> '''External dependencies:'''
>
> * Avalon Framework (for the configuration subpackage only) [2]
> * Jakarta Commons Logging [3]
> * Jakarta Commons IO
>
> [2] There's enough opposition here that warrants a reevaluation. We'll
> try to do without this.
>
> [3] During the move it should be tried to remove this dependency, i.e.
> no logging at all in the basic shared components.
>
> === 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 (org.apache.batik.util, could be used by FOP, too.
> Benefits: RFC2397 data: URLs, automatic gzip decompression (SVGZ))
> * image codecs (org.apache.batik.ext.awt.image.codec)
> * Base64 encoder and decoder (org.apache.batik.util)
> * SVGGraphics2D
> * ...
>
> === Organization and naming ===
>
> ==== Naming the individual parts ====
>
> ''Apache XML Graphics Commons''
>
> * xmlgraphics-commons-pdf (PDF library)
> * xmlgraphics-commons-ps (PostScript generation and manipulation/post-processing code)
> * xmlgraphics-commons-fonts (Font library)
> * xmlgraphics-commons-codecs (Image codecs)
> * xmlgraphics-commons-image-adapter (Image library adapters and analyzers)
> * xmlgraphics-commons-utils (IO classes, Exception classes, ParsedURL)
> * xmlgraphics-commons-java2d (Graphics2D implementation for PDF and PS, base for the Transcoders)
> * xmlgraphics-commons-rtf (RTF library)
>
> ==== layout in SVN ====
>
> http://svn.apache.org/repos/asf/xmlgraphics
> +-- commons
> +-- branches
> +-- tags
> +-- trunk
> +-- src
> +-- java (all shared components under this directory)
> +-- org.apache.xmlgraphics
> +-- codecs
> +-- fonts
> +-- image-adapters
> +-- java2d (Graphics2D implementations, gradient/(pattern) extensions)
> +-- pdf (PDF implementation)
> +-- ps (PS implementation)
> +-- svg (SVG implementation)
> +-- pdf
> +-- ps
> +-- rtf
> +-- utils
> +-- java-1.4 (all JDK 1.4 dependant code under this directory)
> +-- batik
> +-- branches
> +-- tags
> +-- trunk
> +-- fop
> +-- branches
> +-- tags
> +-- trunk
> +-- site
>
>
> '''Notes:'''
>
> * In this scenario, the PDF and PS transcoders are transferred to the
> Batik subproject under their repository.
> * Basic Graphics2D implementations and supporting code
> (gradient/(pattern) classes) go into Commons (Batik only gets the
> Transcoders)
> * this layout has the effect that we have three major products (batik,
> fop and xmlgraphics-commons), where axgc may have additional
> (sub-)products for each individual components (if necessary).
> * axgc builds some components individually (xmlgraphics-commons-pdf.jar,
> xmlgraphics-commons-utils.jar etc.), as well as a collective
> (xmlgraphics-commons.jar). A release is only done as a collective for
> the whole of XML Graphics Commons.
> * All releases are always coordinated on the project level (i.e. on
> level Apache XML Graphics).
>
> === Notes on additional use cases for the separated components ===
>
> * PDFDocumentGraphics2D and PSDocumentGraphics2D can be used to create
> streamed print services for JPS which would allow arbitrary Java
> applications to create PDF and PostScript by simply printing to JPS.
> * The PDF library could be used to create PDF documents from scratch
> (iText is probably better suited for that).
> * The PDF library could be extended to modify existing documents (same
> comment as above)
> * The PS library code could be extended to support PostScript
> post-processing.
> * The RTF library is reported to be used separately. There is desire
> for a separate JAR with only the RTF generation code.
>
> =======================================================================
>
> For the transition period it is probably best to start with copying (!)
> the components over to Commmons, refactor there and then remove the
> originals. It doesn't all have to happen in one batch. We can gradually
> move components over. But we should see to it that we maintain SVN
> history while moving, so the classes can be traced back to their origin.
>
> Please cast your votes!
>
> 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
Re: [VOTE] Creation of XML Graphics Commons
Posted by The Web Maestro <th...@gmail.com>.
On Aug 24, 2005, at 12:17 AM, Jeremias Maerki wrote:
> It took a long time since the initial idea until today, but we finally
> have a plan we can proceed with. So I'd like to call a formal vote for
> the following plan:
>
> Recent key amendments to the plan:
> - Extraction of the dependencies on Avalon Framework and Commons
> Logging
> for the components going into Commons while they are migrated.
> - All migrated code goes under one source directory rather than a new
> package structure for each component.
>
> =======================================================================
> http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
Looks good to me.
+1
Regards,
Web Maestro Clay
--
<th...@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