This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: [docbook] XSLT/FO issue -- id "x" already exists in this document
- From: Alex Russell <alex at netWindows dot org>
- To: M Flood <mdflood at starpower dot net>,docbook at lists dot oasis-open dot org
- Date: Tue, 30 Sep 2003 16:03:54 -0500
- Subject: Re: [docbook] XSLT/FO issue -- id "x" already exists in this document
- Organization: netWindows.org
- References: <3F79D27B.9000306@starpower.net>
On Tuesday 30 September 2003 13:59, M Flood wrote:
> Greetings:
>
> This is an issue that appears to have been addressed in the past, but
> which I am now seeing for the first time.
>
> I have a substantial Docbook file, which is converted via xsltproc to
> both HTML and PDF. I am having the
> same problem with both docbook-xsl-1.62.0 and 1.62.4. The Docbook
> conversion to HTML goes fine.
>
> In the conversion to PDF, though, the conversion to FO works fine, but
> the mapping from FO to PDF produces:
>
> [ERROR] file: ... id "id2908630" already exists in this document
>
> From ealier discussions in the list archives, it sounds like a similar
> problem was addressed already -- so now perhaps it
> has regressed. In my case, the trouble seems to be caused by a lengthy
> (49 items) list of qandaentries. Does this
> sound like a bug? How much work is it to patch the stylesheets?
Patching the stylesheet is fairly straightforward. Here's the diff from my
environment:
---------------
--- fo/qandaset.xsl Mon Sep 29 21:50:25 2003
+++ fo/qandaset.xsl.orig Tue Sep 30 15:42:27 2003
@@ -200,9 +200,7 @@
</xsl:variable>
<fo:list-item xsl:use-attribute-sets="list.item.spacing">
- <!-- FIXME: this (somehow) seems to create dupe entries, breaking FOP -->
- <!-- <fo:list-item-label id="{$id}" end-indent="label-end()"> -->
- <fo:list-item-label end-indent="label-end()">
+ <fo:list-item-label id="{$id}" end-indent="label-end()">
<xsl:choose>
<xsl:when test="$deflabel = 'none'">
<fo:block/>
---------------
Note that this isn't a smart fix. It just removes the ID, which arguably
should be made unique in the calling style by some other means (prepending
some identifier, etc...).
IIRC, the on-list resolution to date was along the lines of "well, your parser
should be able to handle that, it's broken", so I'm not sure how much
sympathy such a patch will get.
Regards.
--
Alex Russell
alex@burstlib.net BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
alex@netWindows.org F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
To unsubscribe from this list, send a post to docbook-unsubscribe@lists.oasis-open.org.