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 answer:
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 systems. 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
