xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cumiskey <adrian.cumis...@gmail.com>
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 Wed, 29 Oct 2008 10:28:52 GMT
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
>> 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
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
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.


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

View raw message