> -----Original Message-----
> From: Finn Bock [mailto:[EMAIL PROTECTED]
> [Simon Pepping]
<snip />
> > However, I am not happy with your
> > solution. During the layout process, you feed the page dimensions back
> > into the FO tree, in PageLayoutManager.createPageAreas.
> Yes, and in BlockLayoutManager and in all the other LM that defines base
> length for percentages.
> > I think it
> > would be a better design if, in order to resolve the percent-based
> > properties, you would not climb the FO tree but the Area tree. That
> > avoids feeding back results from the Area tree into the FO tree.
> >

Yes, but... isn't it the main idea that we serialize the FO tree for
possible later re-use? Independently of the Area tree?

In that case, it seems more than logical to feed these back into the FOT
once, instead of re-resolving them from the AT when the document is rendered

<snip />
> > [Simon ]
> > Holding those parameters in the FO tree is one solution. Extracting
> > them from the area tree layed out up to that point is another
> > solution,
> But there is *no* areas layed out or even created at the point where we
> need resolved length. When getNextBreakPoss is called, we only have a
> series of BreakPoss's stored in different layout managers.
> The Area objects are created much later when we have BreakPoss's for an
> entire page. PageLM then calls addAreas which recursively creates all
> the areas for the page.

Strong point. Personally, I see the benefits of both approaches in that one
could be used to store in the FOT _a_ base for the percentages to be set to
preliminarily resolved values, with the option of re-resolving (or merely
fine-tune) them WRT more accurate figures from the AT downstream (--which
can take into account info provided by the LM's).

> Perhaps the dimensions should be stored in the layout manager tree but
> the LM tree is not available when the the properties are parsed and
> there is no way to get from a FO to the LM's that the FO creates.




Reply via email to