Thanks for the feedback, and thanks for giving me some directions.  I'll 
try to chase some of them down in the next week of so.


Arved Sandstrom wrote:

> 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?
> 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 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

"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to