Thanks Vincent, much appreciated. It turns out I can't use the render context for what I'd hoped to anyway. I'm having to use a weakhashmap keyed on the FOUserAgent to associate image-handler private data with a rendering run.
I'm putting together a proposal and patch to add interceptors around IFDocumentHandler calls, with a service loader based mechanism for fop image handlers, document extensions etc to register handlers. This will - if accepted - let plugins and exts do extra work at various document production phases and provide a cleaner way for plugins and exts to keep per-render data. It will also provide an easy way to support checking for cancellation of rendering runs fairly frequently. The main problem is that I don't see how I can do it without repeating a line of interceptor call code at the start and end of every IFDocumentHandler method implementation, breaking source compatibility for external subclasses of AbstractIFDocumentHandler, or using a tool like JavaAssist. I'm inclined to break source compare for AbstractIFDocumentHandler subclasses and just not propose inclusion in 1.0.x stable but I'd like your view on this. Note that I can't use the user-oriented event system - it doesn't give any access to renderer/handler state and probably shouldn't, plus it doesn't offer low level enough events and again probably shouldn't. If it were targeted at fop 1.1.x only would I possibly be able to use Java 5 in a patch? It'd make this one much cleaner, particularly being able to use enums . On Dec 20, 2011 11:34 PM, "Vincent Hennebert" <vhenneb...@gmail.com> wrote: > > Hi Craig, > > On 16/12/11 13:29, Craig Ringer wrote: > > Hi all > > > > While reading over the pdf-image extension and fop code, I'm having a bit of > > an interesting time figuring out the difference between a few things and was > > hoping for a very brief pointer. > > > > I'm not quite sure what differentiates org.apache.fop.render.RendererContext > > from org.apache.fop.render.RendererContext . The JavaDoc comments don't really > > differentiate them and they look quite similar. > > This is hard to tell. I could trace RendererContext as far back as 2003, > while RenderingContext was added in 2009 with the new XML Intermediate > Format. I don’t know why RenderContext was not deleted or retrofitted > back then. > > Given that RenderingContext is more recent, is an interface and has many > more implementations than RenderContext has sub-classes (actually only > one in the AFP code), I’d say it’s a safe bet to go with > RenderingContext. > > > > This isn't helped by the fact that the pdf-image extension provides two image > > handlers - one implements PDFImageHandler and takes a RendererContext, while > > the other implements ImageHandler and takes a RenderingContext. They seem to > > do much the same thing. > > > > Is this a case of old-backwards-compat-code meets new-code? If so, which > > should I target for future work? > > > > *headscratch* > > > > -- > > Craig Ringer > > HTH, > Vincent