[Win32] Inkscape cannot find its resources (e.g. icons) when run from an Unicode directory

[Doriel]

Have made a Screenshot
http://iloapp.doriel-design.de/data/_gallery/public/8/1263033859_resized.jpg?width=800&height=640
I have installed the newest stabil Version 0.47-3 and tried Inkscape Portable too. It was always the same.
My friend has installed it on Windows 7 and has the same Problem (me use XP). The tools still working, i just can't see what I'm using.
One Preversion of 0.46 works fine.

[Krzysztof Kosinski (tweenk)]

1. Where have you installed Inkscape?
2. Is the file icons.svg present in Inkscape's installation directory?

[Doriel (yui-ichito)]

1. On my Windows partition
2. yes, it is.

[Krzysztof Kosinski (tweenk)]

Sorry, I wasn't specific enough. Please tell me the full directory where you have installed Inkscape.

[Doriel (yui-ichito)]

C:\Winpgms\Bürosoftware\Grafik\Inkscape

do you mean this?

[Erick (erick-fauquette)]

Installation directory : C:\Program Files\Inkscape

icons.svg exists in directory :C:\Program Files\Inkscape\share\icons

[avbushuev (avbushuev-yandex-deactivatedaccount)]

I have the same problem like Doriel and the directory where I've unpacked Inkscape is D:\Distrib\Архивы\Inkscape.

[avbushuev (avbushuev-yandex-deactivatedaccount)]

If nobody understands what I've written I try to explane. I don't install Inkscape on my computer. I use only archived (portable) version which doesn't need to install.

[Krzysztof Kosinski (tweenk)]

I found the cause: the problem is the usage of SetCurrentDirectory in main.cpp. ANSI functions are used instead of Unicode functions, and there are no conversions between UTF-16 used by Windows and UTF-8 used by Glib.

[Jon A. Cruz (jon-joncruz)]

Anyone who is looking at / working in this area probably should keep in mind one thing about Inkscape resource paths. Originally things were implemented such that macros hardcoding a location and assuming a single file would only ever be in a single location.

We've been cleaning up and getting to a proper approach where resources are searched for in a set of multiple possible locations. We just want to be sure any Win32 code does not move backwards in this regard.

Thanks.

[Krzysztof Kosinski (tweenk)]

I fixed resource lookup, but Python extensions still fail with a spawn error. I have no idea why this happens, since everything is in UTF-8, and g_spawn_* takes UTF-8 argv.

[Krzysztof Kosinski (tweenk)]

Maybe if I make the path to the script relative to the current directory, so that i doesn't contain any Unicode charaters, it will work correctly; e.g. Instead of
python "c:\bad folder ąół\Inkscape\share\extensions\some_ext.py"
I could call
python share\extensions\some_ext.py

Right now the absolute path to the script is always resolved and used.

[Erick (erick-fauquette)]

Always the same problem with release : inkscapeR9232-1003252225.7z
Regards

[Krzysztof Kosinski (tweenk)]

I made some progress: Python now spawns successfully. It turns out that the Windows _wspanvp function that Glib uses is broken and doesn't work when PATH contains Unicode directories. The remaining issue is that Python bombs when passed an Unicode filename. :/ It should be fixable by making the filename relative to the working directory.

[Krzysztof Kosinski (tweenk)]

SUCCESS against all odds!!!

Python cannot handle Unicode paths. If it's run from an Unicode directory, it will fail to find any modules in that directory. To make it work, I had to:
1. Use short paths in PYTHONPATH.
2. Run Python in the extensions directory, using its short path in the call to g_spawn.

I will commit this once I clean it up a bit and ensure that all extensions work.

[Krzysztof Kosinski (tweenk)]

Fixed in revision 9248.

[su_v (suv-lp)]

Inkscape 0.47+devel r9249 on OS X 10.5.8

Regression: Extensions installed in '~/.config/inkscape/extensions' no longer can find the modules in the system extension directory (e.g. 'inkex.py'). This worked without problems in previous revisions - without explicitly adding the path in the python script.

[su_v (suv-lp)]

(see bug #197475 “inkex.py not found for extensions in ~/.inkscape” which was fixed in 0.47)

[Krzysztof Kosinski (tweenk)]

The regression should be fixed in 9251.

[su_v (suv-lp)]

Inkscape 0.47+devel r9251 on OS X 10.5.8

Not fixed: extensions in user's directory still fail to load modules (e.g. inkex.py) from the inkscape extension directory.

When built to be packaged as osx application (configure option --enable-osxapp) the location of the shared extension directory may vary, but it is not '/usr/share/inkscape/extensions'.

[Erick (erick-fauquette)]

On windows, no improvement with release "Inkscape 0.47+devel r9247"
Regards

[Erick (erick-fauquette)]

On windows, why some icons are visible ? (New document, open, Save, Print,Copy,Cut,Paste,Preferences, Document preferences).
Regards

[ScislaC (scislac)]

All of Krzysztof's most recent commits were in 9248 forward... please be patient for another nightly build.

[su_v (suv-lp)]

@Krzysztof - can't you move all of the changes you made for win32 into '#ifdef WIN32' sections so that they are not seen when building on other platforms?

This regression (not fixed in r9252) has broken all extensions I install into '~/.config/inkscape/extensions' for testing purposes; manually adding several search paths to each python script and managing those is no option on Mac OS X because the application package is self-contained and relocatable, and there may well be several versions installed which include their own set of shared resources.

[Krzysztof Kosinski (tweenk)]

> @Krzysztof - can't you move all of the changes you made for win32 into
> '#ifdef WIN32' sections so that they are not seen when building on other
> platforms?

I did just that. Otherwise you would get build failures.

> This regression (not fixed in r9252) has broken all extensions I install
> into '~/.config/inkscape/extensions' for testing purposes;

Try 9257, I noticed a slight functional difference between my code and
what was there previously and it might be that Python doesn't like it
when the last character in PYTHONPATH is a searchpath separator.

[su_v (suv-lp)]

regression not fixed with Inkscape 0.47+devel r9257 on OS X 10.5.8

> I did just that. Otherwise you would get build failures.
Then why was code to set PYTHONPATH on other platforms changed (broken?) when fixing a win32 issue?

How can I help to debug this issue? Did you test it on Linux with an extension that doesn't explicitly add the path to 'share/extensions' in the python script?

[su_v (suv-lp)]

new bug #551433 “inkex.py not found for extensions in user's directory (regression)” filed to separate the discussion about PYTHONPATH from this report about (icon) resources not found on win32 platforms.

[Erick (erick-fauquette)]

On windows, no improvement with release "inkscapeR9322-1004132210"
Regards

[Krzysztof Kosinski (tweenk)]

Erick:
1. What is your Inkscape installation directory?
2. Are you sure you are running the file you've unpacked, rather than the old version? You need to double-click inkscape.exe unpacked from the downloaded file, rather than open it from the Start menu or by opening an SVG.
3. Can you capture the console messages by running the file inkscape.com?

[Erick (erick-fauquette)]

To be sure, I destroy the directory "C:\Program Files\inkscape" and unpack again the files.
Now everything is OK.
It seems to be a good recommendation to empty the directory before unpacking a new release, to avoid conflicts...
Thanks.
Regards.

[jazzynico (jazzynico)]

@Krzysztof - Apparently, the fix committed revision 9248 introduced a regression in the way the paths are set in the registry (see Bug #644185 "Inkscape mangles win32 registry keys..."). Could you please take a look?