Jeremias and Finn, many thanks for your feedback. More inline below.
On Wed, 24 Aug 2005 03:36 pm, Jeremias Maerki wrote: > (comments inline) > > On 24.08.2005 09:10:26 Finn Bock wrote: > > [Jeremias Maerki] > > <snip/> > > >> > > >>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. > Thanks > 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. > OK, noted - I will not use the area tree. > > > 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. > Great suggestions will do as such. One problem though (Finn you may have an idea here?): The LengthRangeProperty properties in their methods to getMinimum(), getMaxmium(), getOptimum() call checkConsistency(). checkConsistency in turn calls getValue(). So even if the initialization wants to store Lengths only it will by side-effect do a getValue(). OK, we can make the rule that the managers can't store individual Lengths of those LengthRangeProperties in their initialisation. But we still would have to alter the getOpt/Min/Max methods to accept a context because of the implicit evaluation. Is there a better way of doing this? Shall we make checkConsistency() public and request that the managers call it before accessing individual components of a LengthRangeProperty? > > > 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! > You both agree that the LMs are the right way to go. That's great and gives me enough confidence to proceed further down that path. It will be a big patch though whenever it comes :-). > > Jeremias Maerki Manuel
