> -----Original Message-----
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
> In my view FOP consists of a number of subsystems that are ordered
> from upstream to downstream. The FO tree is the most upstream system,
> the area tree (or objects that are constructed by a renderer) is the
> most downstream system.

Indeed, but...

> Information should flow downstream, not
> upstream.

(Hmm. Isn't there an Aussie in this house who disagrees? Callbacks, Peter?
;) Nah, bad example...)

I gave the example of resolving a percentage p of an indefinite page-height
or -width...
Say you have to do this for a page that turns out to be .. quite long
(--say, an ancient scroll or something.. ).
For this you'd need the total width of every object laid out on the page
(nothing rendered yet), then a very simple: reswidth = totwidth * (1 +
p/100 ) / ( 1 - p/100 )

Don't know about you, but even *with* the possibility of the next renderer
not using the same configuration as the first, I wouldn't want to just throw
away a possibility of re-using the layout info and only having to reuse the
calculated values (--or, in the worst case, maybe results from a calculation
based upon higher-level relationships between the different configurations

Basic point: the preferred direction of the information flow depends (almost
entirely) upon the relationship between the up- and downstream events that
is being
You are IMO very correct by stating that 'if the Layout info can be reused,
so can the AT and the renderer', however, if I interpret correctly, the
latter two are designed to dispose of their created objects ASAP.
The downstream objects hold a reference to the upstream ones, not the other
way around --unless you have a way out of there, as long as a certain
page-sequence is referenced, the entire Layout/AT/Renderer structure would
exist in memory, which can get .. quite large even for moderately sized
documents. Would it really be worth a shot to change the design there, and
flip a switch? Throw the FOTree away and just fill up the AT and re-use



Reply via email to