When our production wiki kept throwing odd FOPException, I decided to investigate it a bit. I found out that it's possible to trigger an org.apache.fop.apps.FOPException 'The id "some id" already exists in this document' by creative naming of pages and including a certain heading in a page. The chances for this bug to emerge may be slim, but it happened in my company.

To trigger the bug, do following steps.

1. Create a new page to a space called Foo-Bar. No content needed on the page.
2. Create a new page to the space called Foo
3. In the Foo page insert a heading Bar, e.g.

Bar

4. Save the pages and export the page to PDF. The FOPException will be raised.

This happens for the following reason. PDF seems to be generated from a FO input generated by applying an XSL stylesheet to XHTML rendering of the wiki pages. In the previous example, the FO input gets a <fo:block id="Foo-Bar" ...>...</fo:block> element for the Foo-Bar page created above. Unfortunately, another <fo:block id="Foo-Bar" ...>...</fo:block> element is later generated when transforming the page Foo.

Wiki markup h2 seems to get rendered as XHTML element <h2 id="$PAGE_NAME-$CONTENT_AFTER_H2_DOT">$CONTENT_AFTER_H2_DOT</h2>, i.e. <h2 id="Foo-Bar">Bar</h2> in our example. When xhtml2fo.xsl is used to generate FO content from this snippet of XHTML, apparently at lines 609-613, any value of id attributes in the XHTML (maybe not any id attribute, but id attributes of XHTML heading elemets at least) are set as the value of the id attribute of the corresponding <fo:block/> element. Thus conflicting <fo:block id="Foo-Bar" ...>...</fo:block> results in the generated FO document when <h2 id="Foo-Bar">Bar</h2> element is transformed from XHTML to FO.

How to overcome this bug? When rendering wiki markup to XHTML, perhaps another character than a dash could be used as a delimiter between page name and local content when generating id attributes for various XHTML elements. I don't know if it's possible to choose such a character which is valid in XHTML attributes but invalid in user-supplied page names, though. Or perhaps the XSL stylesheet could be modified to append some string dependent on the local context to the value of generated id attribute of <fo:block/> elements resulting in unique id's among the FO document instead of blindly copying the value of id attribute of supplied input element, which may not (and need not) be unique among the input document. Or better yet, convert the XSL stylesheet to use strings obtained with generate-id() function described in http://www.w3.org/TR/xslt11/#misc-func as value to id attributes of <fo:block/> elements, if possible.