Bertrand, < I started writing this before the flurry of messages in the last day or two, so it may now be redundant. If so, however, I have missed part of the conversation. My recollection of consensus of opinion some months ago was as I state just below. >
I think you will still have attribute resolution problems. Remember that some attributes are only going to be resolved during the layout. It seems to me that the general solution would involve the definition of a structure api, taking account of the layout dependencies. to get there, you need to define an XML equivalent of the structure that is presented to the RTF renderer. Define all of the data types that are being passed into RTF, and isolate the circumstances in which information cannot be passed across prior to layout. Out of that you might get three interface definitions: ideal RTF, layout RTF and FOTree RTF. With any luck, ideal RTF would co-incide completely with layout RTF, and differ only in a few minor details from FOTree RTF. Then have the same thing done for, say, MIF. From a comparison of the layout MIF and FOTree MIF, try to develop a general FOStructure API which will hopefully be flexible enough to accommodate any other structure renderers which come along. The danger in not doing that is that you end up with an FOStructure API that is only an RTFStructure API. It may be necessary to build in a fundamental option to choose, e.g., layout RTF or FOTree RTF. In the latter case, the User Agent would arbitrate unresolved arrtibutes; in the former, the layout engine would have to proceed far enough to resolve all of the attributes. One possibility in the former case is that you _may_ find it is possible to do the transformation to FOTree RTF in XSLT. Just a flight of fancy perhaps. You may already have documented the structure transformations needed for FO->RTF. If so, it would be a very good idea to include them in the NEW DESIGN documentation. Peter Bertrand Delacretaz wrote: >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]
