On 26.08.2005 10:41:31 Manuel Mall wrote: > The spec says: The percentage is calculated with respect to the > corresponding dimension of the closest area ancestor that was generated > by a block-level formatting object. If that dimension is not specified > explicitly (i.e., it depends on content's > block/inline-progression-dimension), the value is interpreted as > "auto". > > The second sentence of the above statement is currently not implemented > resulting in "messed up" output. What is the best way to fix this? > Can we do it on the fo tree when the property is constructed, i.e. walk > up the tree and see if a corresponding dimension is set explicitly and > if not not force the property to "auto"? There are complications like > width and height are corresponding properties to i-p-d/b-p-d and > writing mode and reference orientation are also relevant. May be this > is too much for the fo tree / property construction phase?
Yes, I think so. It also duplicates code. See below. > Alternatively, it must be done in the layout managers / percentage > resolution code. But this appears to be non-trivial as well. Yes, but the LMs have to resolve the "auto" values anyway with the help of the LayoutContext they get passed by the parent. That's one more reason why it's a good idea IMO to let the LM provide the percentage resolution context. > Currently the getValue() call just returns an int. If we want to use an > int value to signal back "cannot resolve" we need to reserve a value > for that purpose, may be MIN_INT? But this then has to flow through the > expression validation logic. Reminds me a bit of handling of NULL > values in SQL - nasty. Not necessary IMO. The LM needs to check "width.getEnum() != EN_AUTO", for example, and chose the right value. I think this paragraph would only have applied if we'd consider doing the resolution in the FO tree, right? > Or getValue() could throw an exception - but there are many 100's of > calls to getValue() which all would need to be checked then. Uh, oh. > Or we could set a flag on the property (e.g. isResolved()) to be tested > after calls to getValue(). I believe checking getEnum() should be enough. > Or we put more logic into the LMs for this. They would have to test the > property if it is of type Relative...Property. If so they have to go up > the LM chain and check if the ancestor block has an explicit b-p-d, if > yes do normal property resolution, if no behave as if the property was > set to "auto". Have a look at BlockContainerLM. I really think this needs to be done in the LMs since they have to know these values anyway and they resolve them, too. > Any one with better ideas / comments? No better comments other than try to provide the necessary values through the percentage resolution context and the LMs. I believe it's the best way. HTH (and I hope I understand this stuff enough to give good advice/comments). Jeremias Maerki
