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 with the SAX event model. It just doesn't make sense from the point of view of layout which is basically a top-down process.
By top-down, do you mean the visiting order of the nodes in the tree? Or the structure of the code that does the layout? Like this:
process(Node n) { preorder(n) for (each child in n) { process(child) child(n, child); } postorder(n); }
The traverse() code does the exact same as the process() code.
I noticed that, and wondered what you were getting at.
The differences are:
- All people immediately recoqnize process(). - process() can use local variables to store state.
A major drawback of process() is that is darn hard to suspend processing and then restart it. Our current getNextBreakPoss() code is a nice example of just how hard it is.
The penny drops. There has always been a requirement for some form of co-routine, and I see now what you are getting at. I think I see why you mentioned this in the same breath as "the SAX event model", but that confuses the issue, I think. What you are proposing is compatible with stream parsing, and in fact, fits quite well. Alt-design parsing provides on-demand events to the FO tree builder, and is automatically regulated by up-stream demand.
It seems to me that the events most natural to the layout process are events in the FO tree, and that the main requirement for "restarts" in the FO tree is to do with the inherent dialogue between FO and Area trees. However, the discussion is too general, and my understanding of the particular problems you are addressing is too vague, for me to make meaningful comments.
Peter
