This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 479683 - fop fails when using indexterm in a varlistentry
fop fails when using indexterm in a varlistentry
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: docbook-style-xsl (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-12 09:11 EST by Murray Cumming
Modified: 2009-02-17 11:02 EST (History)
6 users (show)

See Also:
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 11:02:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test.xml (2.15 KB, text/xml)
2009-01-12 09:11 EST, Murray Cumming
no flags Details
test.fo (57.94 KB, text/plain)
2009-01-12 09:12 EST, Murray Cumming
no flags Details
Stepping through xsltproc in gdb (573 bytes, application/octet-stream)
2009-01-21 09:47 EST, Omair Majid
no flags Details
strace of xsltproc (271.62 KB, application/octet-stream)
2009-02-09 10:22 EST, Omair Majid
no flags Details

  None (edit)
Description Murray Cumming 2009-01-12 09:11:35 EST
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 09:12:32 EST
Created attachment 328740 [details]
test.fo
Comment 2 Omair Majid 2009-01-19 10:47:24 EST
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 09:47:13 EST
Created attachment 329611 [details]
Stepping through xsltproc in gdb
Comment 4 Omair Majid 2009-01-21 09:50:16 EST
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 11:06:33 EST
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 09:23:10 EST
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 10:17:12 EST
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 10:22:33 EST
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 10:59:44 EST
(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 11:46:21 EST
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 12:02:10 EST
Thanks for report - it is really typo in that patch.
Comment 12 Ondrej Vasik 2009-02-11 12:18:31 EST
Fixed and built as docbook-style-xsl-1.74.0-7.fc11 and docbook-style-xsl-1.74.0-5.fc10.

Note You need to log in before you can comment on or make changes to this bug.