You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2002/02/07 12:15:53 UTC
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: StructureEvents concept
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: StructureEvents concept
Posted by "Peter B. West" <pb...@powerup.com.au>.
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: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: StructureEvents concept
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org