On Mon, Dec 13, 2004 at 02:26:40PM -0700, Victor Mote wrote:
Simon Pepping wrote:
The code you presented seems to be an algorithm implementing
an iterator over a tree. Because it maintains its state, it
can be stopped and resumed at will, provided you keep a
reference to it.
If
Finn Bock wrote:
Did you notice that if a FOTree (or a fragment of it) is
serialized to a preorder sequential representation with end
markers, the preorder, postorder and child events can be
fired directly from the input stream?
IOW the event based layout can work both of a normal
Simon Pepping wrote:
The code you presented seems to be an algorithm implementing
an iterator over a tree. Because it maintains its state, it
can be stopped and resumed at will, provided you keep a
reference to it.
If LMIter would have a reference to its parent LMIter, and
could return
The code you presented seems to be an algorithm implementing an
iterator over a tree. Because it maintains its state, it can be
stopped and resumed at will, provided you keep a reference to it.
If LMIter would have a reference to its parent LMIter, and could
return to it after having processed
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.
[Victor]
This model probably works fine if you never need to look ahead, but there
are
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.
[Victor]
This model probably works fine if you never need to look ahead, but there
are numerous examples
The problem with Keirons layout code (with respect to large input
files) is that it works top-down on the LM tree and thus require the
creating of the complete LM tree for the page sequence. To better fit
within SAX event model the layout process should also be event driven,
triggered f.ex by
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.
[Peter]
I suppose so. And I suppose that making layout event-driven would
better fit in
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
Peter B. West wrote:
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
Finn Bock wrote:
...
The problem with Keirons layout code (with respect to large input files)
is that it works top-down on the LM tree and thus require the creating
of the complete LM tree for the page sequence. To better fit within SAX
event model the layout process should also be event
[Peter]
As a completely unintentional side-effect, it gave me the tools to solve
the really critical FOP performance problem on large files. This isn't
going to be solved by micro-efficiencies on FO tree storage.
I'm going to use this as a excuse to outline my thinking for handling
large input
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
!
For the smaller files (up to 50 megabytes) FOP works fine, but processing large files
isn't very performant.
Thanks for your help and time,
Christophe Vanderhaeghen
analist - programmer
_
Christophe Vanderhaeghen
Volvo IT Belgium
AS-OTD (location BTE
14 matches
Mail list logo
