Re: [docbook-apps] FW: [[1454121] Path dirs repeated twice in imagedata urls]

["Bob Stayton" <bobs@sagehill.net>]

Yes, I've seen this problem before.  It usually happens when the 
xml:base attributes added by the XInclude processor are not 
correct.  That is, the xml:base attributes should be taken as 
relative to the containing element.  But XInclude processors seem 
to have a problem always getting them correct for all 
combinations of directory layouts and nested XIncludes.  I 
personally reported two instances of such problems in libxml2, 
with the most recent bug being fixed last year.

This is best diagnosed by running an identity stylesheet using 
the XInclude processor and examining the xml:base attributes that 
it adds.  If you keep track of the contexts and the nesting, you 
can usually figure out if the xml:base attributes are not 
correct.

The other possibility is that the consolidation of xml:base 
attributes done by the DocBook stylesheets has a bug.  But since 
it worked for xsltproc, I suspect it is the Xerces XInclude 
processor that has the bug.  If so, you may have to switch to two 
step processing, using xmllint --xinclude to resolve the 
XIncludes and then your regular process to apply the stylesheet.

Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net


----- Original Message ----- 
From: "Michael(tm) Smith" <smith@sideshowbarker.net>
To: <docbook-apps@lists.oasis-open.org>
Sent: Sunday, March 19, 2006 7:45 PM
Subject: [docbook-apps] FW: [[1454121] Path dirs repeated twice 
in imagedata urls]


Forwarding a message I got from Mark Proctor (who's been trying 
to
get a working environment set up to author and publish docs for
Drools [JBoss Rules product] using DocBook).

Has anybody ever come across this problem before? (parts of path
names getting repeated in URIs).

It seems like it might be caused by a problem in the Xerces
XIncludeParserConfiguration class. He's using that to do
single-pass resolving of his XIncludes along with the
transformation to XSL-FO. With Saxon as the XSLT engine.

But if I run his source through an Xinclude processer (I'm using
xmlllint --xinclude) to resolve the Xinclude instances first, and
then pass on that result to Saxon, everygthing works as expected
(no parts of the path names get repeated).

  --Mike

----- Forwarded message from Mark Proctor 
<mproctor@codehaus.org> -----

Date: Mon, 20 Mar 2006 03:25:11 +0000
From: Mark Proctor <mproctor@codehaus.org>
User-Agent: Thunderbird 1.5 (Windows/20051201)
To: smith@sideshowbarker.net
Subject: [1454121] Path dirs repeated twice in imagedata urls

   I have been trying to generate pdfs with the latest snapshot. 
I'm finding
   that it messes up the path of the generated .fo - even before 
I try
   rendering a pdf with fob.
   I have imagedata="A Basic Rete Network.gif" and it ends up 
with
   <fo:external-graphic
   src="Part%20-%201/Part%20-%201/Chapter%20-%20Rule%20Engine/Chapter%20-%20Rule%20Engine/A%20Basic%20Rete%20Network.gif"
   Notice that it repeats each folder twice  - its also wrong 
because the
   image should be relative to the current dir - i.e. 
<fo:external-graphic
   src="A%20Basic%20Rete%20Network.gif"

   I have this error whether I'm using src.image.path or not.

   The document itself a modular docbook, three levels deep - the 
image is at
   the third level. HTML generates fine. I have no joy with pdf 
or html if I
   go back to 1.69.1

   [1]http://sourceforge.net/tracker/index.php?func=detail&aid=1454121&group_id=21935&atid=373747

   Mark

----- End forwarded message -----