layout-master-set and the FO tree

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

As part of the process of building the FO tree, I have been looking at 
the layout-master-set FO.  It was while I was doing this that I became 
uncomfortable with the idea of the FO tree, or at least of attempting to 
realize the FO tree in some actual tree structure.  While the Area tree 
is quite clearly a tree, and a very nice one, too, it seems to me that 
the only reason there is an FO tree at all is that the XML in which it 
is expressed mandates one.

The FO structure is actually a collection of disparate elements - sets, 
sequences and trees.

Immediately under the root is a sequence of two elements, tucked away in 
the definition:

(layout-master-set,declarations?,page-sequence+)


1) a set consisting of the layout-master-set and the declarations.  It's 
a set because, although the XML structure decrees that the optional 
declarations must follow the layout-master-set, there does not seem to 
be any logical necessity for that.

2) a sequence of page-sequences.

The layout-master-set is a set of elements with the master-name 
property, and this property occurs only on elements of this set.

(simple-page-master|page-sequence-master)+

fo:flow elements must reference one of the elements of this set through 
their master-reference property.

All page-sequence-masters eventually resolve to a sequence of 
simple-page-masters, so the eventual target of each reference through 
the master-reference property is a simple-page-master.

Within an individual page-sequence-master is a sequence of elements:

(single-page-master-reference|repeatable-page-master-reference| 
repeatable-page-master-alternatives)+

A single-page-master-reference maps directly onto a simple-page-master 
via a master-reference of its own.  It provides a way of embedding 
simple-page-masters into a sequence of other elements.  The two are 
equivalent except for the nasty quirk that they are referenced by two 
necessarily different names.  Leaving that quirk aside, a 
simple-page-master maps directly onto a single-page-master reference.

A repeatable-page-master-reference also maps directly onto a simple-p-m. 
with the addition of a maximum-repeats count.  This is equivalent to 
specifying a {minimum,maximum} pair of {0,maximum-repeats}.  A 
single-page-m-r maps onto a repeatable-p-m-r with a {minimum,maximum} 
pair of {1,1}.

A repeatable-page-master-alternatives element also has a maximum-repeats 
count, but it maps indirectly onto a simple-p-m through one of a set of 
alternatives expressed in its immediate children.

(conditional-page-master-reference+)

Each conditional-page-master-reference contains a master-reference to a 
simple-p-m, and a set of conditions that a new page candidate must 
satisfy in order to use the associated simple-p-m.  The default values 
for each of these conditions are "any", i.e. any page candidate will 
satisfy the condition.

A repeatable-page-master-reference maps onto a 
repeatable-page-master-alternatives with the same maximum-repeats count 
and a single conditional-page-master-reference child with the default 
condition values.

If a page-sequence-masters, containing a single master-reference to a 
simple-page-master, can be inserted into a layout-master-set to shadow 
the simple-page-master to which they refer, then it is possible to 
reduce (or expand) the layout-master set into a set of page-sequences, 
all of whose elements are repeatable-page-master-alternatives, and a set 
of simple-page-masters, none of which are directly referenced through 
the master-reference of any fo:flow element, but only through the 
conditional-page-master-references.

The virtue of this approach is that it eliminates multiple handling of 
the full complexities of the layout-master-set; only the most complex of 
the sub-sequence specifiers remains.  The data structures are also simpler -

fo:flow master-references key into...

a hash of page-sequence-masters, keyed on master-name
   each containing
     a list of repeatable-page-master-alternatives
       each containing
         a list of conditional-page-master-references
                into...

a hash of simple-page-masters, keyed on master-name

These structures are so simple that there seems no need for more than a 
very few object types to represent and manipulate them.

None of this needs go into the FO tree as such.  As pages are not 
actually generated until the simple-page-masters are applied to fo:flow 
and fo:static-content elements, or vice versa, the pages need not go 
into the FO tree.  Neither need the simple-page-masters.  They are a 
hash which floats around at the top level - as a data structure within 
fo:root, e.g., and need only be accessible to the page generation logic. 
  The only tree-structured elements left are fo:static-content and fo:flow.

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org