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

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

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

[Adrian Cumiskey <ad...@gmail.com>]

Jeremias Maerki wrote:
> 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 Apache 
>> 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 group 
>> 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 these 
>> 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.

I accept that I could have raised this as a discussion point before making the change but I didn't 
want to spend much time/energy on this matter.  I can easily move the AFP library from 
org.apache.fop.afp to somewhere else if you prefer.  Suggestions/discussions are welcome.

> 
>> 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 rendering 
>> engine or even XML Graphics are far more likely to make use of this AFP library and may even 
>> 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.

I cannot accept this 'more cluttered' argument.  I have only added one new package under 
org.apache.fop.  This simply isn't scary.  Let me tell you that unfamiliar, complex and 
interdependent 1-2000+ line procedural style God objects [1] with code copy/pasted/tweaked 
everywhere scare the hell out of me, not the introduction of one new package.  If I was a new 
contributer/committer this is what would scare the pants off me - actually let me correct myself, I 
still find this scary :).

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

I wasn't suggesting the library is moved to XG Commons, I just wanted to quickly and easily provide 
flexibility and options for the codebase, making it more accessible for everyone, so 
contributers/new committers don't need to necessarily get involved with the renderers.

Adrian.

[1] http://en.wikipedia.org/wiki/God_object

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

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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 Apache 
> 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 group 
> 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 these 
> 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 rendering 
> engine or even XML Graphics are far more likely to make use of this AFP library and may even 
> 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

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

[Adrian Cumiskey <ad...@gmail.com>]

As you know Jeremias, this AFP library and an AFPRenderer was originally donated to the Apache 
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 group 
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 these 
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.

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 rendering 
engine or even XML Graphics are far more likely to make use of this AFP library and may even 
contribute back :).

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.