Re: [Patch Proposal] Integrate FOP with Cocoon/Excalibur Source Resolving

[Glen Mazza]

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