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 > parent/children linked tree and a sequential tree.
Hmmm. I must have totally misunderstood your original point, which I think you expressed much better in your second paragraph above. I certainly didn't mean to argue against event-based layout, which, in general, I support, but rather against the idea that an FOTree node can necessarily be laid out when it is first encountered. And I think I understand now why you have done the massive propagation of properties -- am I correct in understanding that you are essentially flattening the tree so that inheritance must be captured before that flattening takes place? Or are you simply making that an option now? > > The bottom line is that, if you > > conceivably need to see both the beginning and end of the input > > simultaneously (which we do), > > I can see a need for several passes over the same tree > fragment, but do we really need to see the beginning and the > end at the same time? > > The auto table example appears to need 2 or 3 sequential > passes over the table subtree (one to find the > minimum/maximum column width and one to do the actual > layout), but the layout process is still sequential. Perhaps we have a semantical misunderstanding here. By "see", I mean that we know what is in it, and a multiple-pass solution can accomplish that. I'm sure I acknowledged that as one of the two possibly ways that I could think of to accomplish the end. Victor Mote
