Finn Bock wrote:
The loop can be stopped when we temporary run out of FO tree nodes and restarted again when new nodes has been added. I suppose that the FO tree can then be viewed as a stream of FO nodes.
This model probably works fine if you never need to look ahead, but there are numerous examples (well discussed in the archives) where one does need to do that, the most obvious being automatic table layout. Peter's solution to that is pull parsing, which probably works, but forces an intermingling of interests that I need to avoid. My solution is to serialize the FOTree as necessary (I do not have this working). The bottom line is that, if you conceivably need to see both the beginning and end of the input simultaneously (which we do), and you are writing so that disk space is the only constraining factor, you will have to either be prepared to re-parse the data (Peter's approach) or to serialize what has already been parsed (my approach).
Victor, I think you may have misinterpreted an aspect of Defoe's design. The re-parsing (of attribute data) is only required for static-content and markers. Even then, it is not essential, merely the simplest way to achieve the result, given a stream of pre-parsed (in SAX terms) events. I'm quite happy with serializing the partial results where rendering cannot be resolved due to forward references. I don't see auto table layout and other localized look-ahead requiring this.
I have never been able to see a third alternative. But I am always open to new ideas. I rather suspect that the current FOP design is oriented toward common use-cases rather than a comprehensive treatment that will handle all cases.
Peter
