Re: Structure Handlers - RTF Renderer
Hi Peter, Sorry for taking so long, week's been hectic around here. . . . I think you will still have attribute resolution problems. Remember that some attributes are only going to be resolved during the layout. I understand that some attributes cannot be resolved at the parsing stage, and as Keiron mentioned, there will need to be a way to transfer them with all the relevant information. The implications for RTF are not that clear for me though (mostly because jfor is currently sooo weak about attributes, AND I never worked on a print-type renderer) - I think I need to be able to play with actual code to better understand the issues. AFAIK Keiron is working on a first shot StructureHandler which should help me jump in. . . . It seems to me that the general solution would involve the definition of a structure api, taking account of the layout dependencies. . . . I agree, but again the whole picture is not clear enough in my mind yet to be able to specifiy these dependencies. I suggest that we wait for Keiron's skeleton code, on which we build a rough RTF converter which will help us (me at least ;-) understand the issues on concrete examples. We should then be able to define a set of XSL-FO documents that show different use-cases for attribute resolution. . . . 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. . . . Unfortunately not - what jfor currently does is 1-to-1 mapping of basic attributes like font sizes, bold, italic, etc. so there's not much to be said. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
On Tue, 2002-05-28 at 01:20, Peter B. West wrote: 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. The layout is handled by the viewer of the document. All we can do is transfer across the flow and other information. For properties that depend on the layout then they either need to be transferred to the output document in a meaningful way, translated or ignored (default value). I would like to have a look at how the MIF handler would work with this but I don't have a viewer so it is a bit difficult (does anyone have access to a viewer?). 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. If we do a parallel layout and resolve the properties that cannot be transferred at the same time then it may give a better result. I guess it would depend on circumstances and if it is really worth it. I don't know the 'use cases' so it would only be a guess. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
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]
Re: Structure Handlers - RTF Renderer
Hi Keiron, . . . 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. . . . ok, It wasn't clear for me either what would go into the context object, but it is certainly better that passing the FO object directly. . . . 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. . . . Would this scenario be easy to implement? startTable startRow (maybe after all FOs for the row have been parsed) startCell (maybe after all FOs for the cell have been parsed) start/end stuff for cell contents endCell more start/endCell endRow more start/endRow endTable or do you mean just one startTable with row/columns contained in the FO? I'd prefer many event calls, as the StructureHandler wouldn't need to know as much about FOs in this case. Conceptually (and this might be useful for concrete stuff like testing too), I think the StructureHandler needs to be able to rebuild the XSL-FO structure with as little code as possible. Maybe (if easier to implement or to avoid slowing down PDF rendering) this event generation can be done by an intermediate component that decodes the FOs and generates detailed events? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
On Mon, 2002-05-27 at 11:37, Bertrand Delacretaz wrote: Would this scenario be easy to implement? startTable startRow (maybe after all FOs for the row have been parsed) startCell (maybe after all FOs for the cell have been parsed) start/end stuff for cell contents endCell more start/endCell endRow more start/endRow endTable or do you mean just one startTable with row/columns contained in the FO? If you need to output the row after all FOs for the row then you could simply use the endRow to get the row and output its children. I'm thinking of the start as setting up the current context and the properties, then when others start it will belong to the current context. The end can then indicate context and finish off the formatting object and if easier then to handle the children and put everything into the output. These methods are called by the fo tree objects themselves as a result of the FOTreeBuilder calling through the SAX events. fo - rtf startTable - setup table endRow - create row info in rtf endTable - end table in rtf I'd prefer many event calls, as the StructureHandler wouldn't need to know as much about FOs in this case. Conceptually (and this might be useful for concrete stuff like testing too), I think the StructureHandler needs to be able to rebuild the XSL-FO structure with as little code as possible. Maybe (if easier to implement or to avoid slowing down PDF rendering) this event generation can be done by an intermediate component that decodes the FOs and generates detailed events? I think the fastest way to handle this would be to have a boolean where if true it calls all start/end otherwise it only calls the ones required by the layout structure handler. I can't think of any better way without having two fo trees or something slower being handled in the FOTreeBuilder. I think the names should be StructureHandler, LayoutHandler, RTFHandler etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
On Mon, 2002-05-27 at 14:22, Bertrand Delacretaz wrote: What about: a) base class with all start/end methods but most of them are empty (costs very little to call IMHO compared to the whole rendering process) b) derived class for RTFHandler and such, where most or all methods do something. But you know the code much better than I do, so I'll let you choose the best option. How about actually starting to implement this? I can spare a few hours a week to help, but having some skeleton code to start with would help me a lot. -Bertrand That is roughly the idea. I will commit the bits I have (and fix another problem) and we can go from there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
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]
