I'm sorry, I'd better shut up if I can't dive fully into this matter. I'm just wasting your and my time. Finn seems to have a better grip on this area.
On 26.08.2005 11:21:58 Manuel Mall wrote: > 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 Jeremias Maerki
