Hi Tom, Andreas, > Well, it is only available in the SVN repo, so in the sense that it is not > officially released yet, it is indeed in development. That said, some users > consider trunk to be stable enough to use in production environments.
As far as I understood, out-of-the-ant-file Fop still uses AT, not IF, as default rendering path. But that reminds me, I wanted to find out how to activate IF and see, what happens to my publications. > The benefits of the new IF are mainly: <...> it is better documented than the > Area Tree. Well, that ain't hard. :-) Regards, Georg Datterl ------ Kontakt ------ Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de -----Ursprüngliche Nachricht----- Von: Andreas Delmelle [mailto:[email protected]] Gesendet: Dienstag, 14. Juli 2009 17:17 An: [email protected] Betreff: Re: AW: AW: AW: AW: Area Tree Handling On 14 Jul 2009, at 16:43, TomWilcox wrote: Hi Tom, Georg, > I look forward to getting into the IF however I was under the > impression it is still very much in the development phase.. Well, it is only available in the SVN repo, so in the sense that it is not officially released yet, it is indeed in development. That said, some users consider trunk to be stable enough to use in production environments. The benefits of the new IF are mainly: optimized parsing (faster) and it is better documented than the Area Tree. The Area Tree XML will probably remain alive for some time. In some use-cases, the new IF could lack some of the more detailed structure information that is preserved in the Area Tree. It's really up to you, but we encourage to use the newer IF, since that is ultimately one sure way of getting feedback based on real-life scenarios. All we know for a fact is that our test-suite does not fail, but that is no guarantee whatsoever that everything is A-OK. >> However, I would like to propose a potentially useful future feature >> of FOP would be the ability to do this using Java objects with a view >> for optimising modifications of document fragments such as a subtree >> of the AT through an API (as I think either yourself or Andreas >> mentioned earlier). IIC, the reason we opted for XML formats in the first place, is that one does not really need a specialized API to perform such manipulations. Why double the effort if XSLT already provides you with basically everything you need? All you'd need to do is write some stylesheet code to modify/ manipulate either the Area Tree XML or the IF, and use the standard JAXP pattern to apply the stylesheet to the intermediate XML. That is basically the same pattern that you already use to feed the input to FOP... >> Any ideas where I post suggestions for FOP features? A Bugzilla entry would be a start, but do mind the above reservations. I would be reluctant to introduce such a feature (and thus increase our maintenance overhead), for something that is fairly straightforward to achieve using standard JAXP and XSLT (requiring no changes to the FOP codebase, and still offering all the flexibility that one could desire, IMO) Regards Andreas Andreas Delmelle e-mail: andreas.delmelle.AT.telenet.be Skype: adlm0608 Jabber: [email protected] --------------------------------------------------------------------- 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]
