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? Alternatively, it must be done in the layout managers / percentage resolution code. But this appears to be non-trivial as well. 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. Or getValue() could throw an exception - but there are many 100's of calls to getValue() which all would need to be checked then. Or we could set a flag on the property (e.g. isResolved()) to be tested after calls to getValue(). 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". Any one with better ideas / comments? Manuel
