Hi Keiron, >. . . > This structure handler will have a number of methods for the start and > end of elements like block, table, list item etc. and others for > external graphic etc. >. . .
I agree that high-level events like start/end block, table, etc. are what we need for structure rendering. Currently jfor works by mapping SAX events (that come directly from parsing the XSL-FO) to the construction of RTF objects, so the kind of interface that you mention would certainly help integrating the current jfor code. > 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. >. . . > Currently the StreamRenderer does a very limited version with start, end > document and end page sequence. This could become a subclass of the > structure handler where it will only use a few methods (probably should > rename it to RenderHandler). > . . . 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" - Bertrand --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
