I set up a similar scenario:
test dir/test2/article.txt
test dir/images/tiger.png
The generated DocBook is both valid and as expected and does not reference the
"test dir" (also as expected) e.g.
<imagedata fileref="../images/tiger.png"/>
dblatex 0.3 generates a PDF without errors but the images are missing (as
reported). FOP does not suffer from this problem.
So the problem appears to lie with dblatex (another corroboration of my previous
comment on the subject of spaces in paths
http://groups.google.com/group/asciidoc/browse_thread/thread/74da1c249667a2ad).
Cheers, Stuart
On 21/01/11 11:29, Tim Mertens 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
--
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.
