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