On 14/09/2010, at 10:01 PM, Q wrote:
Unless FOP supports some kind of resource resolution delegate
Thanks for the idea. It turns out that FOP does indeed support custom URI resolvers. I created a subclass of FOURIResolver which just overrides resolve(String, String), and returns a StreamSource by calling WOResourceManager.inputStreamForResourceNamed():
public class WOURIResolver extends FOURIResolver {
@Override
public Source resolve(java.lang.String href, java.lang.String base) throws javax.xml.transform.TransformerException {
return new StreamSource(WOApplication.application().resourceManager().inputStreamForResourceNamed(href, null, null));
}
}
(Obviously this is an incomplete proof of concept. That method would certainly need to call super.resolve() at some point if the WOResourceManager can't find the resource, as it's effectively swallowing up all _other_ URI references. I just happen to have none in this particular situation.)
Passing one of these to TransformerFactory.setURIResolver() sorts out the xsl:import issue, and to FopFactory.setURIResolver() sorts out the fo:external-graphic problem.
Have a look at the source for ERPDFGeneration in wonder for how this problem is currently handled. If you aren't tied to using FOP you may wish to try using it instead.
As an aside, I'm only tied to FOP to the extent that I have an existing XSLFO solution for simple invoice generation that I currently use with RenderX's XEP. The cost of embedding XEP for this particular application is prohibitive. FOP seemed like an interesting alternative if I could get it to work. I haven't looked at it since about version 0.2, and it seems to be doing well enough to render the very simple documents I'm throwing at it here. And the price is right.