[Manuel Mall]
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?
It sounds just like a job for the property system since it already deals
with the corresponding properties and knows if a property is explicitly
set.
I don't think that there is an existing way to check if a fo is
block-level but that can be added (like generatesReferenceAreas()) or
just done by hand:
if (fo.getNameId() == Constants.FO_BLOCK || ...
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.
Ugh.
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,
The knowledge of explicit set properties isn't stored after the fo tree
is constructed. This is for memory reasons.
if
yes do normal property resolution, if no behave as if the property was
set to "auto".
Any one with better ideas / comments?
regards,
finn
