xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: svn commit: r708134 [1/6] - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources: ./ src/java/org/apache/fop/ src/java/org/apache/fop/afp/ src/java/org/apache/fop/afp/fonts/ src/java/org/apache/fop/afp/goca/ src/java/org/apache/fop/afp/ioca/ src/java/org...
Date Tue, 28 Oct 2008 17:24:33 GMT
On 28.10.2008 18:55:39 Adrian Cumiskey wrote:
> As you know Jeremias, this AFP library and an AFPRenderer was originally donated to the
> Foundation in 2006 [1].  It was donated as a prototype AFP library and renderer all mixed
up together.
>  From the work I have done in the Temp_AFPGOCAResources branch, the original AFP code
is no longer 
> just a library and renderer but is a much more complete production quality implementation.
 We now 
> have complex data object creation, native image embedding using object containers, resource
> streaming (external), resource leveling and an AFPGraphics2D implementation providing
GOCA support. 
>   Its offering is now much more substantial and mature and it made sense as I implemented
> things that that the AFP library component should become independent and have no knowledge
of FOP's 
> AFP rendering component.  Having this separation in mind made it conceptually easier
for me.

I assumed as much but that wasn't the reason for my post. It was the
lack of discussion before the change.

> As you mentioned with the PDF library, maybe there might similarly be a desire for access
to the AFP 
> library in XG Commons or elsewhere in the future, this would now be quite straight forward
if there 
> was a desire for it.  Similarly, other projects which may have no interest in the FOP
> engine or even XML Graphics are far more likely to make use of this AFP library and may
> contribute back :).

Fair enough. The same applies to the RTF library of course, which
actually even has examples of how to create a stand-alone document.

I'm all for improving visibility (if there are actually potential
stand-alone users) but not at the price of making the org.apache.fop
package structure more cluttered and therefore scary to new committers.
Moving everything to Commons is probably no solution either, as Batik is
not interested in either RTF or AFP. It would only blow up the Commons
JAR (which can be an issue for some people). Anyway, things like that
require consensus before a move.

> Of course I'd be interested to hear the thoughts of other committers.
> [1] http://incubator.apache.org/ip-clearance/xmlgraphics-fop-afp-renderer.html
> Jeremias Maerki wrote:
> > Back in 2003, the RTF library was moved from org.apache.fop.rtf under
> > org.apache.fop.render.rtf [1], and now the AFP library is moved in
> > exactly the opposite direction. Yes, there's the PDF library under
> > org.apache.fop.pdf. But it's destined to move out to XG Commons because
> > Batik needs a cleaner access path to it (I know, I know, that one's
> > still on my task list). I'm not vetoing this change but I would think
> > things like that warrant checking back with the rest of the committers
> > to see what they think before doing something like that. I believe we
> > would want to follow a certain strategy on such things. FWIW, I
> > currently don't see a necessity or benefit for this change at the moment.
> > 
> > [1] https://svn.apache.org/viewvc?limit_changes=0&view=rev&revision=196981
> > 
> > On 27.10.2008 13:11:38 acumiskey wrote:
> >> Author: acumiskey
> >> Date: Mon Oct 27 04:11:31 2008
> >> New Revision: 708134
> >>
> >> URL: http://svn.apache.org/viewvc?rev=708134&view=rev
> >> Log:
> >> All AFP library classes without Renderer dependencies moved from org.apache.fop.renderer.afp.*
to org.apache.fop.afp.*.
> >> AbstractNamedAFPObject now truncates names to the last x characters of the name
string instead of the first x (where x is the name length of the structured field).
> >> Removed redundant package org.apache.fop.store.
> > <snip/> 
> > 
> > 
> > Jeremias Maerki
> > 
> > 
> Adrian.

Jeremias Maerki

View raw message