GNOME Bugzilla – Bug 413451
when comments are preserved, text is reordered in the output
Last modified: 2007-06-07 14:25:18 UTC
$ xsltproc --version Using libxml 20627, libxslt 10120 and libexslt 813 xsltproc was compiled against libxml 20627, libxslt 10120 and libexslt 813 libxslt 10120 was compiled against libxml 20627 libexslt 813 was compiled against libxml 20627 stylesheet: ================================================ <xsl:template match="comment()"> <!-- pass through comments --> <xsl:comment><xsl:value-of select="."/></xsl:comment> </xsl:template> ================================================ XML input: ================================================ <varlistentry id="opt-memsize"><term><option>-m</option> &mems-r;</term> <listitem><para>Sets the amount of memory &clisp; tries to grab on startup. The amount may be given as <variablelist> <varlistentry><term><replaceable>nnnnnnn</replaceable></term> <listitem><simpara>measured in bytes </simpara></listitem></varlistentry> <varlistentry> <term><replaceable>nnnn</replaceable><command>K</command></term> <term><replaceable>nnnn</replaceable><command>KB</command></term> <listitem><simpara>measured in kilobytes </simpara></listitem></varlistentry> <varlistentry> <term>&n-r;<command>M</command></term> <term>&n-r;<command>MB</command></term> <listitem><simpara>measured in megabytes </simpara></listitem></varlistentry></variablelist> The default is 3 megabytes. <!-- #if (oint_addr_len+addr_shift==24) --> The argument is constrained between 100 KB and 16 MB. <!-- #elif (oint_addr_len+addr_shift==26) --> The argument is constrained between 100 KB and 64 MB. <!-- #elif (oint_addr_len+addr_shift==28) --> The argument is constrained between 100 KB and 256 MB. <!-- #else --> The argument is constrained above 100 KB. <!-- #endif --> </para><simpara>This version of &clisp; <!-- #if defined(SPVW_MIXED) && defined(SPVW_BLOCKS) --> <!-- #ifdef GENERATIONAL_GC --> is not likely to actually use the entire &mems-r; since &gc;ion will periodically reduce the amount of used memory. It is therefore common to specify 10 MB even if only 2 MB are going to be used. <!-- #else --> eventually uses the entire &mems-r;. <!-- #endif --> <!-- #else --> allocates memory dynamically. &mems-r; is essentially ignored (except that it determines the Lisp &STACK; size). <!-- #endif --> </simpara></listitem></varlistentry> ================================================ html output: ================================================ <dt><a id="opt-memsize"></a><span class="term"><code class="option">-m</code> <em class="replaceable"><code>memory-size</code></em></span></dt><dd><p>Sets the amount of memory <a href="http://clisp.cons.org" target="_top"><span><strong class="command">CLISP</strong></span></a> tries to grab on startup. The amount may be given as </p><div class="variablelist"><dl><dt><span class="term"><em class="replaceable"><code>nnnnnnn</code></em></span></dt><dd>measured in bytes </dd><dt><span class="term"><em class="replaceable"><code>nnnn</code></em><span><strong class="command">K</strong></span><br /></span><span class="term"><em class="replaceable"><code>nnnn</code></em><span><strong class="command">KB</strong></span></span></dt><dd>measured in kilobytes </dd><dt><span class="term"><em class="replaceable"><code>n</code></em><span><strong class="command">M</strong></span><br /></span><span class="term"><em class="replaceable"><code>n</code></em><span><strong class="command">MB</strong></span></span></dt><dd>measured in megabytes </dd></dl></div><p> <!--#endif--> The argument is constrained above 100 KB. <!--#else--> The argument is constrained between 100 KB and 256 MB. <!--#elif (oint_addr_len+addr_shift==28)--> The argument is constrained between 100 KB and 64 MB. <!--#elif (oint_addr_len+addr_shift==26)--> The argument is constrained between 100 KB and 16 MB. <!--#if (oint_addr_len+addr_shift==24)--> The default is 3 megabytes. </p><p>This version of <a href="http://clisp.cons.org" target="_top"><span><strong class="command">CLISP</strong></span></a> <!--#if defined(SPVW_MIXED) && defined(SPVW_BLOCKS)--> <!--#ifdef GENERATIONAL_GC--> is not likely to actually use the entire <em class="replaceable"><code>memory-size</code></em> since <a href="impnotes.html#gc" class="olink">garbage-collect</a>ion will periodically reduce the amount of used memory. It is therefore common to specify 10 MB even if only 2 MB are going to be used. <!--#else--> eventually uses the entire <em class="replaceable"><code>memory-size</code></em>. <!--#endif--> <!--#else--> allocates memory dynamically. <em class="replaceable"><code>memory-size</code></em> is essentially ignored (except that it determines the Lisp <a href="impnotes.html#vm" class="olink"><code class="literal">STACK</code></a> size). <!--#endif--> </p></dd> ================================================ note that the "The argument is constrained" lines are ordered differently in the input and output. the lines are NOT reordered by Saxon 6.5.5. please see https://sourceforge.net/tracker/?func=detail&atid=373747&aid=1617448&group_id=21935 for more information
please note that this bug hold up a CLISP release (http://clisp.cons.org)
In order to expedite action on this, please provide a complete stylesheet and xml file to demonstrate the bug, together with the expected output. The smaller these files are, the more likely it will be resolved quickly.
stylesheet: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"/> <xsl:template match="comment()"> <!-- pass through comments --> <xsl:comment><xsl:value-of select="."/></xsl:comment> </xsl:template> </xsl:stylesheet> expected should order the "The argument is constrained" lines the same way as the input (specifically, the "ifdef/elif/endif" comments must be in a valid order, i.e., acceptable to CPP). thanks!
ok. But the last sentence of my above comment applies - "smaller" includes any imports, and the last time I tried to debug using the docbook stylesheets it took a couple of months.
you might find this comment (see the SF bug issue link abovve) useful: I found that the reordering is taking place in the unwrap.p mode used in the template named 'paragraph' when the parameter html.cleanup="1". (there is more information there that you may find helpful in debugging this). alas, I am no expert in xsl, so my ability to help is limited to bitching and copying comments from one tracker to another :-)
At the time the problem occurs, routines within xsltproc have "recursed" to a depth of 68. This is a direct result of the recursive nature of the docbook templates, and is what makes it quite difficult to debug. I found (and fixed) two separate problems within the xpath module of the libxml2 library. This seems to fix the bug. Please download the latest version of libxml2 source code from SVN and see if it's ok.
I downloaded and compiled ftp://xmlsoft.org/libxml2/libxml2-cvs-snapshot.tar.gz ftp://xmlsoft.org/libxml2/libxslt-cvs-snapshot.tar.gz here is what I see: works correctly: $ xsltproc -version Using libxml 20623, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20623, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20623 libexslt 812 was compiled against libxml 20623 reorders stuff: $ xsltproc -version Using libxml 20628, libxslt 10120 and libexslt 813 xsltproc was compiled against libxml 20627, libxslt 10120 and libexslt 813 libxslt 10120 was compiled against libxml 20627 libexslt 813 was compiled against libxml 20627 $ ../../../libxslt-1.1.19/xsltproc/xsltproc -version Using libxml 20627-CVS2884, libxslt 10119-CVS1096 and libexslt 813-CVS1096 xsltproc was compiled against libxml 20627, libxslt 10119 and libexslt 813 libxslt 10119 was compiled against libxml 20627 libexslt 813 was compiled against libxml 20627
hmmm... apparently those "snapshot" files haven't been updated since January. Here's what I get at the moment: [bill@bbsf bug413451]$ xsltproc --version Using libxml 20628-SVN3621, libxslt 10120-SVN1428 and libexslt 813 xsltproc was compiled against libxml 20628, libxslt 10120 and libexslt 813 libxslt 10120 was compiled against libxml 20628 libexslt 813 was compiled against libxml 20628 I'll attach the resulting output from your test.
Created attachment 89515 [details] output from xsltproc after XPath fix
Thanks. When is the release due?
The problem with stale files on xmlsoft has been fixed by Daniel - you should be able to re-load them successfully now. The current (2.6.28) libxml2 release was in April, and the one previous to that was last October. Probably best to ask on the xml mailing list if you feel a new release is required. I'm going to go ahead and close this bug, as it would appear my fixes to libxml2/xpath.c are sufficient. Thanks for the report, and for your patience.
fix confirmed with $ ../../../libxslt-1.1.20/xsltproc/xsltproc --version Using libxml 20628-SVN3622, libxslt 10120-SVN1429 and libexslt 813 xsltproc was compiled against libxml 20628, libxslt 10120 and libexslt 813 libxslt 10120 was compiled against libxml 20628 libexslt 813 was compiled against libxml 20628 thanks!