Created attachment 328739 [details] test.xml This markup causes an exception in fop: <varlistentry> <term> <indexterm><primary>Producer</primary></indexterm> Producer </term> This is the exception: SEVERE: javax.xml.transform.TransformerException: file:/home/murrayc/svn/flumotion-doc/doc/manual/pdf/flumotion.fo:8:57: Property id "id2739301" previously used; id values must be unique in document. Jan 6, 2009 4:04:07 PM org.apache.fop.cli.Main startFOP SEVERE: Exception javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: file:/home/murrayc/svn/flumotion-doc/doc/manual/pdf/flumotion.fo:8:57: Property id "id2739301" previously used; id values must be unique in document. at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:217) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:196) --------- javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: file:/home/murrayc/svn/flumotion-doc/doc/manual/pdf/flumotion.fo:8:57: Property id "id2739301" previously used; id values must be unique in document. at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:724) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:317) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:214) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:196) Caused by: org.apache.fop.fo.ValidationException: file:/home/murrayc/svn/flumotion-doc/doc/manual/pdf/flumotion.fo:8:57: Property id "id2739301" previously used; id values must be unique in document. at org.apache.fop.fo.FObj.checkId(FObj.java:175) at org.apache.fop.fo.FObj.startOfNode(FObj.java:155) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:295) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:163) at com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:208) at com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:281) at com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.comment(ToXMLSAXHandler.java:406) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.comment(AbstractSAXParser.java:670) at com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.comment(XIncludeHandler.java:817) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:454) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:810) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:740) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:110) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:641) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:712) ... 5 more --------- Version-Release number of selected component (if applicable): fop-0.95-0.2.beta1 (the normal package for Fedora 10) How reproducible: Either create the fop file from the attached DocBook XML file, using the Docbook XSL fo stylsheet and then run fop on it, or just run fop on the attached generated .fop file. For instance: $ xsltproc -o test.fo --xinclude --catalogs http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl test.xml $ fop test.fo test.pdf
Created attachment 328740 [details] test.fo
Hi Murray, Thanks for reporting the bug. I can confirm the issue. However, fop is correct in reporting the error message. The test.fo (an XML FO) file produced by xstlproc contains two elements with the same id (id2757015). This is forbidden by the XSL standard [1]. It seems that xsltproc generates an incorrect XML FO file. I am trying to find out why this happens. [1] http://www.w3.org/TR/xsl/#id
Created attachment 329611 [details] Stepping through xsltproc in gdb
This is a bug in xsltproc. As the gdb log shows, xsltproc returns the same value for two calls to generate-id().
Perhaps Daniel can shed some light on this? If it's not xsltproc he can at least tell us why not.
Maybe it's not that simple. This is what xsltproc on Fedora 10 produces in that part of the .fo: <fo:wrapper id="id2757015"><!--Producer--></fo:wrapper> Producer </fo:inline></fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block><fo:inline> <fo:wrapper id="id2757015"><!--Producer--></fo:wrapper> Producer </fo:inline> But this is what xsltproc on Ubuntu Intrepid produces: <fo:wrapper id="id2935385"><!--Producer--></fo:wrapper> Producer </fo:inline> I find it strange that the whole fo:wrapper node seems to be duplicated. If it's really a problem with generate-id, then maybe Daniel would like a simpler test case, maybe using a simple test XML and XSL file.
Here's what happens when trying out the test case with saxon: saxon -o test.fo test.xml http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl produces <fo:list-item-label end-indent="label-end()" text-align="start"> <fo:block> <fo:inline> <fo:wrapper id="d0e60"><!--Producer--></fo:wrapper> Producer </fo:inline> </fo:block> </fo:list-item-label> <fo:list-item-body start-indent="body-start()"> <fo:block> <fo:block> A producer only produces stream data. </fo:block> </fo:block> </fo:list-item-body> and saxon -o test.fo test.xml /usr/share/sgml/docbook/xsl-stylesheets/fo/docbook.xsl <fo:list-item-label end-indent="label-end()" text-align="start"> <fo:block> <fo:inline> <fo:wrapper id="d0e60"><!--Producer--></fo:wrapper> Producer </fo:inline> </fo:block> </fo:list-item-label> <fo:list-item-body start-indent="body-start()"> <fo:block> <fo:inline> <fo:wrapper id="d0e60"><!--Producer--></fo:wrapper> Producer </fo:inline> <fo:block> A producer only produces stream data. </fo:block> </fo:block> </fo:list-item-body> So it looks like the local stylesheet is the one causing problems :(
Created attachment 331319 [details] strace of xsltproc xsltproc cant handle http:// and falls back to local stylesheets in /usr/share/sgml/docbook/xsl-stylesheets-1.74.0/
(In reply to comment #8) > Created an attachment (id=331319) [details] > strace of xsltproc > > xsltproc cant handle http:// and falls back to local stylesheets in > /usr/share/sgml/docbook/xsl-stylesheets-1.74.0/ Err... scratch that. xsltproc looks for local stylesheets first and only then uses http. So a workaround would be to remove the docbook-style-xsl package. I also tried reverting to 1.73.2-9.fc9 which seemed to solve this particular problem (but probably has other bugs)
If I rebuild docbook-style-xsl-1.74.0-4.fc10 without patch5 (docbook-xsl-list-item-body.patch) then the xsltproc and saxon both work fine, and fop can produce a pdf
Thanks for report - it is really typo in that patch.
Fixed and built as docbook-style-xsl-1.74.0-7.fc11 and docbook-style-xsl-1.74.0-5.fc10.