>----- Oorspronkelijk bericht ----- >Van: Andreas Delmelle [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag, juni 13, 2008 01:18 PM > >>----- Oorspronkelijk bericht ----- >>Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] >>Verzonden: vrijdag, juni 13, 2008 12:17 PM >> ><snip /> >> >>FOP lacks of robustness here since it crashes instead of just giving >>a warning that column-number doesn’t apply to fo:block. Can you please >>create a bug report on Bugzilla, attaching a complete FO file containing >>your snippet above as an example? >>https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop >> >>This will help us to keep track of the issue. Thanks! > >This is a very easy fix. I'll see if I can take care of it ASAP. I just >checked the SVN > history of the related source file, and apparently, I had initially added > such a check > in the wrong place (ColumnNumberPropertyMaker.make(PropertyList), which is > normally only called to 'make' implicit values; removed in the meantime). > The check should still be made, however, in make(PropertyList, String, FObj), > so > that it is instead called when making the property off an explicitly > specified value.
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. WDYT? Cheers Andreas
