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.
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 all
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
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
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 nu
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 (w
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
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 t
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 driven,
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 pre
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 th
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 numer
12 matches
Mail list logo
