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

Reply via email to