> -----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 anew? <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. > ... Cheers, Andreas
