Re-sending due to mailer problems.


-------- Original Message --------
Subject: Re: [PATCH] Support for percentages and table-units
Date: Thu, 19 Feb 2004 12:48:59 +1000

Andreas L. Delmelle wrote:
-----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

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

Thanks Andreas. Yes, I disagree, but then, so does the spec. What information *should* do is not terribly relevant. We need to work out and express what information *must* do to get this thing working.


Basic point: the preferred direction of the information flow depends (almost entirely) upon the relationship between the up- and downstream events that is being

Yep. (Even without the end of the sentence.)

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

Or process the minimal relevant parts of the FO and Area trees in parallel. That is what I am working towards. I believe that page-at-a-time layout with just in time processing of the FOs is possible. Given that, both FOs and Areas can be kept alive while required. (I haven't given any thought to rendering.) Note that forward references are always going to be a problem, but that a combination of weak/soft/phantom references and serialization should keep memory requirements manageable.

Peter B. West <>

Reply via email to