Andreas Delmelle wrote:
<snip/>
In the meantime, I made this change locally, but stumbled on the fact that we
do not have an event defined for non-applicable properties.
Now I'm wondering whether we should warn about those at all. According to the
XSL-FO Recommendation, any property may be specified on any FO. If the property
is inherited, warning about its being non-applicable is more a nuisance than a
feature. I, for one, would rather not get a warning each and every time I
define the standard font-size on the fo:root, for example.
That would leave the non-inheritable properties, but there we also have the
possibility of specifying the property on an ancestor (to which it does not
apply), and then retrieve the value on one of the descendants using
from-nearest-specified().
Since we can't check for the use of that function at the time the property is constructed, I'd be inclined to leave the code virtually unaltered.
The only modification would be:
* surrounding the method body of ColumnNumberPropertyMaker.make(PropertyList,
String, FObj) with a check for the type of FO for which the property is being
constructed. If that isn't a table-cell or a table-column, then we /silently/
ignore it (after all, it's always possible that the value is referred to
further down the stream)
* if it is not a table-cell or table-column, return a zero value to avoid the
property subsystem calling make(PropertyList) to construct a default/initial
value
If a user does supply a non-applicable property, this is not an error. He may
scratch his head for while, trying to figure out why it doesn't work, but I
don't think we can expect FOP to cater for /every/ possible mistake... In this
case, all it takes is one look at the property definition (*) to find out that
the behavior is only defined for fo:table-cell and fo:table-column.
+1. I totally agree with your assessment. We don't want lots of warnings
generated by font-family on fo:root or similar. The same is true for non
inheritable properties as they may be used by functions like you said.
We need to silently ignore column-number on non-applicable FOs to avoid
NPE or similar errors during layout. The only other alternative is to
make layout more robust, but that is a more difficult solution. Also it
doesn't feel the right place to solve this proble, it should be dealt
with in the properties package.
Thanks,
Chris
