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