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?
To the first question, yes. Layout will be invoking the method as it
computes traits for Areas. If Layout is trying to compute, say, the width
for an Area, and information about the Area's ancestry is needed to complete
that computation, then pass that Area to the FO Tree "get" method that does
the computation. The Area needs to conform to an interface that has methods
that can return the appropriate values. For example, the percentage rule
whose URL you referenced refers in item 1 to "the content-rectangle of the
closest ancestor block-area that is not a line-area". So, perhaps a
"getNotLineAreaAncestorBlockWidth" is a method in that interface. Similar
methods can be created for other values that may be needed in a computation.
> >>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,
> >>grafting.
> >
> >
> > OK, I have addressed this.
> >
>
> We do have very different grafting methodologies.
I understand. What I am trying to get you to do is to *consider* the
possibility that grafting may not be any more complicated than passing a
grafting point around. I am trying to get you to take a step back from your
implementation, and help us determine whether, in theory, it really needs to
be any more complicated than that.
> >>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?
Yes. Why not? The problem before us is that the generating FO says "I need
to know some resolved values from the Area tree to complete this
computation." So we say "OK, here is an object that conforms to an interface
that will give you that information." FO Tree says "OK, here is the value
that I compute for that, based upon that object's responses." Layout says
"Thank you" and plugs the value into the Area's traits.
> >>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.)
Yes, in some cases that is true.
> >>2b) Designing the interaction between the FO builder and the Area tree
> >>builder.
> >
> >
> > 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.
The reason that the Area Tree needs to know its FO Tree ancestry is
precisely because of the grafting issue. You are correct that the FO Tree
needs information from the Area Tree to complete its computations, but how
does this beg the question? The question is "How do we get the Area
information to the FO Tree so that it can complete its computation?" My
answer is "Pass the Area to it, and let the FO TRee ask the Area for the
needed information?" It may not be a good answer, but I don't think it
begged the question.
> >>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
> >>contents.
> >
> >
> > 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.)
I don't understand your point. We all know that these things are
troublesome. We are not trying here to solve those problems, but to consider
whether the proposed interface is workable in the problem solution. You
either know the Area Tree information that is needed for the computation or
you don't. If you don't, then you have to do some more work until you do.
The issue of relayout of pages is not relevant either. If stuff needs to be
re-laid out, get its values based on the new layout.
What am I missing?
Victor Mote
