command-line usage (--export-pdf) fails with absolute paths in cygwin notation

Bug #726875 reported by Um What
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Confirmed
Low
Unassigned

Bug Description

Console (command-line) use of inkscape.exe to export pdf/ps/etc fails with an absolute path on Win32 . This happens with SVG files from at least Visio and Dia. (I haven't checked other input formats of flavors of svg.)

I use Cygwin on XP, and I discovered this when using dblatex for converting DocBook5 XML to PDF (when dblatex sees an SVG file referenced in XML it calls inkscape using absolute paths).

My Cygwin environment is very complete and robust -- I do a lot of development, compiling, etc.

When I test inkscape alone it clearly succeeds on relative paths but fails on absolute paths.
(Note that if you want to try this yourself then you have to patch imagedata.py because it calls inkscape with in/out files mixed up -- see: http://sourceforge.net/tracker/index.php?func=detail&aid=3039592&group_id=72607&atid=535062)

I've tried your official/stable win32 installer v0.48, earlier v0.46, and nightly build 0.48+devel r10061 (Feb 21 2011). I also tried setting pythonpath, and other variables, and have made sure my shell knows which inkscape/python combo to use.

OSX version produces another error when I attempt the same test -- not sure if it's supposed to have a console mode. I didn't see a Linux binary, and since I don't have the time to compile it...

BTW, although I tried compiling the latest on win32, some of Cygwin's packages are a bit behind and well, ain't gonna happen:
configure: error: Package requirements (gdkmm-2.4 glibmm-2.4 giomm-2.4 gtkmm-2.4 >= 2.10.0 gtk+-2.0 libxml-2.0 >= 2.6.11 libxslt >= 1.0.15 cairo sigc++-2.0 >= 2.0.12 gthread-2.0 >= 2.0 libpng >= 1.2 gsl) were not met:
No package 'gdkmm-2.4' found
No package 'glibmm-2.4' found
No package 'giomm-2.4' found
No package 'gtkmm-2.4' found

So I won't be able to patch source and recompile, I just can't go down that road, but I'll be glad to test new versions.

Thanks for any help.

PS, I have far too many accounts on systems around the Net, and I prefer to subscribe/unsubscribe from lists when possible. I shouldn't have to create an account on Launchpad to report this bug!

/cygdrive/c/temp

$ inkscape -z -D --export-pdf=fig0.pdf testfile.svg (or dir/subdir/testfile.svg , or ../subdir/testfile.svg, etc)

$ ls -l fig0.pdf
-rwx------+ 1 jazing None 18858 Feb 25 12:50 fig0.pdf

$ rm fig0.pdf

$ inkscape -z -D --export-pdf=fig0.pdf /cygdrive/c/temp/testfile.svg

** (inkscape.exe:7632): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

** (inkscape.exe:7632): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

** (inkscape.exe:7632): WARNING **: Specified document /cygdrive/c/temp/approval.svg cannot be opened (does not exist or not a valid SVG file)

Tags: cli win32
su_v (suv-lp)
tags: added: cli win32
Revision history for this message
su_v (suv-lp) wrote :

Quoting from <http://article.gmane.org/gmane.comp.graphics.inkscape.user/7728>:
«Now that I got everything sorted out (thanks to all who replied!), I
figure I might as well post to the list how I automated Inkscape SVG
exporting under Windows+cygwin, perhaps it will save someone else some
time in the future. (…)

The first stumbling block was that inkscape requires full paths to the
original file and the destination file. The second stumbling block
was how to translate them for inkscape, which does not like cygwin's
/cygdrive/c/... notation.»

AFAIU full paths are no longer required with Inkscape 0.48 (at least when using formats supported by internal extensions; for script-based extensions possibly the regression reported in bug #695120 also applies to Windows builds).

Inkscape 0.48 has seen several changes with regard to the command line usage on Windows:
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48#Command_line_interface>

Revision history for this message
su_v (suv-lp) wrote :

> OSX version produces another error when I attempt the
> same test -- not sure if it's supposed to have a console mode.

With some limitations the bundled application can be used from the command line (always use absolute paths, for details see bug #181639), but the bundled osxapp version is indeed not intended to be used as command line app: install inkscape with MacPorts if it is primarily employed from within scripts or for command-line based export tasks.

su_v (suv-lp)
summary: - console export-pdf etc absolute paths not working
+ command-line usage (--export-pdf) fails with absolute paths in cygwin
+ notation
Revision history for this message
su_v (suv-lp) wrote :

> (…) which does not like cygwin's /cygdrive/c/... notation.»

According to <http://www.google.com/search?q=inkscape+cygpath> many scripts use 'cygpath' to generate filenames/paths for Inkscape in shell scripts launched in cygwin environments.

(Note: I'm not using Windows myself, my comments are just the result of spending a few minutes googling the issue).

Revision history for this message
su_v (suv-lp) wrote :

Setting bug status to 'Confirmed' because according to Google it seems to be a known issue when calling inkscape.exe from cygwin shell scripts. Bug importance set to 'Low' because workaround exists (use 'cygpath' [1] to convert from Cygwin POSIX-style paths to Windows native paths).

[1] <http://www.cygwin.com/cygwin-ug-net/using-utils.html#cygpath>

Changed in inkscape:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Um What (jazing+inkscape) wrote :

Thanks, but tho I'e tried I'm not able to wrap inkscape in a script. It's being called from a python script (see below) and I don't see how to rewrite it or wrap inkscape into a sh script, etc. I've tried a few things but to no avail.

.py script:
cmd = "inkscape -z -D \"--export-%s=%s\" %s" % (format, input, output)

Note, although I offered an example using /cygdrive/c/..., dblatex is passing the path "/cygdrive/c/Documents and Settings/myself/My Documents/..." , so in my test I tried to simplify the path as /cygdrive/c/temp/testfile.svg -- no spaces, backslashes, quotes, etc. Certainly inkscape should be able to handle this.

Unfortunately I don't think the workaround offered will not for me because inkscape is being called in a python script, and I don't see how to rewrite the script to wrap inkscape into cygpath. Also the path variable is set in a class somewhere outside the script, so modifying it will break other things.

Here's the tail of output from dblatext:
...
Stripping NS from DocBook 5/NG document.
Processing stripped document.
inkscape -z -D --export-pdf=fig0.pdf "/cygdrive/c/Documents and Settings/myself/My Documents/Manual/images/approval.svg"

** (inkscape.exe:4132): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

** (inkscape.exe:4132): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

** (inkscape.exe:4132): WARNING **: Specified document /cygdrive/c/Documents and Settings/myself/My Documents/Manual/images/approval.svg cannot be opened (does not exist or not a valid SVG file)
inkscape -z -D --export-pdf=fig1.pdf "/cygdrive/c/Documents and Settings/myself/My Documents/Manual/images/authentication.svg"

** (inkscape.exe:6956): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

** (inkscape.exe:6956): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

** (inkscape.exe:6956): WARNING **: Specified document /cygdrive/c/Documents and Settings/myself/My Documents/Manual/images/authentication.svg cannot be opened (does not exist or not a valid SVG file)
...
'manual.pdf' successfully built (of course, sans all svg images)

So, any idea why inkscape doesn't like the path?
Is there any chance this will be fixed in the near term or will this be a long time coming?
Is there a precompiled inkscape for Fedora?

Thanks.

Revision history for this message
su_v (suv-lp) wrote :

> to wrap inkscape into cygpath

Don't try to wrap inkscape.exe, AFAIU you need to convert the absolute paths for the _files_ using cygpath. There are numerous examples if you search google.

> So, any idea why inkscape doesn't like the path? Is there
> any chance this will be fixed in the near term or will this
> be a long time coming?

The Windows port of Inkscape apparently does not support the cywin path notation for files (but it handles the Windows native paths well). The bug report has been set to confirmed based on finding the workaround mentioned in various scripts, forum messages and web sites. Any further activity depends on whether a developer volunteers to further investigate, and whether it is doable within Inkscape's code or needs to be implemented upstream in one of the libraries used by Inkscape (Glib, GTK+, gtkmm, etc.).

> Is there a precompiled inkscape for Fedora?

AFAIK Inkscape is available in the official Fedora repositories. The Inkscape project itself currently does not provided binary packages for linux.

Revision history for this message
Um What (jazing+inkscape) wrote :

Just in case anyone else runs into this situation, here's a hack to dbtexmf/core/imagedata.py that lets cygpath convert the path from unix to windows-style, the way inkscape likes it :)

        import commands
        ...
        (ret, inkinput) = commands.getstatusoutput("cygpath -w \"%s\"" % str(input))
        (ret, inkoutput) = commands.getstatusoutput("cygpath -w \"%s\"" % str(output))
        cmd = "inkscape -z -D --export-%s=\"%s\" \"%s\"" % (format, inkoutput, inkinput)

Thank you for the tips!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.