RE: [docbook-apps] Cannot resolve imagedata element's fileref attribute using 
modular docbook and XIncludeI'm not familiar enough with dblatex to tell you 
how to proceed.  Can dblatex run a customization layer?  If so, you could try 
putting the @fileref template in that, which should trigger the resolution of 
xml:base attributes for filerefs.  That assumes that the rest of the code is 
compatible, since several utility templates are called upon to resolve path 
information.

Bob Stayton
Sagehill Enterprises
[email protected]


  ----- Original Message ----- 
  From: Michael Erickson 
  To: Bob Stayton ; [email protected] ; 
[email protected] 
  Sent: Wednesday, October 14, 2009 11:10 AM
  Subject: RE: [docbook-apps] Cannot resolve imagedata element's fileref 
attribute using modular docbook and XInclude


  Bob,

  Thank you *very* much for the reply.  There appears to be a difference 
between the way graphics are handled between DbLaTeX and DocBook XSL.

  I compared /usr/share/xml/docbook/stylesheet/dblatex/xsl/graphic.xsl and 
/usr/share/xml/docbook/stylesheet/nwalsh/fo/graphics.xsl.  The dblatex version 
does not contain <xsl:template match="@fileref">.

  The other templates you mention appear to be the same.

  So, now that we've (possibly) found the issue, what do you think would be the 
best way to proceed?  I don't want to start "hacking" on the dblatex 
stylesheets without some understanding about what I'm doing.  Is there an easy 
way to simply include the DocBook XSL Stylesheet fo/graphics.xsl in the dblatex 
one?

  Alternatively, is there an "DocBook-to-DocBook" transformation that I could 
pass to xsltproc which would resolve xml:base attributes - which I could then 
pass to dblatex?

  Something like:

  $ xsltproc -o tmp.xml fixup.xsl book.xml
  $ # tmp.xml now has all of the paths in attributes correct

  $ dblatex tmp.xml

  I've been looking for something like the above, but haven't found anything 
yet.

  The closest I've gotten is using xmllint to verify the document.  When I view 
the output of that, I can see xml:base added to sections and other elements, 
but not the fileref attributes.




  --
  Michael Erickson
  Director Software Products
  LOGIC
  (612) 436-5118 : desk
  (612) 384-1584 : cell
  http://www.logicpd.com



  -----Original Message-----
  From: Bob Stayton [mailto:[email protected]]
  Sent: Wed 10/14/2009 12:41 PM
  To: Michael Erickson; [email protected]; 
[email protected]
  Subject: Re: [docbook-apps] Cannot resolve imagedata element's fileref 
attribute using modular docbook and XInclude

  Hi Michael,
  Do you know if dblatex knows how to resolve xml:base attributes?  If not, 
then that is where it is going wrong. 

  When XInclude pulls in content from another directory, the XInclude processor 
inserts an xml:base attribute indicating the new directory.  That sort of 
stores a "change-of-directory" in the resolved XML content, so that relative 
paths (like yours) in the included content can be resolved downstream.  When 
the DocBook XSL stylesheets encounter a relative path in a fileref, they look 
for xml:base attributes and reconstruct any fileref path to resolve any 
xml:base attributes from all its ancestor elements.  If dblatex does not do 
that xml:base resolution, then the filerefs are passed through without change 
and lack the directory fixups.

  The relevant templates in DocBook XSL include:

  in fo/graphics.xsl:
    <xsl:template match="@fileref">

  in common/common.xsl:
    <xsl:template name="relative-uri">
    <xsl:template name="xml.base.dirs">

  Bob Stayton
  Sagehill Enterprises
  [email protected]



          ----- Original Message -----
          From: Michael Erickson <mailto:[email protected]> 
          To: [email protected] ; [email protected]
          Sent: Wednesday, October 14, 2009 9:42 AM
          Subject: [docbook-apps] Cannot resolve imagedata element's fileref 
