On Tuesday 10 July 2001 04:27, Peter B. West wrote:
> > I have attempted to make Tree class operations thread-safe, and have
> added a subclass TreeRoot in an attempt to support fail-fast iterators
> as in AbstractList and its subclasses. Comments from more experienced
> Java folks would be welcome.
>
> My motivation, apart from the perceived need to give direct expression
> to the trees in use, was to provide a platform for some of the tree
> flattening operations which werer talked about here briefly. My
> concerns about the relationship between the final form of layout and the
> tree structure have tended to resolve in favour of virtual operations on
> an underlying tree, because the trees express so eloquently the
> relationships between the various layout components. If virtual
> flattening operations on trees are to be implemented, they will have to
> have well defined trees to work with, I should think.
>
> I still haven't looked in depth into the code, but it also occurs to me
> that, in association with the FO and area trees, a context stack would
> be a very useful way of keeping track of a lot of information that is
> relevant to the layout process. Some such stack or stacks may already
> be present in the code, explicitly or implicitly. Can someone point me
> in the right direction?
>
> Peter
Hi, Peter
Your Tree class efforts have not gone unnoticed. I've been mulling them over,
anyway.
My interest in what you are doing is not related to flattening, per se,
although this mechanism may simplify answering questions that we need to ask.
The kinds of questions that routinely come up are:
1. Is this area leading or trailing in context (page, even-page, odd-page,
column)?
2. Is this area first or last in a reference-area or page-sequence?
3. Get me the preceding or succeeding sibling. Get me all siblings and/or
ancestors that have this or that constraint (e.g. particular keep);
4. Tell me if there is a stacking constraint before or after this area? If
so, what is it?
There are convoluted mechanisms for doing some of this. Answering questions
about trailing conditions (is this area trailing in context? is this the last
area in the page sequence?) are currently not so easy. I don't want to even
think about trying to answer question 4 for all the different situations -
anything your efforts can do to simplify that would be great. I know that you
have taken an interest in space-specifier resolution; the first step of
course is just to figure out what the sequence of space specifiers is,
assuming a stacking constraint exists, and right now that would be a serious
pain in the butt.
I would recommend familiarizing with our current area hierarchy, assuming you
have not already done so. Basically Pages are flat within the area tree
(AreaTree); each page contains 5 AreaContainers (for the regions), and the
region-body itself is a container for 3 AreaContainers. One of those, the
main-reference-area, is a container for span-area AreaContainers, and
finally, span-areas contain ColumnAreas, which are also AreaContainers (and
represent normal-flow-areas). So you see that we are pretty closely following
the abstract model in the spec.
ColumnAreas contain all the actual normal flow stuff.
I cannot really say that there are any context stacks. Areas maintain a list
of their children, as a Vector. There is just no other context information
easily to be had, for example related to easily answering questions like the
above. If you look at the checkBreakBefore() method in PropertyManager,
you'll see the kinds of hoops we have to jump through right now to answer
basic questions...it would be nice to obviate the necessity for that.
Any insight you can bring to bear on this would be appreciated. I'd
personally be happy to assist with integrating your tree stuff into FOP.
Regards,
Arved
--
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Halifax, Nova Scotia
Wireless * B2B * J2EE * XML
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
