I think a separate sub-project for AFP rendering is a great idea. We could use this endeavour as an opportunity to perhaps think about how we canmake FOP more modular: currently too many classes that 'claim' to be output neutral refer to specific renderers or other extension processes. If FOP could be made a bit more pluggable in certain areas I believe the code base would be far more readable and maintainable. It would not be an easy task but any steps in this direction would have advantages even if clean separations cannot be made.
Pete On Fri, Sep 10, 2010 at 1:34 PM, Simon Pepping <[email protected]> wrote: > For completeness, I note that I have no opinion on this topic. > > I am though a bit reluctant to define a new ideal restructuring > goal. Is this one of our high priorities? Of course, it depends on the > size of the work, and if someone sees this as his ideal work for the > coming time, he is welcome to do it. > > Simon > > On Fri, Sep 10, 2010 at 01:45:10PM +0200, Jeremias Maerki wrote: >> Re-reading you earlier comment (2010-08-25), I realize I misunderstood >> you back then. I thought you suggested XGC as target for the AFP parser >> when you actually proposed an additional subproject. So I'll move the >> AFP parser back to FOP for the moment. It doesn't really make much sense >> in XGC right now. >> >> That said, I believe RTF is used more intensively than you think. It's >> just that not much effort goes into further improving it, lately. >> >> Splitting up FOP into multiple JARs is basically OK with me, although I >> prefer having separate source trees to make the dependencies better >> thought through. I've had to fix a number of not so good dependencies >> between packages in the past. Batik has a single source tree and I think >> it's a difficult situation to keep dependencies clear although it's >> easier to set up in the IDE, of course. >> >> On 10.09.2010 12:19:20 Vincent Hennebert wrote: >> > Ideally every output format should be optional and shipped in its own >> > jar. I???m not sure the RTF library currently included in FOP is any more >> > used than the AFP output. That doesn???t prevent us, anyway, from >> > delivering some fop-all.jar that would contain all the common output >> > formats. >> > >> > In the case of AFP there now is this AFP parser that has nothing to do >> > with FOP???s or XGC???s primary functions. So I think a dedicated >> > sub-project is most definitely appropriate. >> > >> > +1 for creating a sub-project. >> > >> > Vincent >> > >> > >> > On 09/09/10 15:08, Julien Aymé wrote: >> > > Hi, >> > > >> > > As Eric already said, the new format should be split into a separate jar, >> > > but there is no need to create a new subproject. >> > > A dedicated ant task to create the new jar should suffice. >> > > >> > > Julien >> > > >> > > >> > > 2010/9/9 Eric Douglas <[email protected]>: >> > >> Not only have I never used AFP I don't believe I've heard of it. I had >> > >> to look it up, which found multiple definitions. Is this the one you're >> > >> referring to? >> > >> http://en.wikipedia.org/wiki/IBM_Advanced_Function_Printing_(AFP) >> > >> >> > >> I think any output format which adds considerable overhead should be >> > >> split into a separate jar if at all possible, to minimize the amount of >> > >> code to load for anyone not using that format. >> > >> >> > >> >> > >> -----Original Message----- >> > >> From: Jeremias Maerki [mailto:[email protected]] >> > >> Sent: Thursday, September 09, 2010 9:52 AM >> > >> To: [email protected] >> > >> Subject: Brainstorming: AFP subproject? >> > >> >> > >> I've just committed a basic AFP parser to XGC as discussed on fop-dev >> > >> some time ago. While doing that I've started to think that AFP is really >> > >> something not many people know about or need. I wonder if it would make >> > >> sense to actually create an XML Graphics subproject dedicated to AFP. It >> > >> would include the AFP generation library from FOP and the AFP parser >> > >> I've started, maybe even the FOP output plug-in. A dream of mine is to >> > >> have an actual AFP viewer/converter at some point. >> > >> >> > >> The rationale behind it is that the AFP library alone increases the FOP >> > >> JAR size considerably and only relatively few people actually need AFP >> > >> support. >> > >> >> > >> WDYT? > > -- > Simon Pepping > home page: http://www.leverkruid.eu > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