attribute using modular docbook and XInclude


          Hello all,
         
          I've posted the question below on the DbLaTeX mailing list, but I 
have a suspicion that my problem might be solved if I had a better 
understanding of XSL, XInclude, and using xsltproc.
         
          I would greatly appreciate any advice you might provide.
         
          Basic information:
          ------------------
          * Debian 5.0 "Lenny" host machine, all packages up-to-date
          * Validating against DocBook XML V4.5 DTD
          * dblatex version 0.2.9-3
          * $ latex --version
          pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6)
          kpathsea version 3.5.6
              ...
          Compiled with libpng 1.2.27; using libpng 1.2.27
          Compiled with zlib 1.2.3.3; using zlib 1.2.3.3
          Compiled with libpoppler version 3.00
         
          * $ xsltproc --version
          Using libxml 20632, libxslt 10124 and libexslt 813
          xsltproc was compiled against libxml 20632, libxslt 10124 and 
libexslt 813
          libxslt 10124 was compiled against libxml 20632
          libexslt 813 was compiled against libxml 20632
         
         
          Problem:
          --------
          I'm having trouble getting dblatex to locate images.  I believe that 
the trouble lies someplace with xsltproc not expanding the "fileref" attribute 
using xml:path.  WARNING, I am *not* an XML or DocBook expert, so you should 
take any of my suspicions with a large grain of salt - and you may feel free to 
laugh should I say something that makes no sense :-)
         
          My directory structure looks like:
         
          book/
          ____| main.xml
          ____| appendix/
          ______________|appendix.xml
          ______________| foo/
          ___________________| foo.xml
          ___________________| images/
          ___________________________|*.png
         
          Book/main.xml uses XInclude to insert book/appendix/appendix.xml, 
which in turn uses XInclude to insert book/appendix/foo/foo.xml.  
Book/appendix/foo/foo.xml contains elements such as:
         
          <mediaobject>
            <imageobject>
              <imagedata fileref="images/image_1.png" format="PNG" />
            </imageobject>
          </mediaobject>
         
          If I enter the book/appendix/foo/ directory and execute:
              $ dblatex foo.xml
          I have no problems.  Foo.pdf is created, and includes the images I 
expect it to.
         
          If I am anywhere above the "foo" directory, dblatex reports "Image 
'images/image_1.png' not found" and the resultant PDF file does not include the 
images.
         
          What I've Tried:
          ----------------
          I can sucessfully use xsltproc to create HTML and "chunked" HTML 
files, as long as I pass the following parameters to it:
         
            --xinclude
            --param keep.relative.image.uris 0
         
          I've reviewed the XSL Parameters section (5.1) of the DocBook to 
LaTeX Publishing User Manual for something similar to 
"keep.relative.image.uris", but have been unsuccesfull.
         
          I've searched and grep'ed through the 
/usr/share/xml/docbook/stylesheet/dblatex files - but didn't see anything that 
jumped out at me (admittedly, they are out of my comfort zone).
         
          I've looked into trying to use xmllint or xlstproc to generate an 
intermediate XML file with completely resovled path names, so I could pipe that 
to dblatex, but haven't had any luck coming up with the proper XSL file or 
parameter combination.
         
          I've tried using the "-I" option to point dblatex at additional 
directories to search for "figures."  I also wrapped some of the <mediaobject> 
elements in figures - but that didn't seem to make a difference.
         
          I *have* confirmed that setting the fileref attribute to an absolute 
pathname *does* work.
         
          I've googled a ton and reviewed the dblatex mailing list on 
SourceForge.  Since I've come up empty, and I can't believe that nobody else 
has ever structured a document the why I have, my intuition tells me that I am 
missing something completely obvious.
         
          Can anyone help me understand what is happening and how to fix it?
         
          Best regards,
          --mike
         
          --
          Michael Erickson
          Director Software Products
          LOGIC
          (612) 436-5118 : desk
          (612) 384-1584 : cell
          http://www.logicpd.com
         
         
         



Reply via email to