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
