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.
