J.Pietschmann wrote:
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).
Some of that makes sense, and some sounds like stuff that just needs to be
fixed. In any event, I understand the desire to keep the area tree lean.
In both cases, the maintenance branch seems more correct to my
naive eye.
Uh, duh :-)
Hmmm. I don't know what this means.
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.
From my perspective, the first item is not really an option, yet. FWIW, it
is actually third on my list, after 1) PionerLS (and finally killing the
maintenance branch), and 2) fonts.
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.
I didn't do a good job of explaining this. What I am looking at /
experimenting with is two separate shadow object concepts, one for FONode
and one for Area. (There is no GoF Shadow pattern -- the closest that I can
see is Decoration, and that is not it.) Each of these shadow concepts would
have a null interface, and each FONode and Area subclass would have exactly
one pointer to a shadow object conforming to the respective interface.
Implementations of the interface would belong to the LayoutStrategy, and
would be used to expand the respective tree objects. When a page is
completed, the related Area shadows can be discarded (even before the Areas
themselves have been). When a page sequence is completed any shadow objects
attached to it can be discarded as well. This gives LayoutStrategies a place
to store data that they may need without forcing either FOTree or AreaTree
to know anything or do anything about it. The only costs to the non-layout
portion of FOP is 1) the cost of the memory for the pointer in each FONode
and Area object, and 2) the cost of traversing the tree fragments and
discarding any shadow objects that exist. I think these costs are acceptable
for the additional flexibility. Of course, for LayoutStrategies that wish to
use them, there are additional costs, but those are tradeoffs anyway. The
LayoutManager LS goes through and creates a bunch of LM objects instead.
I am not entirely sure yet whether the above idea is feasible. The issue
that I haven't worked through yet is dealing with subclass differences,
e.g., if I need fo.flow.Block to have additional items stored that FONode
doesn't need, or InlineArea to have items that Area doesn't. I think our
already implemented Visitor patterns can help us with these issues. I'll
know more shortly. In the meantime, if you and Glen and anyone else paying
attention would care to comment on whether the above ideas are acceptable or
not, that would be appreciated. If they are *not*, then I believe bringing
the PioneerLS into the trunk is not feasible, and I will abandon it.
Victor Mote
