Further to this topic.
Peter B. West wrote:
Yes, and this whole post was a bit of a disaster. The point I had fuzzily in mind was that the resolution of marker properties can only occur as the area tree (of the fo:flow) is being constructed. Only then does "current page" have any meaning. It's an example of the impossibility of resolving FO property expressions independently of area tree construction.
I have attached a diagram illustrating my thinking about processing markers in the context of alt.design.
Fig 1) illustrates the general flow of control in alt.design's pull parsing. FoXMLEvents are pulled from buffer on demand, and processed into the FO Tree.
2) shows my original vague idea for handling fo:markers. Because there is no context for resolving fo:marker properties where they are encountered in the fo:flow, I was intending to divert the FoXMLEvents into named buffers for later processing in a manner parallel to the mainstream XML event processing.
3) represents the problem of reconciling a pre-built FO static-content sub-tree with a buffer of FoXMLEvents representing the fo:marker, within the overall context of the construction of the static region area sub-trees.
4) represents a solution in conjunction with 2). Viz., divert not only the fo:marker subtrees from the fo:flows into FoXMLEvent buffers, but also the whole of each fo:static-content subtree. As Joerg pointed out, the size of the static regions is fixed, so they have no impact on the layout of the region-body. (Let me know if I'm missing something here.) Furthermore, if they contain an fo:retrieve-markers, the resolution of the static content region is "dymanic" to the extent of the markers being retrieved.
The general solution is represented by 5). The whole of the static-content subtree is processed as the area tree for that region is being built, and after the region-body has been laid out. As fo:retrieve-markers are encountered in the stream of events, they are resolved with reference to the current and previous pages, and the appropriate fo:marker buffer becomes the reference for events. The existing mechanism for obtaining events can readily be generalised to query the appropriate buffer. Where a static-content sub-tree has no fo:retrieve-markers, the optimisation is obviously to resolve the sub-tree once.
The most interesting point here is that the processing of the FO sub-tree is driven from within the construction of the relevant area sub-tree. I am increasingly of the opinion that such should be the general approach to all FO tree handling - that it should be demand-driven by the construction of the area tree. I haven't considered thsi in enough detail to be more definite that that yet.
Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
<<inline: marker-handling.png>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
