Looks like you made a thorough analysis. What I read made sense to me although I didn't check everything to the last character. Providing the Context interface through the LayoutContext didn't occur to me and I don't know if it's the right way, but if it just clicks in there without much hassle then it's probably a good idea. I'd have implemented the Context as an inner class to the LMs but then I haven't investigated this so thoroughly as you just did. I simply stumbled over it back in January and what I wrote there was simply what was occuring to me at the time (having been a newbie to the layout engine, too, back then).
So. I believe you're on the right course. Your approach seems to be fine-grained enough to handle every case and still limit the additional code to where it is needed. This is going to be a big jump into the layout engine for you. I'm glad you want to try it. Please don't forget to document your work with test cases ("test-first" has proven to be very helpful while I'm coding in FOP's layout engine). I'm looking forward to reviewing you patch. And thanks so much for your help!!! BTW, I'm very positively surprised and extremely pleased about your contributions so far. Is your boss supporting you or have you simply become addicted to FOP? :-) Just curious. On 19.08.2005 17:58:48 Manuel Mall wrote: > I have just documented the rules with respect to determining the base > value for percentage calculations on the WIKI . I also looked at the > fop-dev messages related to the code in this area ( and ). > > If my analysis in  is correct we have broadly speaking 4 different > cases to consider: > > 1) Percentages resolved against property values (mainly font-size) in > the fo tree. That is the "easy" case and can be done during fo tree > construction similar to some other relative properties. This would get > rid of the need to carry the property lists into the LengthBase (see > ). > > 2) Percentages resolved against dimensions (ipd, bpd, padding rectangle, > etc.) in the area tree (current area, parent area, ancestor block, > etc.). This is the "hard" case - discussion below. > > 3) Special case dealing with intrinsic sizes of e-g and i-f-o (2 > properties). This could be handled "locally". > > 4) Special case for resolution against region (1 property). Again this > could be handled locally. > >  deals with the case 2) above and problems in the current system. The > current system uses the fo tree to simulate upwards navigation through > the areas. It is the LMs responsibility to add dimension information to > the FOs which is then used for percentage resolution. The alternative > proposed is for the LMs to construct a "context" object which is passed > to the property getValue() function. This context object (working name > PropertyResolutionContext) will provide the means for the property > resolution code to get to the relevant dimensions, e.g. provide getters > like getParentAreaIPB(), getContainingBlockBPD(), > getIntrinsicHeight(), .... The context object internally could make use > of the information stored in the current LayoutContext (may be by > defining PropertyResolutionContext as an interface LayoutContext can > implement it?) as well as in the area tree constructed so far. > > I'll stop here - does this makes sense so far? Worth pursuing further? > Remember I am new to this and be grateful for any 'gotchas' and the > like to be pointed out to me. > > Manuel > > On Fri, 19 Aug 2005 04:20 pm, Jeremias Maerki wrote: > > On 18.08.2005 17:32:54 Manuel Mall wrote: > > > I am currently looking at the XSL-FO spec with respect to resolving > > > percentages in property values because it was mentioned on this > > > list that the current system in FOP needs improvements. For many > > > properties the spec refers to the 'closest ancestor block area that > > > is not a line area'. This again is the same as 'containing block'. > > > However, I also came across a description saying 'closest area > > > ancestor that was generated by a block-level formatting object'. > > > Now are these the same things: 'closest ancestor block area that is > > > not a line area' == 'closest area ancestor that was generated by a > > > block-level formatting object'? It sounds to me like they are the > > > same or do I miss some subtle difference? > > > > It's probably the same although I can't shake the feeling, either, > > that there could be a subtle difference. But I'm pretty sure that the > > intent is for it to have the same effect. I think it boils down to > > having good test cases which document all the different > > possibilities. Based on these we can in time find out if there are > > indeed some differences by looking at each and every case. > > > > BTW, my original mail to suggest a refactoring of the percentage > > handling mechanism (just for reference): > > http://marc.theaimsgroup.com/?l=fop-dev&m=110630658730554&w=2 > > > > I don't claim that my proposal is the right way to pursue this but I > > still think it probably offers the best flexibility even if it > > probably complicates the layout managers a bit. > > > > Thanks for looking at this. It's on my list but not for just now. > > > > Jeremias Maerki >  http://wiki.apache.org/xmlgraphics-fop/PropertyHandling/Percentages >  http://marc.theaimsgroup.com/?l=fop-dev&m=110630658730554&w=2 >  http://marc.theaimsgroup.com/?l=fop-dev&m=110442946030972&w=2 Jeremias Maerki