Bug 479683

Summary: fop fails when using indexterm in a varlistentry
Product: [Fedora] Fedora Reporter: Murray Cumming <murrayc>
Component: docbook-style-xslAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: fitzsim, kdudka, langel, omajid, ovasik, veillard
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: docbook-style-xsl-1.74.0-5.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-17 16:02:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
test.xml
none
test.fo
none
Stepping through xsltproc in gdb
none
strace of xsltproc none

Description Murray Cumming 2009-01-12 14:11:35 UTC
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

Comment 1 Murray Cumming 2009-01-12 14:12:32 UTC
Created attachment 328740 [details]
test.fo

Comment 2 Omair Majid 2009-01-19 15:47:24 UTC
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

Comment 3 Omair Majid 2009-01-21 14:47:13 UTC
Created attachment 329611 [details]
Stepping through xsltproc in gdb

Comment 4 Omair Majid 2009-01-21 14:50:16 UTC
This is a bug in xsltproc. As the gdb log shows, xsltproc returns the same value for two calls to generate-id().

Comment 5 Paul W. Frields 2009-01-21 16:06:33 UTC
Perhaps Daniel can shed some light on this?  If it's not xsltproc he can at least tell us why not.

Comment 6 Murray Cumming 2009-02-06 14:23:10 UTC
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.

Comment 7 Omair Majid 2009-02-09 15:17:12 UTC
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 :(

Comment 8 Omair Majid 2009-02-09 15:22:33 UTC
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/

Comment 9 Omair Majid 2009-02-09 15:59:44 UTC
(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)

Comment 10 Omair Majid 2009-02-09 16:46:21 UTC
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

Comment 11 Ondrej Vasik 2009-02-11 17:02:10 UTC
Thanks for report - it is really typo in that patch.

Comment 12 Ondrej Vasik 2009-02-11 17:18:31 UTC
Fixed and built as docbook-style-xsl-1.74.0-7.fc11 and docbook-style-xsl-1.74.0-5.fc10.