Chris Bowditch
Fri, 13 Jun 2008 09:08:37 -0700
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