jfor integration: right after the FO tree building stage?

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Hi team,

I started looking at the FOP source code in more detail last week, and from 
what I understand at this point I think it would make sense to integrate jfor 
as a "structure renderer" right after the FO Tree building stage.

At this point my idea would be to:

a) add a Visitor pattern mechanism to visit the FOTree independently of 
layout operations

b) split layout() methods in two, adding a method called "getProperties()" or 
something (see details below)

c) implement a Visitor that would generate RTF from the FOTree, calling 
getProperties() on the way

d) maybe having getProperties() do its work only once even if called multiple 
times, and calling it both before the Visit and at the start of layout()

Of course, this shouldn't be limited to jfor, the FOTreeVisitor should be 
reusable for other output formats. 

Does this sound like I'm on the right track?

- Bertrand

Appendix: layout() method discussion.
For what I've seen in the source code, some computations (property 
resolution, if I understand right) done in the layout() methods would need to 
be moved to a "pre-layout" stage: maybe breaking layout() in two.

Taking flow.Block as an example:
void layout()
{
  . . .stage 1): properties acquisition
  this.align = this.properties.get("text-align").getEnum();
  this.alignLast = this.properties.get("text-align-last").getEnum();
  this.breakAfter = this.properties.get("break-after").getEnum();
  . . .more property reading

  . . .stage 2): actual layout  
  int breakBeforeStatus = propMgr.checkBreakBefore(area);
  . . .
}

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

StructureEvents concept (was: jfor integration: right after the FO tree building stage?)

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Hi Keiron,
(of course comments from everyone are welcome!)

Thanks for the info and sorry for not replying sooner - but I feel our slow 
discussion is going the right way.

> A visitor pattern sounds right. Instead of building the fo tree and then
> using the layout managers to create an area tree. Use a structure renderer
> to read from the fo tree.

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)

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?

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: jfor integration: right after the FO tree building stage?

[Keiron Liddle <ke...@aftexsw.com>]

Hi Bertrand,

The layout methods and how they work are subject to change with the layout 
process. So don't read too much from these methods.

A visitor pattern sounds right. Instead of building the fo tree and then 
using the layout managers to create an area tree. Use a structure renderer 
to read from the fo tree.

Fo each element in the fo tree when creating we call: start, 
handleAttributes and end. We should be able to put the visitor in various 
sections depending on the type of element and the layout managers may also 
be able to operate in the same areas (ie. have a common interface).

We want to be able to process elements as soon as possible and dispose of 
used data so it should be something that can work from the area tree at 
early stages.

Regards,
Keiron.

On 2001.12.17 13:53 Bertrand Delacretaz wrote:
> Hi team,
> 
> I started looking at the FOP source code in more detail last week, and
> from
> what I understand at this point I think it would make sense to integrate
> jfor
> as a "structure renderer" right after the FO Tree building stage.
> 
> At this point my idea would be to:
> 
> a) add a Visitor pattern mechanism to visit the FOTree independently of
> layout operations
> 
> b) split layout() methods in two, adding a method called
> "getProperties()" or
> something (see details below)
> 
> c) implement a Visitor that would generate RTF from the FOTree, calling
> getProperties() on the way
> 
> d) maybe having getProperties() do its work only once even if called
> multiple
> times, and calling it both before the Visit and at the start of layout()
> 
> Of course, this shouldn't be limited to jfor, the FOTreeVisitor should be
> 
> reusable for other output formats.
> 
> Does this sound like I'm on the right track?
> 
> - Bertrand
> 
> Appendix: layout() method discussion.
> For what I've seen in the source code, some computations (property
> resolution, if I understand right) done in the layout() methods would
> need to
> be moved to a "pre-layout" stage: maybe breaking layout() in two.
> 
> Taking flow.Block as an example:
> void layout()
> {
>   . . .stage 1): properties acquisition
>   this.align = this.properties.get("text-align").getEnum();
>   this.alignLast = this.properties.get("text-align-last").getEnum();
>   this.breakAfter = this.properties.get("break-after").getEnum();
>   . . .more property reading
> 
>   . . .stage 2): actual layout
>   int breakBeforeStatus = propMgr.checkBreakBefore(area);
>   . . .
> }

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org