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 [EMAIL PROTECTED] http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
