Peter B. West wrote:
Which modules? I'm not sure what you mean. The modularity of area processing? The Rec gives an utterly spurious view of this. It has been misleading developers since the drafts were first published, and giving the impression that things can be neatly modularised. Some of the persistent difficulties of design arise from this misunderstanding. However, I may be misreading you here. What modules do you have in mind?
All right, educate me please. (I have read your doc and don't get it). In as simple terms as possible (for my simple mind), why can't markers defer the resolution of their properties until layout time?
They can. They must. But then what happens to the idea that the FO tree can be processed and refined before the layout occurs? If you are going to defer the resolution, why not defer the parsing as well? Marker resolution requires the merging of the fo:static-content subtree (encountered *before* the corresponding fo:flow) with fo:marker subtrees which can only be determined as pages are laid out. Furthermore, this process may repeat with *different* fo:marker subtrees being attached at the same fo:retrieve-marker point in the static-content.
With pull parsing, events are extracted from a parsing event buffer *as required*. In general, this will occur "synchronously", but need not. The stream of static-content parsing events can be stashed away, the stream of fo:marker subtree events can be stashed away somewhere else, and the process of resolving the FO tree need never know that it is in fact reading an "asynchronous" stream of parser events in which fo:marker streams are attached by sleight-of-hand in place of the fo:retrieve marker dynamically and transparently, and that this parsing is happening after the event - well after the static-content was first encountered, and after the region-body has been laid out. Furthermore, it can be "rewound" and repeated for as long as new pages with new fo.marker retrievals are required.
"Synchronous" and "asynchronous" are relative terms here. It's all asynchronous, in the sense that the SAX component simply creates parse events and sticks them in a producer/consumer buffer.
The other problem is percentage lengths, where the percentage is defined against an enclosing area dimension. Doesn't it make sense to create the area before you even look at the FOs which will fill it? Creating the area also creates the context for the resolution of percentages. In the difficult cases where the area dimension is initially indeterminate, the unresolvable percentage can at least be immediately "attached" to the area dimension whose resolution will in turn, resolve the percentage. In most cases, however, the resolution will be immediate.
This approach, of having the containing area in place before parsing the contained FO subtree, is easy to implement with pull parsing, driven by the *areas*.
If I have not answered your question, yell out. I am quite happy to keep on at this until you at least understand my thinking on this, even if you don't agree with it.
Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
