OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook] XSLT/FO issue -- id "x" already exists in this document

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 


--- 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 @@

   <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:when test="$deflabel = 'none'">


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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]