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