On Sun, Feb 15, 2004 at 10:43:12PM +0100, Finn Bock wrote: > [Simon Pepping] > > >Finn, > > > >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. > > > >The XSL spec says (XSL-PR/slice3.html#section-N1208-Conceptual-Procedure): > > > >'The formatting object supplies parameters to its children based on the > >traits of areas already in the area tree, possibly including areas > >generated by the formatting object or its ancestors.' > > > >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.
Indeed, I had not thought of that. > >which has the advantage that it does not load the FO tree > >with information that it does not need to have. > > I initially had a separate PropertyContext object where the length was > stored. The FO element then had a reference to the PropertyContext and > there was a PropertyContext for every FO. But since there was a > one-to-one correspondence between the FO's and the PropertyContexts I > decided to put the information directly in the FO's instead. > > Somehow, in our current design, the information must be stored in an > object that exists: > > - when the properties are parsed. > - when the break possibilities are created. > > The FO nodes fulfills both requirements. > > 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. I see the problem now. Thanks for the explanation. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
