--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:

> Does any package other than the renderers really
> *need* access to the
> renderInlineXXX methods? 

No, they're now protected--furthermore, whether or not
such renderInlineXXX methods even exist within a
Renderer is now up to the renderer (the change allowed
me to remove these methods from the Renderer
interface.)

Just FYI, we have two types of renderers--Structure
Renderers (MIF, RTF) and formatting renderers (those
needing an Area Tree--PDF, PS, PCL, etc.)  For the
formatting renderers, they all descend from
AbstractRenderer and therefore follow its general
design.

But the nice thing about our system is that they don't
have to follow AbstractRenderer.  AR implements an
interface called Renderer, which is the bare minimum
of methods needed to implement a FOP-compatible
renderer.  Since InlineAreas never call
renderInlineXXX anymore, I pulled it out of the
Renderer interface.  Now, a renderer can create  
methods of its choosing for implementing inline area
rendering--so a Renderer implementor now has more
design options.


It seems to depend on
> whether one wants to be able
> to have:
> 
> a) an InlineArea that 'knows how to render itself'
> or

No, the wrong direction.  A renderer knows how to
render an InlineArea.  The InlineArea would need to
know too much of the innards of the Renderers--as well
as its present state of that renderer's
processing--for that to happen.

> b) an InlineArea that 'knows how to provide data
> about itself to the
> renderer when asked for it'
> 
> The logic is not meant to be 'the AbstractRenderer
> asks the InlineArea to
> render itself', but rather, 'the AbstractRenderer
> asks the InlineArea for
> the specs necessary to render it'.

Exactly!  Renderers get specs from the Area objects,
and use that data to render the object.  Rendering is
done by renderers.

> In order to be able to respond to such a call, the
> InlineArea inevitably
> gets coupled to the different possible renderers

Actually no--The Renderers get coupled to the
InlineArea, as well as every other type of Area
object, which is fine.  Working with InlineAreas,
querying their traits, rendering them, etc., is their
job.  But the InlineAreas aren't coupled to the
Renderers anymore--they don't make a reference anymore
to Render objects in their code.  

InlineArea ia.getTrait(); within the renderer code for
example:  Renderer knows about IA but IA is now
oblivious that it's being used by a Renderer object.

Glen

Reply via email to