Re: StructureEvents concept
On Thursday 07 February 2002 12:15, Keiron Liddle wrote: . . . Do we need to have this completely separate method of reading the fo tree (layout managers is the other) when both do some similar things. I'm not sure, I just can't picture how it should work at the moment. Right - let me try to reformulate what we need to be able to create an RTF document. If this is already covered by the current layout manager interface, then it's fine. We need: - start and end of document yes - start and end of page sequence yes (mapped to an RTF document section) - resolved properties yes - static areas yes, for RTF they should at best come right after the start of the page sequence - add info after end of block level object: block, table, list etc. yes, for RTF we need both start and end events for most such constructs: table cells, list items, etc. So I think what you suggest maps well with the requirements of an RTF render (or other structure-based renderers). Where should I look in the current code to start playing with this? layoutmgr package? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: StructureEvents concept
On Friday 08 February 2002 01:58, Peter B. West wrote: Bernard, (That's Bertrand by the way ;-) What sort of structure does rtf exhibit? Is it a page-based structure, or is it divided, like xslfo, into page definitions and flows? This is a critical difference as far as the design goes. From what you say below, it seems to rely on a flow-based model. In the sense of not being mapped to printed pages directly (unless hard page-breaks are used), RTF is flow-based, not page-based. An RTF document is broken out in sections which are very similar to page-sequences in concept. The pagination is done by the RTF reader (usually a word processor) when it renders the document to screen or print. Constructs like tables, lists etc. are flow-based but need to be closed, kind of like the nested elements of an XML document. I think RTF maps well to XSL-FO documents in terms of structure. What has been hard in our past efforts to write an RTF renderer was that FOP didn't provide end events (or we didn't find out how it did) for tables, lists and other elements, for which the RTF render needs to generate element-closing codes. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: StructureEvents concept
Bernard, What sort of structure does rtf exhibit? Is it a page-based structure, or is it divided, like xslfo, into page definitions and flows? This is a critical difference as far as the design goes. From what you say below, it seems to rely on a flow-based model. Peter Keiron Liddle wrote: On 2002.01.11 10:38 Bertrand Delacretaz wrote: ... contracts: c1. zero to N StructureEventListeners can register with an FONode to receive StructureEvents c2. an FONode that does not have its own list of StructureEventListeners uses that from its parent c3. StructureEvents are like: FONodeStartEvent, FONodeEndEvent, FONodeAttributesEvent which are sent at the end of the corresponding FONode methods c4. FONode has an usage counter, that prevents it and its parents from being disposed of until its value is zero (or do we want to rely on the gabage collector only for this?) In this way, StructureEventListeners (like an RtfRenderer based on jfor code) could release FONodes early if they are able to render on the fly, or keep them around if needed. How does this sound? This doesn't quite feel right to me. Why do we need to count things if those that need them simply keep a reference. Do we need to have this completely separate method of reading the fo tree (layout managers is the other) when both do some similar things. I'm not sure, I just can't picture how it should work at the moment. We need: - start and end of document - start and end of page sequence - resolved properties - static areas - add info after end of block level object: block, table, list etc. I don't quite understand how these things fit in the rtf. Should we call everything StructureEvent... or FONodeEvent... or FOStructureEvent...? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: StructureEvents concept
On 2002.01.11 10:38 Bertrand Delacretaz wrote: If I understand right, FONode objects should be disposed of as soon as possible - in this case I'd suggest creating a StructureEventListener as follows: actors and goals: ag1. FOP creates FONodes while parsing the input stream ag2. FOP wants to dispose of FONodes as soon as possible, to be able to work on SAX event streams without keeping everything in memory ag3. StructureEventListener wants to use FONodes as soon as they are created, and often needs specific FONodes to stay around until they have been used (rendered) This sounds right. contracts: c1. zero to N StructureEventListeners can register with an FONode to receive StructureEvents c2. an FONode that does not have its own list of StructureEventListeners uses that from its parent c3. StructureEvents are like: FONodeStartEvent, FONodeEndEvent, FONodeAttributesEvent which are sent at the end of the corresponding FONode methods c4. FONode has an usage counter, that prevents it and its parents from being disposed of until its value is zero (or do we want to rely on the gabage collector only for this?) In this way, StructureEventListeners (like an RtfRenderer based on jfor code) could release FONodes early if they are able to render on the fly, or keep them around if needed. How does this sound? This doesn't quite feel right to me. Why do we need to count things if those that need them simply keep a reference. Do we need to have this completely separate method of reading the fo tree (layout managers is the other) when both do some similar things. I'm not sure, I just can't picture how it should work at the moment. We need: - start and end of document - start and end of page sequence - resolved properties - static areas - add info after end of block level object: block, table, list etc. I don't quite understand how these things fit in the rtf. Should we call everything StructureEvent... or FONodeEvent... or FOStructureEvent...? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
