On Fri, 26 Aug 2005 05:14 pm, Jeremias Maerki wrote: > 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.
They do, that's correct. But in this case they have to figure out that although a percentage is set on the property they should treat it like "auto". > > > 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? > The problem is that getEnum() != EN_AUTO is true because a percentage was set but the percentage value should be ignored and treated like EN_AUTO if no explicit b-p-d was set on the parent. It is that particular decision which is not currently handled. > > 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. I don't think it is - see above. > > > 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 Manuel
