Victor Mote wrote:
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)?

IIRC it was made to allow areas GC'd early. In the maintenance branch, if something keeps a reference to an area, like tables did, the tree for the whole page is kept until the page sequence ends and the whole FO subtree can be reclaimed. However, the parent pointer isn't always set properly, for example line areas may not set it (fortunately, because basic-link keeps a reference to the line).

In both cases, the maintenance branch seems more correct to my naive eye.
Uh, duhhhhh.... :-)

Is there any enthusiasm for a lowest-common-denominator approach to the area
tree?
No. I'd rather have the bugs in HEAD fixed. Then refactor the Area
heirarchy (factoring out a bordered area, for example), and get a
more efficient representation for words.

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.
The bad news is there are areas not corresponding to FOs.

J.Pietschmann



Reply via email to