Re: Percentages in XSL-FO
[Jeremias Maerki] 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. [Manuel Mall] I have been working on this for the last couple of days and I am not so sure any more about the 'being on the right course' bit. So this is a bit of a cry for feedback. I will try to outline the issues. Most percentages are being resolved in the same way: Find the appropriate ancestor area and get the relevant dimension from it. That sounds very simple. The current system solves this by a) using the fo tree to navigate upwards until an appropriate fo is found which generates the type of area we are looking for and b) by the layout managers to attach dimension information to the fos. The reason we are looking for a redesign is that this doesn't appear to be the right way to attach layout information to the fos. The current system is also not complete in its implementation but that is a different issue. The alternative proposed is to use a context which is created by the layout managers and passed to the property resolution system, i.e. the getValue() call. Sounds good so far as the layout managers have access to the dimension information, actually in my code in the moment the layout managers are the context, that is they implement the interface I have defined for the context. But we still need to move up some form of tree or list to find ancestors. The obvious choice would be the area tree but that doesn't work as in many cases when we need a resolved property value the areas (as objects in fop) haven't been created yet. Also the areas are not linked back upwards in the tree although a parent pointer could be introduced for that purpose. So, if we can't use the area tree and don't want to use the fo tree what then? The next thing coming to mind is the layout managers as they form a tree structure as well. They even have a parent pointer. So, to find the dimensions we are looking for we navigate up the parent links of the layout managers until we find one which generates what we are looking for and get the dimensions from it. That is a very good summary of the issue. Thank you. But, the parent link is not set consistently and sometimes late. There is for example the case where a layout manager in its constructor accesses a property value. To be able to resolve it would need to know its parent layout manager which isn't set yet. The fix for that is to carry the parent layout manager into all layout manager constructors. Or delay all calls to Length.getValue(..) until after the layout manager tree is completed and the dimensions are available. So the initialization is allowed to store Lengths but only during getNextKnuthElement() is it allowed to extract the int values from the Lengths. This is where my problem is. We have a system now which is simple (attach dimension information to the fo tree) and we are replacing it with something that changes many internal interfaces, virtually hundreds of method calls by adding extra parameters, and still does the same thing. Which is exactly why I didn't complete the work at the time. Navigate up a tree structure (and I am not 100% sure that navigating up the layout manager tree really is the right thing to do) to find a suitable node and get the appropriate values from that node. The information obviously belong in either the LM tree or in the Area tree. So it is the right thing IMO to move it out of the fo tree. regards, finn
Re: Percentages in XSL-FO
(comments inline) On 24.08.2005 09:10:26 Finn Bock wrote: [Jeremias Maerki] 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. [Manuel Mall] I have been working on this for the last couple of days and I am not so sure any more about the 'being on the right course' bit. So this is a bit of a cry for feedback. I will try to outline the issues. Most percentages are being resolved in the same way: Find the appropriate ancestor area and get the relevant dimension from it. That sounds very simple. The current system solves this by a) using the fo tree to navigate upwards until an appropriate fo is found which generates the type of area we are looking for and b) by the layout managers to attach dimension information to the fos. The reason we are looking for a redesign is that this doesn't appear to be the right way to attach layout information to the fos. The current system is also not complete in its implementation but that is a different issue. The alternative proposed is to use a context which is created by the layout managers and passed to the property resolution system, i.e. the getValue() call. Sounds good so far as the layout managers have access to the dimension information, actually in my code in the moment the layout managers are the context, that is they implement the interface I have defined for the context. But we still need to move up some form of tree or list to find ancestors. The obvious choice would be the area tree but that doesn't work as in many cases when we need a resolved property value the areas (as objects in fop) haven't been created yet. Also the areas are not linked back upwards in the tree although a parent pointer could be introduced for that purpose. So, if we can't use the area tree and don't want to use the fo tree what then? The next thing coming to mind is the layout managers as they form a tree structure as well. They even have a parent pointer. So, to find the dimensions we are looking for we navigate up the parent links of the layout managers until we find one which generates what we are looking for and get the dimensions from it. That is a very good summary of the issue. Thank you. I agree. I'd be very careful about depending on the area tree for getting values. First, we need to make sure we don't create additional memory problems. I also don't think that the area tree is the right place to get such values from. Furthermore, I can already predict that there will be a discussion about some changes in the area tree for the creation of an intermediate format (basically re-parseable XML representation of the area tree but probably with some changes in the approach). I can't tell yet, how this will look and what the effects will be on the area tree. More on that at an appropriate time. But, the parent link is not set consistently and sometimes late. There is for example the case where a layout manager in its constructor accesses a property value. To be able to resolve it would need to know its parent layout manager which isn't set yet. The fix for that is to carry the parent layout manager into all layout manager constructors. Or delay all calls to Length.getValue(..) until after the layout manager tree is completed and the dimensions are available. So the initialization is allowed to store Lengths but only during getNextKnuthElement() is it allowed to extract the int values from the Lengths. I agree with Finn here. These values should only be resolved when the layout engine has actually started its work, not already while the LM tree is being built. This is where my problem is. We have a system now which is simple (attach dimension information to the fo tree) and we are replacing it with something that changes many internal interfaces, virtually hundreds of method calls by adding extra parameters, and still does the same thing. Which is exactly why I didn't complete the work at the time. Navigate up a tree structure (and I am not 100% sure that navigating up the layout manager tree really is the right thing to do) to find a suitable node and get the appropriate
Re: Percentages in XSL-FO
On Sat, 20 Aug 2005 11:33 pm, Jeremias Maerki wrote: snip/ 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. Jeremias, Thank you for your kind words. If you mean 'boss' in the domestic sense the answer is no - she certainly doesn't like me doing any more work on computers than I am doing any way. If you mean 'boss' in the business sense then there is a big problem: I am my own boss and any time I spent on fop I am not earning money to feed the bunch at home. But seriously - I have been lurking on the fop-dev list for many years and even provided some minor patches back in the days when 0.20.4 and 0.20.5 where hot property. This all started when I introduced and used fop in a high volume document centric server application for a customer. As a result of that success I always wanted to contribute back something to an open source project whose 'fruits of labour' I was using commercially. However, fop didn't appear to be going anywhere for a long time (apart from some at times not so friendly discussions on this list). Finally, you wrote on this list that fop 1.0 may be nearing a first pre-beta release. That's when I got encouraged to look at it in more detail again and then decided to help with the push to get it 'out of the door'. Does that satisfy your curiosity? Manuel
Re: Percentages in XSL-FO
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-devm=110630658730554w=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-devm=110630658730554w=2 [3] http://marc.theaimsgroup.com/?l=fop-devm=110442946030972w=2
Percentages in XSL-FO
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? Manuel
