Hi Bertrand, On Fri, 2002-05-24 at 15:25, Bertrand Delacretaz wrote: > > It will pass appropriate information, mostly the > > current fo object. > > Maybe passing a compound object (StructureRendererContext?) that *contains* > the current fo object would help, as the renderer might need to access > configuration, logging or other services.
We should be able to set common objects like the logging and config on the structure handler itself. But the context idea could be useful for other objects that it may need to access. > Looks good to me - basing the current rendering process on the structure > rendering stuff certainly makes sense. > > If I get it right, the processing pipeline would then look as follows: > parsing -> SAX events -> validation -> attribute resolution -> structure > rendering (SR) > > Where SR is either "RTF rendering" or "layout -> PDF rendering" Yes. Where the validation is done by the FO tree and attribute resolution is handled by the current property handling system. The RTF handler will get the fo java object, then it can get the properties and children (at the end). I'm not sure about the best way to do things like the table columns. It would be simpler if it could do a start table after it has all the table columns rather than needing to get each table column individually through method calls. Keiron. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
