Re: Thoughts on design - FO expressions in markers

["Peter B. West" <pb...@powerup.com.au>]

Fopdevs,

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