xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter B. West" <pbw...@powerup.com.au>
Subject Re: [VOTE] Properties API
Date Sat, 06 Dec 2003 00:09:43 GMT
Victor Mote wrote:
> Peter B. West wrote:

> The topic at hand is what API is needed for the FO Tree to be able to pass
> property values to its clients.

Ok.  The trouble is that the relationship between FO Tree and Area Tree 
is, for me, still very much an unresolved question.  When we start 
talking about these things, I go back to thinking about the details of 
the interaction between FO Nodes and Areas in the Area Tree.

Isn't part of your rationale in this "get" method to provide for the 
feedback of FO data to the Areas?  At what points do you see the method 
being invoked?

>>1) markers
>>I have a pretty well-developed idea of how to implement the FO tree
>>building side of this in alt.design.  It involves
>>static-content-specific changes to the current FO tree building
>>algorithm, and a slight generalization of the SyncedFoXmlEventsBuffer
>>class to allow events to be read from a variety of sources.  In a word,
> OK, I have addressed this.

We do have very different grafting methodologies.

>>2) Area tree dependencies for FO expressions.  Basically, length
>>calculations involving percentages.
> OK, I proposed passing the relevant Area to the "get" method.

Is this happening when an area is looking for information about its 
generating FO?

>>2a) Handling the expressions.
> This can all be done within the FO Tree.
But, if I understand you correctly, only with reference to the Area Tree 
(via the passing of Area parameters in the "get" method.)
>>2b) Designing the interaction between the FO builder and the Area tree
> OK. I proposed the following, which you have not addressed:
> <from-previous-posting>
> Your experience and insight on this issue are extremely important. If Areas
> know how to find their FOTree heritage as well as their AreaTree heritage,
> can you think of any concept that is missing to do Property resolution,
> assuming that the relevant Area is passed to the "get" method on the FOTree
> side?
> </from-previous-posting>

This seems to me to be begging the question to some extent.  Rather than 
the Areas knowing how to find their FOTree heritage, isn't it necessary 
for the FOs to be able to find the AreaTree ancestry of the Areas that 
the FOs are generating?  Isn't that what passing the relevant area in 
the "get" is all about?  At the same time, however, it does get us 
thinking about the precise nature of this interaction.

>>3) Layout look-ahead and backtracking.  Closely related to 2b.
> AFACT, these would become simply re-"get"ting the value from the FO Tree,
> passing a new Area as a parameter.
>>4) Managing the association out-of-line areas (footnotes and floats)
>>with the FONode/Area in which it was defined and the higher-level areas
>>(e.g.  before-float-reference-area, footnote-reference-area,
>>main-reference-area) which are juggled as a result of the lower-level
> Is this not just a specialized case for the general case #2 above?

Very specialized.  These things can force re-layout of the existing 
page, and can even ramify to previous pages, as we move towards a more 
"intelligent" layout strategy.  There are two problematical aspects:

Layout look-ahead, to determine layout "errors" (e.g. footnote overflow, 
last page), and

Layout lookahead to determine actual dimensions ("auto" table layout.)

Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

View raw message