GNOME Bugzilla – Bug 61070
Numbering bug(s?)
Last modified: 2009-08-15 18:40:50 UTC
I'm using xsltproc from libxslt version 1.0.4 with libxml version 2.4.3 compiled on my Debian box. When numbering, in some cases, the count start from zero instead of one. For instance, the example in section 7.7 of the XSLT Specification from 16 November 1999 gives a wrong result in numbering H4's. Given the template: <xsl:template match="h4"> <xsl:copy> <xsl:number level="any" from="h1" count="h2"/><xsl:text>.</xsl:text> <xsl:number level="any" from="h2" count="h3"/><xsl:text>.</xsl:text> <xsl:number level="any" from="h3" count="h4"/><xsl:text> </xsl:text> <xsl:apply-templates/> </xsl:copy> </xsl:template> This will supposedly give a 3-part label to a h4 element, but the last number is off by one (e.g. it will give 1.1.0, 1.1.1, 1.1.2... instead of 1.1.1, 1.1.2, etc.) The problem seems to come from level="any": if I try to number all h2, h3, ... in the same fashion in my document, the last part of the label is off by one whereas all the previous parts are correct. The following template is supposed to give a four-part label, but shows the problem described here: <xsl:template match="h2|h3|h4|h5"> <xsl:copy> <xsl:number level="any" from="h1" count="h2"/> <xsl:if test="not(name(.)='h2')"> <xsl:text>.</xsl:text> <xsl:number level="any" from="h2" count="h3"/> <xsl:if test="not(name(.)='h3')"> <xsl:text>.</xsl:text> <xsl:number level="any" from="h3" count="h4"/> <xsl:if test="not(name(.)='h4')"> <xsl:text>.</xsl:text> <xsl:number level="any" from="h4" count="h5"/> </xsl:if> </xsl:if> </xsl:if> <xsl:text> </xsl:text> <xsl:apply-templates/> </xsl:copy> </xsl:template> The first <h2> is numbered 0 instead of 1, the following <h3> is numbered 1.0 instead of 1.1, etc. Setting format="1" does not help; setting format="a" gives a blank string instead of "a", "a" instead of "b", etc. Tests with xalan and saxon gave expected results. My guess is that level="any" is the culprit; if h2's are numbered with level="single", the numbers are correct; however, this breaks the numbering pattern (which is normal). Numbering with level="multiple" (in other situations) gives correct result, except that the formatting is different than the one in the spec (e.g. when given the format "1.1 ", a one-part label will be "1.", where the spec says it should be "1"; a three-part label will be "1.1 1" where one could expect "1.1.1", which is how xalan and saxon do it), although this is surely unrelated and maybe not a bug but rather a different interpretation of the spec (which is not too clear on this point).
Okay I think I have found the problem. I commited a fix http://cvs.gnome.org/bonsai/cvsquery.cgi?module=libxslt&branch=HEAD&branchtype=match&dir=libxslt&file=&filetype=match&who=veillard&whotype=match&sortby=Date&hours=&date=explicit&mindate=10%2F06%2F01+13%3A45&maxdate=10%2F06%2F01+13%3A47&cvsroot=%2Fcvs%2Fgnome but there is clearly a bit more work left to do. Please report if it doesn't fix the problem or if you found more bugs in this area. thanks Daniel P.S.: giving full but minimal examples of input and stylesheet allows me to process them faster :-)
Patch was wrong, this needs more work Daniel
Okay the patch to libxslt/numbers.c really fixes the problem. This should be faster too. http://cvs.gnome.org/bonsai/cvsquery.cgi?module=libxslt&branch=HEAD&branchtype=match&dir=libxslt&file=&filetype=match&who=veillard&whotype=match&sortby=Date&hours=&date=explicit&mindate=10%2F07%2F01+07%3A18&maxdate=10%2F07%2F01+07%3A20&cvsroot=%2Fcvs%2Fgnome thanks for the report, Daniel
Should be fixed in the last releases, Daniel