On 22 January 2011 03:24, Tim Mertens <[email protected]> wrote: > One more update: > > I rolled back to the original configuration (using just "../include" > for the path to the include directory) with a space in the parent > directory/path to the asciidoc documents. > > It appears that the build failure is probably occurring in xsltproc or > dblatex. I noticed a couple of things: > > First, when dblatex calls xsltproc, in each call it includes a string > to the docbook xml which is not enclosed in quotes. For example: > > Build the book set list... > xsltproc -o /path/to/tmp/directory/doclist.txt --xinclude -- > xincludestyle doclist.xsl ~/Desktop/Documentation 2011-1/FirstDocument/ > FirstDocument.xml > > ^Note the lack of quotes around the last path passed to xsltproc. > However, I also noted that xsltproc succeeds in being executed so I'm > not certain that the above is in fact a problem. If I try to execute > xsltproc from the terminal with this same syntax, it fails, so perhaps > dblatex is calling it slightly differently than it shows in the logged > output.
I suspect it execs it and doesn't use a shell, so args are already broken up and spaces don't matter. > > Second, I found that in the FirstDocument.tex file that was generated > somewhere during this whole process, the references to the images are > _NOT_ expanded. So Asciidoc itself is not expanding the file paths to > their full path names. > > Additionally, in the XSLT/Latex output, it does not report these > images as 'not found' unless they are in fact missing, so it seems to > me that most likely the issue is somewhere in the very end of the tool > chain when the images are actually accessed to output the PDF: > > XSLT stylesheets DocBook - LaTeX 2e (0.3) > ================================================= > Image 'images/preferences_001.png' not found > Image '../include/another_image_001.png' not found > > ^In the above example output, the files listed in fact do not exist on > the file system; however, other included files in the "../include/" > and "images/" paths do not appear in this 'not found' list of files, > indicating that the files are in fact found at this step in the export > process, so the failure is most likely somewhere after this message is > logged. > > > PDF output succeeds; however, the ../include files are not included in > the exported PDF - only the text for the relative paths to their > locations are printed. > > Also, I confirmed that this issue does not occur if I use FOP for PDF > output. > > > Lex, do you have any more suggestions? It definitely looks like there > is a major problem somewhere toward the end of the tool chain hosing > things up. Your detective work looks impressive, unfortunately I'm no expert on this end of the chain so I can't suggest much, especially as FOP worked, that implies the docbook is ok. Just a couple of questions, do relative paths work with/without spaces, and do absolute paths work with/without spaces. Cheers Lex > > Thanks, > -Tim > > > On Jan 21, 9:47 am, Tim Mertens <[email protected]> wrote: >> Hi Lex, >> >> I have now encoded the image include path I am using as an asciidoc >> attribute so that ' ' becomes '%20', but this causes xsltproc to fail >> to find _any_ of the included image files. So it seems that xsltproc >> expects actual spaces to locate the files, not %20. >> >> I also end up with a fatal error message from pdflatex: >> >> MyFileName.tex: File ended while scanning use of \imgexists. >> MyFileName.tex: Emergency stop. >> Unexpected error occurred. >> >> Thanks, >> -Tim >> >> On Jan 20, 5:14 pm, Lex Trotman <[email protected]> wrote: >> >> > On 21 January 2011 09:29, Tim Mertens <[email protected]> wrote: >> >> > > I found, after a fair amount of investigation, that images fail to >> > > export in the PDF output if a relative path is used which must ascend >> > > a directory "../", if the parent path to the folder containing the >> > > Asciidoc document contains a space. >> >> > > For example, let's say my directory structure looks like this (the ~/ >> > > abbreviation used for simplicity): >> >> > > ~/Desktop/Documentation 2011-1/FirstDocument/asciidoc.conf >> > > ~/Desktop/Documentation 2011-1/FirstDocument/FirstDocument.txt >> > > ~/Desktop/Documentation 2011-1/FirstDocument/images/customimage.png >> > > ~/Desktop/Documentation 2011-1/Another_Document/asciidoc.conf >> > > ~/Desktop/Documentation 2011-1/Another_Document/Another_Document.txt >> > > ~/Desktop/Documentation 2011-1/Another_Document/images/ >> > > custom_image.png >> > > ~/Desktop/Documentation 2011-1/include/Some_Include_File.txt >> > > ~/Desktop/Documentation 2011-1/include/Some_Images/Shared_Image.png >> > > ~/Desktop/Documentation 2011-1/include/More_Images/Shared_Image2.png >> >> > > So you can see there are at least two separate Asciidoc documents, >> > > each of which will be rendered to a separate PDF file on output. Each >> > > asciidoc document (I will call them "Projects") has its own >> > > 'asciidoc.conf' in the directory of the main asciidoc text file, and >> > > it's own images directory for images used only by that individual >> > > Project. However, the projects share some asciidoc documents as well >> > > as images, which end up in the "../include" directory, relative to the >> > > asciidoc file. >> >> > > So to make things simple in the "asciidoc.conf" for each project I >> > > have a variable that I set to the include path: >> >> > > :include-dir: ../include/ >> >> > > Which then also gets pre-pended to the directory for images references >> > > in an included asciidoc text file. For example, in ../include/ >> > > Some_Include_File.txt, I would set: >> >> > > :someimages-dir: {include-dir}SomeImages/ >> >> > > Which then in turn is prepended to the image: >> >> > > image::{someimages-dir}Shared_Image.png[] >> >> > > This worked perfectly until we tried implementing this into our build >> > > system which is not entirely under my control. Keep in mind, this was >> > > at first used without spaces in any of the paths. So "Documentation >> > > 2011-1" would be "Documentation" or "Documentation2011-1". >> >> > > Long story short, there ended up being spaces in the directory path >> > > containing the asciidoc files, similar to the file list shown above >> > > "Documentation 2011-1". After introducing the spaces to the path - >> > > even though the folder/path containing the spaces is a parent >> > > directory and is not actually referenced anywhere in the asciidoc >> > > documents, this resulted in all of the "../include" image files to >> > > fail to appear in the exported PDF document. >> >> > > Images included directly underneath the main project directory showed >> > > up fine, for example: >> > > image::images/customimage.png[] >> >> > > ...but everything that was referenced using "../include/" only >> > > displayed the path to the file as text in the PDF output. >> >> > > After some research, we discovered the spaces in the parent path were >> > > to blame; however, since I have little control over this I ended up >> > > instead passing the full path to the files as an asciidoc variable in >> > > the script I use to build the documentation: >> >> > > #################################### >> > > #!/bin/bash >> > > cd "`dirname "$0"`" >> > > CURRENTDIR=`pwd` >> > > # Some other code... >> > > a2x -v -f pdf --asciidoc-opts="--attribute=include-dir=\"$CURRENTDIR/ >> > > include/\"" "FirstDocument/FirstDocument.txt" >> > > #################################### >> >> > > This resulted in the image:: tags containing the full path to be no >> > > longer recognized (as described in my previous post) and later after >> > > resolving _that_ issue, it caused PDF output to fail if the source >> > > image did not exist at the target location, warranting yet another >> > > workaround. >> >> > > With the other assorted fixes and workarounds I've found, I've more or >> > > less patched up the issues on my end at least for now, but it would be >> > > nice to see a fix to this problem (I'm not sure how this specific >> > > problem is caused) so that if the parent directory contains spaces and >> > > you use a relative path to a file, it still appears in the pdf >> > > output. This seems like a pretty significant issue because it is not >> > > at all uncommon for file paths to contain spaces, and this was an >> > > extremely elusive issue to track down because there was nothing >> > > useful, as i can recall, logged in the a2x output with the -v flag. >> > > We only discovered the actual cause on a hunch. >> >> > > Thanks! >> > > -Tim >> >> > Hi again Tim, >> >> > I don't think the "problem" is in Asciidoc or dblatex or any other >> > tool, its in the definition of XML and specifically docbook. The >> > image tag takes a URL, but URLs are defined to not contain spaces, >> > they need to be encoded, thats why the %20 works. Your substitution >> > eventually expands somewhere to an absolute path with spaces in it, >> > illegal for a URL. >> >> > If the expansion takes place in Asciidoc it might be possible to have >> > all illegal characters encoded before the URL is output, but Stuart >> > would have to check that this isn't going to break existing documents >> > that already are encoded (I suspect it will). If the expansion takes >> > place in one of the later tools then Asciidoc may not be able to help. >> >> > Probably best if you substituted encoded absolute paths in your build. >> > Maybe use a teeny Python script that uses os.path.abspath() and >> > urllib.quote() >> >> > Cheers >> > Lex >> >> > > -- >> > > You received this message because you are subscribed to the Google >> > > Groups "asciidoc" group. >> > > To post to this group, send email to [email protected]. >> > > To unsubscribe from this group, send email to >> > > [email protected]. >> > > For more options, visit this group >> > > athttp://groups.google.com/group/asciidoc?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/asciidoc?hl=en. > > -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
