OK - i will do that! Stefan
> -----Original Message----- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > Sent: Friday, April 30, 2004 2:35 PM > To: [EMAIL PROTECTED] > Subject: Re: [Patch Proposal] Integrate FOP with > Cocoon/Excalibur Source > Resolving > > > Absolutely, thanks! Indeed, if there is *functionality* you > need that > can be programmed natively into FOP--for the use of all, > without needing > to tie us to particular frameworks--fantastic--please just enter this > enhancement request into Bugzilla so it doesn't get lost (you > can just > reference this email in the ML archives). Thank you for > bringing this > to our attention. > > Glen > > > Stefan Seifert schrieb: > > >I understand understand your concerns concering avalon (and > followed myself the thread you noticed in the last weeks). > > > >But it would be great to have any possibility to "plug in" a > own source resolving concept in FOP in any case! This could > be Excalibur or anything else. > > > >Consider something like this (very rough): > > > >public interface FopImageResolver { > > > > URL resolve(String href) throws MalformedURLException; > > > >} > > > >And a extension to FopImageFactory: > > > >public static void setImageResolver(FopImageResolver > resolver) { ... } > >public static FopImageResolver getImageResolver() { ... } > > > >This would allow to "plug in" every image resolving concept > that is needed for 3rdpary application integration including > avalong-based cocoon from now, whatever-based cocoon in the > future and others. > > > >And only some additional lines of code in the Fop sourcebase > - without dependencies to any "non-base" tool. > > > >If you follow some user mailing lists like cocoon and > forrest there are dozens of examples of problems with > embedded images in PDFs, because fop uses internal a complete > different resolving concept than cocoon. This could be solved > very easy, i think. > > > >Stefan > > > > > > > > > >>-----Original Message----- > >>From: Glen Mazza [mailto:[EMAIL PROTECTED] > >>Sent: Friday, April 30, 2004 9:45 AM > >>To: [EMAIL PROTECTED] > >>Subject: Re: [Patch Proposal] Integrate FOP with > >>Cocoon/Excalibur Source > >>Resolving > >> > >> > >>I don't think so. For one, the 0.20.x branch is basically > >>frozen. But > >>more fundamentally, we're moved away from Avalon in 1.0. > Like Xalan, > >>Batik, AntennaHouse and RenderX, we're a base tool--we shouldn't be > >>sitting on frameworks which would then require other users > of FOP to > >>import that framework as well. > >> > >>Cocoon is also moving away from Avalon. I refer you to the > >>"building on > >>stone" thread: > >>http://marc.theaimsgroup.com/?t=108004833700001&r=1&w=2 > >> > >>The problem here appears not to be FOP's "lack of property > Excalibur > >>source resolving support"--of course, gazillions of PDF > >>documents that > >>have been printed without that feature, not just by FOP but by the > >>commercial implementations--but rather, that you're working with a > >>framework that can not interface with a base Java tool, a > >>framework that > >>requires FOP to be rewritten in order to work with it. So it would > >>appear to be better for you to keep wrapping and modifying > >>FOP to suit > >>your needs. It is not like there are that many releases of > >>FOP anyway. > >> > >>Glen > >> > >> > >>Stefan Seifert schrieb: > >> > >> > >> > >>>Recently we integrated for our project Cocoon 2.1.4 with DAY > >>> > >>> > >>Communqiué 3.5.4 (a CMS) and use it together with FOP 0.20.5 > >>for PDF generation. > >> > >> > >>>The problem with the existing FOP integration in cocoon is > >>> > >>> > >>the lack of properly Excalibur source resolving support. > >>Without this (excellent) feature it is not possible to embed > >>images in PDFs from custom source implementations (i.e. a > >>communiqué contentbus source implementation in our case). For > >>some reasons it was not possible for us to use the common > >>workaround and include the images via a HTTP request. > >> > >> > >>>To solve this problem we patched the FOP Sources (Class > >>> > >>> > >>FopImageFactory) and implemented in a simple way a support > >>for Excalibur Source Resolving in Cocoon (extended file > >>attached, added sections are clearly marked with comments). > >> > >> > >>>Because of the existing FOP 0.20.5 implementation we have to > >>> > >>> > >>use some static methods to initialize FOP with the current > >>source resolver from cocoon (this is the only drawback of the > >>solution). The implementation checks first to resolve a image > >>URL with the source resolver, and has a fallback to the > >>default fop implementation if this fails. > >> > >> > >>>To initialize FOP with the current cocoon source resolver it > >>> > >>> > >>is possible to write a simple cocoon action and add it to the > >>pdf generation pipeline (sample attached - 2nd file). > >> > >> > >>>Through not tested in all details yet this solutions works > >>> > >>> > >>very well for us (and should offer a better performance than > >>the workaround with the http requests). > >> > >> > >>>I cross-post this message to fop-dev and cocoon-dev. > >>>To the FOP developers: Any chance to integrate Excalibur > >>> > >>> > >>Source Resolving support in the main FOP codebase? > >> > >> > >>>If this would be the case we could patch the cocoon pdf > >>> > >>> > >>serializer too to hand over the source resolver and get lack > >>of the additional action. > >> > >> > >>>Stefan > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >> > > > > > > > > > > >
