Difference between RenderingContext and RendererContext

[Craig Ringer <cr...@postnewspapers.com.au>]

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 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

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088     Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

Re: Difference between RenderingContext and RendererContext

[Craig Ringer <ri...@ringerc.id.au>]

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" <vh...@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

Re: Difference between RenderingContext and RendererContext

[Vincent Hennebert <vh...@gmail.com>]

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