Andreas L Delmelle wrote:
Which brings us to another important piece of information that would be
interesting to know: how big are each of those instances?
Quite some time ago I did some statistics on number of children
of FOs, using the FOP examples and FO files from bug reports.
The breakdown was roughly the following
~50% no children, mostly FOText nodes and FOs like region-body
and page-number-citation
~40% one child, mostly blocks and inlines (fo:wrapper) having
exactly one FOText node as child
<10% 2..10 children
<<1% more than 10 children, mostly fo:flow, table and table-body
and a few blocks, usually wrapping other blocks.
Real world documents with more tables and inline formatting might
have more multi-child FOs.
I haven't checked whether FOText still inherits the children field
on trunk. If so, it is certainly a good idea to get rid of this
(in the maintenance branch, this had widespread implications).
The case of exactly one child might be worth optimizing too.
Two possible solutions:
A) all FO node implement a FOContainer interface, for example
FONode childAt(int)
int numberOfChildren()
where FOText for example would hardcode return values of null and 0.
B) Use a FOChildrenIterator interface with specific implementations
for FO nodes which can have none or exactly one child.
Furthermore, in the maintenance branch most of the more specific
FOs copied children from the generic children list into properly
typed fields before starting layout, in many cases the generic
children list could have been deleted afterwards if this wouldn't
have broken a few generic recursive algorithms like the one adjusting
available space due to footnotes. The discussion then had Keiron said
he'd even get rid of the generic children list in favour for properly
typed fields, thereby giving up some flexibility needed for
extensions. This could be implemented with either of the approaches
above too (FOContainer interface or FOChildrenIterator interface).
J.Pietschmann
