Victor Mote wrote:
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

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.


Reply via email to