I think Joerg already said this, but it appears that the main challenge to
completing a port of the maintenance branch layout to the trunk will be a
reconciliation of the differences between the two area trees. Since we don't
have a fully-functional layout system using either of the two models, I have
several questions along these lines that I hope one of the veterans can

1. image/ImageArea in the maintenance branch subclasses InlineArea.
area/inline/Image (which appears to be the equivalent trunk class)
subclasses Area (even though it is in the inline package).

2. layout/Area in the maintenance branch stores a parent (through its
superclass Box) which (along with pointers to children) ties the AreaTree
together. It also stores a generatedBy variable, which I think points to the
FObj which generated it. Both of these seem to be missing in the trunk. I
haven't spent a lot of time digging into this yet, but it looks like the
LayoutManagers may be storing this information in the trunk. Since this is
information that is useful only during layout, perhaps this change was made
to make the Area Tree more lean (i.e. use less memory)?

In both cases, the maintenance branch seems more correct to my naive eye.
However, I admit I have much to learn about the two area trees and layout

Is there any enthusiasm for a lowest-common-denominator approach to the area
tree? In other words, to add back some of the variables to accommodate the
Pioneer layout system? I am not eager to clutter it up, but I think some
modest retrofits will keep this moving forward, and we can always factor
them back out later if we think it is useful and convenient. I am eager
enough to get all of our problems in one pile that I think it is worth it to
create some modest-sized ones to get that done. I am contemplating adding a
"shadow" concept to the FO Tree that would allow a layout system to store
data in an object that has a one-to-one relationship with a node in the FO
Tree. Something similar could be done with the Area Tree, with the data
essential to rendering stored in one and the layout-oriented data in the
other, which can be jettisoned when layout is done, to save memory.

Victor Mote

Reply via email to