On Jan 11, 2007, at 22:31, J.Pietschmann wrote:

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.

Interesting figures...

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.

This was indeed altered, I don't know when, and by whom precisely (Glen or Finn, IIRC).
Anyways, the hierarchy is currently:


and only FObj has a protected childNodes instance member, which is a generic ArrayList (and as I hinted, they are all created with: new java.util.ArrayList(), which defaults to an initial backing Object[10]).

A FONode only holds the reference to the parent in the tree, and the FObj.childNodes list is only created when FObj.addChildNode() is called, so if there is no child element, this reference will always be null.

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.

I was already thinking along the lines of creating a subclass of Vector, or an implementation of List, but I'm beginning to wonder if it wouldn't be worth it to create a link between the children...? Instead of holding a reference to an ArrayList, each FObj would have three references: parent, firstChild, nextSibling. Add that FOContainer interface or a FONodeIterator to navigate through it... could work out. 8)

The benefit would be that the average size of an FObj becomes much more transparent: three references, the properties and a handful of private helpers.

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

In the trunk, extensions are treated very differently from what I can tell. Mainly thanks to Jeremias, IIC, who made extensive changes when implementing XMP metadata. They are stored in a separate collection (ExtensionAttachments), which adds its own flexibility, but also difficulty. I'm still not sure how one would have to write an arbitrary fo extension that is supposed to influence the flow of the layout algorithm without needing access to the deeper layout API. Maybe we'd need a sort of generic ExtensionLayoutManager, too...?


Reply via email to