When I transform the attached file to XSL-FO and process the resulting FO with FOP, I get this warning: WARNING: span="inherit" on fo:block, but no explicit value found on the parent FO. I'm using the 1.73.2 DocBook XSL. I get this problem with both FOP 0.94 and FOP 0.95beta.
Created attachment 21991 [details] simple docbook file that demonstrates the problem
(This issue came up on the docbook-apps mailing list.) There are two problems IMO: - I don't see why FOP should issue a warning while such a construct is perfectly legal. I realize that this may help debugging stylesheets, but this will also annoy most users. - The code in PropertyMaker.make(PropertyList, String, FObj) looks suspicious. It tries to get the explicit value set on the parent, whereas it should get its /computed/ value. Granted, the end result is probably the same, still. Leaving it over to property specialists... Vincent
(In reply to comment #2) > (This issue came up on the docbook-apps mailing list.) > There are two problems IMO: > - I don't see why FOP should issue a warning while such a construct is > perfectly legal. I realize that this may help debugging stylesheets, but this > will also annoy most users. Granted... Question in this particular case, however, is what the stylesheet authors hope to achieve by adding 'span="inherit"' anyway. The property only has effect for areas returned by a flow-child. Although the property is not inherited, further descendants automatically take on the characteristics of their parent (see: http://www.w3.org/TR/xsl/#span) > - The code in PropertyMaker.make(PropertyList, String, FObj) looks suspicious. > It tries to get the explicit value set on the parent, whereas it should get its > /computed/ value. Granted, the end result is probably the same, still. I think the reason behind the warning is indeed stylesheet debugging, in the sense that one would expect a value on the parent for a specified value of 'inherit' on the child (?) The keyword is permitted as a value for inherited properties, but hardly useful there... If used for non-inherited properties, then it should indeed evaluate to the computed value. The explicit value obtained in PropertyMaker is used /only/ to check whether there was a value specified on the parent. If this is not the case, then the computed value will evaluate to the initial value, and so could just as well have been omitted... All the same for me to have FOP shut up in those cases, or reduce it to debug-level.
resetting P2 open bugs to P3 pending further review
change status from ASSIGNED to NEW for consistency