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