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


Reply via email to