(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 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. I believe that the LM tree is the right place. I'd really be careful about the area tree. I hope that helps a bit. Have a quick recovery from your cold! Jeremias Maerki
