WinXP2: Command line file names not current dir relative

[Edavies]

Relative file names put on the command line for the
Windows (XP SP2) version of Inkscape are taken to be
relative to the Inkscape installation directory rather
than the current directory.

The name of the file to be opened has to be fully
qualified otherwise it's not found. If the name of the
file for the --export-png option does not have any
directory specification then the exported file is put
in the Inkscape directory (e.g., C:\Program
Files\Inkscape 0.43) rather than the current directory.

This is a right pain if you want to create a make file
which is portable across multiple systems.

This problem doesn't seem to apply on Linux (Ubuntu)
where the current directory is used correctly.

[Johan Engelen (johanengelen)]

Originator: NO

See also [ 1603604 ].
Added to to-do list.

[theAdib (theadib)]

this might be fixed pls doublecheck with SVN

[Rygle (rygle)]

This seems to have been reported against Inkscape 0.43, and was put on Johan's list a long time ago.

Is this still a problem with 0.46? Johan? Edavies?

Assigned to me and I will close this if I don't hear back soon.

[Edavies (edavies)]

Yes, this problem still exists in 0.46.

That's with the Windows version available on Sourceforge which I downloaded within the last hour or so. March 10th I think it said there.

Attached is text from screen showing running Inkscape through a trivial batch file. "happy.svg" doesn't work but "c:\temp\happy.svg" does.

[Rygle (rygle)]

Changing to confirmed. Milestoning for 0.47. Johan, have you made any progress on this?

Edavies test case is as follows;
===========
C:\Temp>type c:\bin\inkscape.bat
"C:\Program Files\Inkscape 0.46\inkscape.exe" %1 %2 %3 %4 %5
C:\Temp>inkscape happy.svg

C:\Temp>"C:\Program Files\Inkscape 0.46\inkscape.exe" happy.svg

C:\Temp>inkscape c:\temp\happy.svg

C:\Temp>"C:\Program Files\Inkscape 0.46\inkscape.exe" c:\temp\happy.svg

C:\Temp>
===========================

[Krzysztof Kosinski (tweenk)]

This is the relevant snippet of code from main() in main.cpp. What should be done instead is that _win32_getExePath should be called whenever a resource is requested. This isn't a trivial change since it requires refctoring how Inkscape's datafiles are accessed.

#ifdef WIN32
    /*
      Set the current directory to the directory of the
      executable. This seems redundant, but is needed for
      when inkscape.exe is executed from another directory.
      We use relative paths on win32.
      HKCR\svgfile\shell\open\command is a good example
    */
    Glib::ustring homedir = _win32_getExePath();
    SetCurrentDirectory(homedir.c_str());
    _win32_set_inkscape_env(homedir);
    RegistryTool rt;
    rt.setPathInfo();
#endif

[Chris Morgan (chris.morgan)]

Another way it could be done (I'd been thinking of doing it for my PortableApps.com applications, especially Inkscape incidentally) is by just analysing the command line, and seeing if it's a file which exists. If it is, use the shlwapi.dll PathCombine DLL call (there may be a better way of doing it, but I doubt it). I believe that PathCombine will work even if it's an absolute path, but if not you'd need to do something like, does it start with \\ or is the second character : or something like that.

That'd be simpler than changing all the resource request lines.

[Krzysztof Kosinski (tweenk)]

Chris Morgan: this would still be an ugly hack. We need to reduce the number of hacks in Inkscape, because we already at the brink of collapse into unmaintainability. All that needs to be done is to modify the profile_path function.

[Krzysztof Kosinski (tweenk)]

This should be fixed in 9281. You can type "inkscape tiger.svgz --export-png=tiger.png" with Inkscape's directory added to your PATH and it will behave just like on Unix.

profile_path is about user configuration rather than Inkscape's datafiles, so it wasn't relevant to this bug - sorry if this caused any confusion.