I have just documented the rules with respect to determining the base value for percentage calculations on the WIKI [1]. I also looked at the fop-dev messages related to the code in this area ([2] and [3]).
If my analysis in [1] 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 [3]). 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. [2] 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 [1] http://wiki.apache.org/xmlgraphics-fop/PropertyHandling/Percentages [2] http://marc.theaimsgroup.com/?l=fop-dev&m=110630658730554&w=2 [3] http://marc.theaimsgroup.com/?l=fop-dev&m=110442946030972&w=2
