Inkscape extensions do not work on MacOS X 10.6 (Snow Leopard)

[Ulf Adams]

After installing Inkscape 0.47 pre4, we found that extensions don't work and give the infamous lxml error message:

The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension. Please download and install the latest version from http://cheeseshop.python.org/pypi/lxml/, or install it through your package manager by a command like: sudo apt-get install python-lxml

Printing out the real exception, this was due to dlopen not working. I investigated a little bit, and it seems that lxml doesn't work with the python 2.6 shipped with Snow Leopard. The python 2.6 binary is a 'Mach-O fat file with 3 architectures', while the etree.so shipped with lxml is a 'Mach-O fat file with 2 architectures'. I suspect that the 2.6 binary is running with the x86_64 architecture, which isn't present in the etree.so library.

As a workaround, I symlinked /usr/bin/python to point to python 2.5 (which is a 'Mach-O fat file with 2 architectures'), and that makes the extensions work again.

I've seen a few other bug reports for extensions, but none of them seems to describe the exact problem we encountered. In particular, the workaround in bug #345176 does not work.

[su_v (suv-lp)]

Setting to 'Confirmed' as it has been reported repeatedly and is a known issue that is being worked on and hopefully will be resolved for the release version.

See also the related discussion in the comments of bug #421305 “Inkscape does not run on Mac OSX 10.6” [1] and a recent thread in inkscape-devel [2].

[1] <https://bugs.launchpad.net/inkscape/+bug/421305>
[2] <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31846>

[Ulf Adams (ulf-ofahrt)]

Let me know if there's anything I can do to help.

[su_v (suv-lp)]

there have been two further workarounds reported in this InkscapeForum topic:
<http://www.inkscapeforum.com/viewtopic.php?f=29&t=3588>

A) change the default python version back to Python 2.5

terminal command:
  defaults write /Library/Preferences/com.apple.versioner.python Version 2.5

references:
<http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/python.1.html>

B) compiling from source:

Packages downloaded:
- lxml-2.2.4.tar.gz
- numpy-1.3.0.tar.gz

Python version used:
$ which python
/usr/bin/python
$ python --version
Python 2.6.1
$ lipo -info /usr/bin/python
Architectures in the fat file: /usr/bin/python are: x86_64 i386 ppc7400

references:
<http://wiki.inkscape.org/wiki/index.php/GettingEffectsWorking#Compiling_from_source>

[Alexey (alexey-muranov)]

I have just removed MacPorts, and extensions in Inkscape 47 on Snow Leopard 10.6.2 started working, except textext, which asks for pdf2svg. I am now trying to install again pdf2svg with MacPorts to see what happens. But it now installs python 2.6.4 as a dependency, so there may be problems, i guess...

[Alexey (alexey-muranov)]

After having installed pdf2svg with MacPorts, extensions, including textext, were working, but i have not done yet
sudo port install python_select, sudo python_select python26
(running python from command line would start Apple's python 2.6.1 instead of MacPorts' python 2.6.4)
so i did

sudo port install python_select
sudo python_select python26

and extensions happily stopped working.
Then i did

sudo port deactivate python26

and extensions happily started working again.
(I also restarted the machine in between, but i guess this does not matter.)
Now i do not have python in command line, but hope that restarting the machine again will bring back Apple's python to command line...

[Michael Wybrow (mjwybrow)]

This is all very strange. I have spent a bunch of time this weekend trying to get the extensions to work under Snow Leopard, mainly by taking versions installed by macports and rewriting the paths to point to versions of libraries in the app bundle. I still can't get this to work and have come to the conclusion that maybe Inkscape launches a python executable and that has it's own executable_path and so does not look for the libraries that the python lxml .so files are linked against. BTW, I also tries specifying a "DYLD_FALLBACK_FRAMEWORK_PATH" but that didn't seem to help.

I was considering building lxml against the Snow Leopard's xml2, xslt and exslt libraries but this is apparently not recommended by the lxml people since the versions distributed with OS X are out of date and cause problems -- this is true for older OS X versions, I haven't checked for sure it is true for the versions distributed with Snow Leopard.

After more investigation, I think the right way to do this might be to build versions of the lxml and numpy extensions with the "--static-deps" option to the "setup.py" build script. This will download and build the most recent xml libraries as part of the build process and then the extension should not depend on anything. Haven't got it building completely yet, but this is what I will test next, maybe tomorrow night.

FWIW, I can't really understand why the prebuilt extensions we have work with Apple's python 2.6 but not the Macports version, but thanks for your testing ~suv and Alexey, this is another avenue to pursue I guess.

[bbyak (buliabyak)]

I just tried the official 0.47 on a Snow L., works fine, but ran into this. This workaround worked for me:

$ defaults write /Library/Preferences/com.apple.versioner.python Version 2.5

Just adding a random data point. I will gladly test any fixes proposed here (if they don't require compilation, I haven't yet set development environment on OSX).

[Alexey (alexey-muranov)]

Strange, my extensions seem to work fine with python 2.6 (see my posts above).
When i run python from command line now, i have Apple's python:

$ python
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

but extensions are working...

[su_v (suv-lp)]

credits for this tip:
> defaults write /Library/Preferences/com.apple.versioner.python Version 2.5
go to 'blei' who added it in a comment of the mentioned topic in the Inkscape forum:
<http://www.inkscapeforum.com/viewtopic.php?f=29&t=3588&start=25#p18179>

Personally I have not yet upgraded to Snow Leopard and can't test any of the reported solutions - I am limited to picking up any promising reports of successful workarounds that could serve as interim solution until the real conflict can be pin-pointed and fixed.

[Ulf Adams (ulf-ofahrt)]

I didn't know about the lipo tool, but according to the lipo command,
the python 2.6 executable has x86_64, i386, and ppc7400. If it gets
executed in x86_64 mode, then loading the etree.so file for the lxml
extension must obviously fail, because it only contains the i386
extension. It shouldn't be too hard to compile the libraries in x86_64
mode and add that architecture to the files.

On Sun, Nov 29, 2009 at 7:12 PM, ~suv <email address hidden> wrote:
> credits for this tip:
>> defaults write /Library/Preferences/com.apple.versioner.python Version 2.5
> go to 'blei' who added it in a comment of the mentioned topic in the Inkscape forum:
> <http://www.inkscapeforum.com/viewtopic.php?f=29&t=3588&start=25#p18179>
>
> Personally I have not yet upgraded to Snow Leopard and can't test any of
> the reported solutions - I am limited to picking up any promising
> reports of successful workarounds that could serve as interim solution
> until the real conflict can be pin-pointed and fixed.
>
> --
> Inkscape extensions do not work on MacOS X 10.6 (Snow Leopard)
> https://bugs.launchpad.net/bugs/482993
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Inkscape: A Vector Drawing Tool: Confirmed
>
> Bug description:
> After installing Inkscape 0.47 pre4, we found that extensions don't work and give the infamous lxml error message:
>
> The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension. Please download and install the latest version from http://cheeseshop.python.org/pypi/lxml/, or install it through your package manager by a command like: sudo apt-get install python-lxml
>
> Printing out the real exception, this was due to dlopen not working. I investigated a little bit, and it seems that lxml doesn't work with the python 2.6 shipped with Snow Leopard. The python 2.6 binary is a 'Mach-O fat file with 3 architectures', while the etree.so shipped with lxml is a 'Mach-O fat file with 2 architectures'. I suspect that the 2.6 binary is running with the x86_64 architecture, which isn't present in the etree.so library.
>
> As a workaround, I symlinked /usr/bin/python to point to python 2.5 (which is a 'Mach-O fat file with 2 architectures'), and that makes the extensions work again.
>
> I've seen a few other bug reports for extensions, but none of them seems to describe the exact problem we encountered. In particular, the workaround in bug #345176 does not work.
>

[su_v (suv-lp)]

@Michael - have you tried to use one of these environment variables in 'Contents/Resources/bin/script'

   export VERSIONER_PYTHON_VERSION=2.5
or
   export VERSIONER_PYTHON_PREFER_32_BIT=yes

as described in <http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/python.1.html> and to remove the MacPython path '/Library/Frameworks/Python.framework/Versions/Current/bin' from $PATH, so that Inkscape internally calls (as primary and fallback) version
a) the system python 2.5 (32bit anyway) or
b) the system python 2.6 (in 32-bit mode)
using the corresponding bundled site-packages for i386, and
c) support the MacPorts versions by changing $PYTHONPATH similar to the discussed and proposed change to the search path for site-packages (see <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31854/focus=32075>) to prepend the ones installed in MacPorts to be used first and only keep the bundled ones as fallback.

[industrie13 (industrie13)]

Statusupdate:
I tried the recent snapshot Inkscape-r9333-10.5+-UNIVERSAL from http://inkscape.modevia.com/macosx-snap/?C=M;O=D today on a stock OS X 10.6.3 (without any aditional python installation, MacPorts or Fink stuff).

So far inkscape starts and works, but extensions still fail to work with this error message:

"The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension. Please download and install the latest version from http://cheeseshop.python.org/pypi/lxml/, or install it through your package manager by a command like: sudo apt-get install python-lxml"

[Dan Michael Heggø (danmichaelo)]

I get the same conflict between the bundled lxml and both Apple's Python 2.6.1 and MacPorts Python 2.6.5:

ImportError: dlopen(/Applications/Inkscape.app/Contents/Resources/python/site-packages/i386/2.6/lxml/etree.so, 2): no suitable image found. Did find:
 /Applications/Inkscape.app/Contents/Resources/python/site-packages/i386/2.6/lxml/etree.so: mach-o, but wrong architecture

As a workaround, I ended up making Inkscape use MacPorts Python 2.6.5 together with MacPorts py26-lxml instead of the bundled lxml, by commenting out line 29 in /Applications/Inkscape.app/Contents/Resources/bin/inkscape:

#export PYTHONPATH="$TOP/python/site-packages/$ARCH/$PYTHON_VERS"

[industrie13 (industrie13)]

I don't think, its a viable solution to expect from every 10.6-user to install macports and a different python version additionally.
I'd love to see it "just working" by default.

[Windell Oskay (windell)]

Just came across what looks like a potential solution, which has (if reports are to be believed) fixed this issue on 0.47 with 10.6:

http://caih.org/open-source-software/fixing-inkscape-in-mac-os-x/

The comments there indicate that the bug is *fixed* in the latest development versions-- can anyone confirm this?

[Ad Bakker (ad-adhenniebakker)]

Like all other suggestions, also this last one did not work with me. I also installed the Inkscape 0.48 pre-release, but still the same message when using extensions like "Modify Path/Add Nodes".
I am an end user, and not an experienced Unix user, so all the suggested work-arounds with all kind of Unix stuff do not work for me. It does amaze me that this problem, which seems to exist over more than a year is still not solved.

[Windell Oskay (windell)]

I wrote a workaround for Inkscape.app that does not solve the underlying problem, but at least fixes the symptom: It allows the application to launch and use extensions under 10.6. What it does is to check the system OS version. If it's version 10.6, then it modifies the path-- as used by inkscape only -- to prefer python 2.5. After doing this, extensions work correctly. (I've even been able to write a Mac installer package that applies this patch.)

To use this patch, copy the file (inkscape_10.6_patch) to into /Applications/Inkscape.app/Contents/Resources/bin/

Then, in the terminal:

cd /Applications/Inkscape.app/Contents/Resources/bin/
patch < inkscape_10.6_patch

Again, this is a workaround, not a permanent solution.

[Ad Bakker (ad-adhenniebakker)]

Thanks Windell, your "workaround" works with me!!!!!!!
Had first some problems, but that was because I saved the file in "normal" Mac text only, while it should be in the CR/LF format, as in MS-DOS. When that was clear it worked for the "Modify Path/Add Nodes" extension, so I presume that for now the problem is solved. I hope that future versions of Inkscape will have a permanent solution. But until then I can use it as it is now.

Again, thanks. I tried to solve this for over 6 months.
What I did was saving your document "inkscape_10.6_patch" in the Applications folder. Then, in the terminal:

cd /Applications
mv inkscape_10.6_patch Inkscape.app/Contents/Resources/bin
cd Inkscape.app/Contents/Resources/bin
patch < inkscape_10.6_patch

To be sure, I restarted and started Inkscape. As mentioned, it worked!!

[Remigiusz 'lRem' Modrzejewski (lrem)]

In fact there are two ways to cope with this problem. Either bundle the libraries in all the architectures (note: 64bit is now the default for OS X, so it's not an exotic request) or do what I did:

rm -r /Applications/Inkscape.app/Contents/Resources/python

Forcing the user to figure out an easy_install run is much better than hacking into the bundle...

[Windell Oskay (windell)]

>Forcing the user to figure out an easy_install run is much better than hacking into the bundle...

This solution (rm -r /Applications/Inkscape.app/Contents/Resources/python) is definitely an example of hacking the bundle as well.

[Alexey (alexey-muranov)]

What is wrong with the workaround that i suggested above?

Just skip doing
sudo port install python_select
sudo python_select python26
after installing python with MacPorts.

Extensions are working happily on my machine...

[Remigiusz 'lRem' Modrzejewski (lrem)]

Well, having to rm is exactly what I meant as hacking the bundle...

The python I have is totally unrelated to Inkscape. Uninstalling other programs to make Inkscape extensions work is not a viable workaround.

[Windell Oskay (windell)]

Having to install extra software (through port install or otherwise) to get the computer to execute programs that already come bundled is just plain silly. I have users that I need to support (running my extension), and if *editing one path* will fix it, that's a heck of a lot less pain then installing Macports and python.

[Alexey (alexey-muranov)]

Hm, my point was that the extensions were working BEFORE installing python with MacPorts, and my workaround was how to keep them working AFTER installing python with MacPorts (as a dependency of something else).

[Windell Oskay (windell)]

> extensions were working BEFORE installing python with MacPorts

The bug under discussion here is about how the default install of Inkscape, on OS X 10.6, does not correctly execute extensions. The conflict with MacPorts is a separate issue, that should be discussed on a separate thread.

[Alexey (alexey-muranov)]

Strange, extensions were working for me with the default install on OS X 10.6.
At least they started working after i removed MacPorts, and kept working after i reinstalled it without activating its python.
I do not plan to retest the whole procedure now...

[Remigiusz 'lRem' Modrzejewski (lrem)]

Bah, of course you're right Windell. Selecting a specific python installation to run is a valid solution. I'd say it should be done even without this bug. I thought I also included it in my comment (I included it in my blog post about the issue).

[su_v (suv-lp)]

a) incompatible architectures of module/python binary
Has anyone on Snow Leopard tried the solution proposed in comment #11 - using an Apple-provided environment variable to do the 'Selecting a specific python installation' magic with regard to version and architecture instead of editing $PATH (as proposed in comment #17)?

b) incompatible dylib versions loaded by modules/python binary
Also note that the fact that 'DYLD_LIBRARY_PATH' is no longer set in the launcher script potentially contributes to the error when trying to use a different python version installed with MacPorts: on OS X 10.5.8 Leopard extensions fail too [1], if using the bundled modules with python26 installed via MacPorts. The problem in this case is not 'different architecture' of the bundled modules and the python binary (both are i386) but a version conflict of the linked/loaded libraries (libxml2.2.dylib in this case). A possible solution for this (secondary) problem could be using the bundled modules only as fallback by adding the MacPorts path for site packages first in $PYTHONPATH, as outlined in comment #11. This would certainly be preferred to re-introducing 'DYLD_LIBRARY_PATH' (which is no longer needed since Inkscape 0.47).

[1] tested with latest bzr build from modevia as well as with local 0.47+devel builds (r9577) on OS X 10.5.8

[su_v (suv-lp)]

> using the bundled modules only as fallback by adding
>the MacPorts path for site packages first in $PYTHONPATH

Addendum: this of course assumes that the required modules lxml and numpy are also installed via MacPorts (e.g. to use the latest versions instead of the rather outdated ones currently bundled with Inkscape (bug #448285)) - else setting 'DYLD_LIBRARY_PATH' is the only workaround I'm aware of to use the bundled modules with a recent python build from MacPorts, at least on Leopard (I do not have access to Snow Leopard to test).

[Windell Oskay (windell)]

a) The fix in #11 does work ( export VERSIONER_PYTHON_VERSION=2.5 ), however it is unnecessarily disruptive to the operating system, as it sets python 2.5 to be the preferred version system-wide. This can have unanticipated side effects.

My version (#17) has a similar method-- forcing python 2.5 but only for Inkscape --and also works as tested on several systems, including ones with macports.

[su_v (suv-lp)]

> as it sets python 2.5 to be the preferred version system-wide

That's not how I read the python man page nor how environement variables work: the scope of using $VERSIONER_PYTHON_VERSION=2.5 is limited to the Inkscape process and inherited by the spawned python preocess, but does not change system preferences:

quoting <http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/python.1.html>:
"This environment variable takes precedence over the preference file settings."

[su_v (suv-lp)]

> forcing python 2.5 but only for Inkscape --and also works
> as tested on several systems, including ones with macports.

Best solution IMHO for allowing the use of either the default system python or one installed with MacPorts would be to add an additional folder hierarchy to the package for x86_64 (currently there exist 'ppc' and 'i386' in 'Contents/Resources/python/site-packages') with the site-packages for Python 2.6 (and maybe 2.7 or 3.0 later-on) in 64bit as well as updating the launcher script to set PYTHONPATH according to the system (or even better: python) arch (PPC, i386, x86_64).

[Windell Oskay (windell)]

>That's not how I read the python man page

I see; the version of this fix that I had tried previously was "sudo export VERSIONER_PYTHON_VERSION=2.5", which was systemwide. My apologies. I agree that using "export VERSIONER_PYTHON_VERSION=2.5", in place of directly editing the path is preferable.

However, it should still be implemented on a system-dependent basis. I believe that (for example) OS 10.4 does not include python 2.5 by default, and so requiring it may counterproductive.

Perhaps something like:

OSSTRING=`sw_vers -productVersion | cut -c 1-4 `
if [[ "$OSSTRING" == "10.6" ]]; then
 export VERSIONER_PYTHON_VERSION=2.5
fi

[su_v (suv-lp)]

> the version of this fix that I had tried previously was
> "sudo export VERSIONER_PYTHON_VERSION=2.5",
> which was systemwide.

Even when using 'sudo' (not needed in the context of the Inkscape launcher shell scripts), AFAIU the scope of the environment variable does not extend beyond the launched shell and processes called from it.

To make an environment variable permanently set in all shell processes you would add it to '~/.MacOSX/environment.plist' or '~/.profile' (or ~/.bash_profile) and to set an environment variable permanently system-wide you would add it for example to the shell profile in '/etc' or to a script in '/etc/paths.d/'.

But setting it permanently (and system-wide) IMHO does defeat the purpose of this environment variable: to override (system-wide) defaults for individual or current processes (again: as far as I understand it). The 'defaults' command is Apple's recommended way to permanently change the setting (python version/arch) system-wide - it should not be used in Inkscape's launcher scripts.

[su_v (suv-lp)]

> However, it should still be implemented on a system-dependent basis. I
> believe that (for example) OS 10.4 does not include python 2.5 by
> default, and so requiring it may counterproductive.

Apple's Python on Tiger and Leopard should ignore $VERSIONER_PYTHON_VERSION - it was introduced with Snow Leopard for the new mechanism to select between multiple installed python versions and provide backward-compatibility. Setting it depending on $OSSTRING might be prudent, but maybe not needed - the main caveats to me seem
- MacPorts: the possibility that python versions installed with MacPorts might be patched to be aware of it (untested),
- MacPython installations (binary packages from python.org): ?

[Patrick Lewis (pdlewis)]

I just figured out today, that I am not the only one with this issues. I am new the Inkscape recently.
I am running
OS X 10.6.3 and have confirmed python 2.6.1 like in #8 & Inkscape .47 r22583
Initially started with mac X11
I found XQuartz and installed 2.5.1 today, and reinstalled Inkscape, no change

I have since upgraded to python 2.7 from http://www.python.org/download/
I selected " Python 2.7 PPC/i386/x86-64 Max OS X Installer Disk Image (for Mac OS X 10.5 or later)"
(there is also a 32-bit version only), installed no change.
It is good to see that this should be fixed soon, but I will see what I can figure out on my side. I will post more as I study this.

Terminal Dump:
---------------------------------
$ python
Python 2.7 (r27:82508, Jul 3 2010, 21:12:11)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
------------------------------

[Patrick Lewis (pdlewis)]

Just an observation but i just downloaded the .48 pre 1 and sill no changed, i did look into the package and after looking at the lxml downloads, I noticed that python 2.6 downloads are called fat, I assume that mean multi arch, but as I can't get the egg to install I can not tell. But on that observation, is it possible the 2.6 lxml in the build is actually the 2.5 lxml?

[su_v (suv-lp)]

> after looking at the lxml downloads, I noticed that
> python 2.6 downloads are called fat, I assume that
> mean multi arch

I don't know about binary packages of lxml downloads.

The site-packages bundled with Inkscape 0.47 (and 0.48pre1) have separate folder hierarchies for ppc/i386.
The i386 modules for python 2.6 are not universal builds:

LeWitt:i386 suv$ file 2.6/*/*.so
2.6/lxml/etree.so: Mach-O bundle i386
2.6/lxml/objectify.so: Mach-O bundle i386

LeWitt:i386 suv$ file 2.6/*/*/*.so
2.6/numpy/core/_dotblas.so: Mach-O bundle i386
2.6/numpy/core/_sort.so: Mach-O bundle i386
2.6/numpy/core/multiarray.so: Mach-O bundle i386
2.6/numpy/core/scalarmath.so: Mach-O bundle i386
2.6/numpy/core/umath.so: Mach-O bundle i386
2.6/numpy/fft/fftpack_lite.so: Mach-O bundle i386
2.6/numpy/lib/_compiled_base.so: Mach-O bundle i386
2.6/numpy/linalg/lapack_lite.so: Mach-O bundle i386
2.6/numpy/numarray/_capi.so: Mach-O bundle i386
2.6/numpy/random/mtrand.so: Mach-O bundle i386

The modules for python 2.5 in 'i386' however are Universal builds (PPC, i386), but do not include 64bit (x86-64):

LeWitt:i386 suv$ file 2.5/*/*.so
2.5/lxml/etree.so: Mach-O universal binary with 2 architectures
2.5/lxml/etree.so (for architecture i386): Mach-O bundle i386
2.5/lxml/etree.so (for architecture ppc7400): Mach-O bundle ppc
2.5/lxml/objectify.so: Mach-O universal binary with 2 architectures
2.5/lxml/objectify.so (for architecture i386): Mach-O bundle i386
2.5/lxml/objectify.so (for architecture ppc7400): Mach-O bundle ppc
2.5/lxml/pyclasslookup.so: Mach-O universal binary with 2 architectures
2.5/lxml/pyclasslookup.so (for architecture i386): Mach-O bundle i386
2.5/lxml/pyclasslookup.so (for architecture ppc7400): Mach-O bundle ppc

(...)

> is it possible the 2.6 lxml in the build is actually the 2.5 lxml

No, they do work with MacPorts Python 2.6 (e.g. on Leopard), if DYLD_LIBRARY_PATH is set.

[industrie13 (industrie13)]

The bug still persists in Inkscape 0.48 in Mac OS X 10.6 Snow Leopard. I can't understand, why the Inkscape team releases such a buggy version. Its unusable for a lot of users this way.

[Windell Oskay (windell)]

Wow-- what happened to this being targeted for milestone Inkscape 0.48 "0.48"?

I'm surprised that it didn't at least merit a mention on the list of known issues -- "oh by the way, the extensions menu doesn't work on all platforms."

[Ad Bakker (ad-adhenniebakker)]

I installed the work-around as described in the posts of June 30 by Windell and myself. It works (Imac21.5 with Snow Leopard 10.6.4), but extremely slow (Modify path --> Add nodes takes about a minute to divide a straight line into 4 segments). And previously I found that it is not stable in all situations, and sometimes causes a crash.

[Andre Dejam (andredejam)]

Hi there-I just started looking into inkscape. I like the program so far. Unfortunately, I came across this extension issue. It seems to me that Windell has a good fix for the problem. I am not familiar with Unix and so could not implement it. Is there a way to help me fix this issue in an "inkscape for Dummies" kind of way?

I would appreciate it very much and thank you for your patience in advance.

Andre

[Windell Oskay (windell)]

In talking to different people about this problem, it sounds like for *some* people, Inkscape 0.48 *does* run on 10.6 with extensions. Can anyone confirm this? Is it possible to nail down under what configuration and/or circumstances Inkscape will work properly?

[Windell Oskay (windell)]

Addendum: I mean, working under 10.6, with python 2.6.

[su_v (suv-lp)]

You could use the attached extension to get some basic information about the python version Inkscape calls, and the modules it loads (lxml, numpy). Put both files (debug.inx, debug.py) into '~/.config/inkscape/extensions' and relaunch Inkscape. The script is listed as 'Extensions > Debug > Python module info'.

[Windell Oskay (windell)]

Following is the trace from a MacOS system running 10.6.4, where Inkscape extensions are working properly.

Also, in case it's helpful,
% uname -a
Darwin xxx 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386

Trace follows:

Default Encoding: ascii
----------------------------------------
Filesystem Encoding: utf-8
----------------------------------------
Platform: darwin
----------------------------------------
Python version: 2.6.4
----------------------------------------
lxml path: /Applications/Inkscape.app/Contents/Resources/python/site-packages/i386/2.6/lxml
LXML_VERSION: 2.1.3.0
LIBXML_VERSION: 2.7.3
LIBXML_COMPILED_VERSION: 2.7.1
LIBXSLT_VERSION: 1.1.24
LIBXSLT_COMPILED_VERSION: 1.1.24
----------------------------------------
numpy path: /Applications/Inkscape.app/Contents/Resources/python/site-packages/i386/2.6/numpy
numpy version: 1.3.0.dev5986
----------------------------------------
sys.path:
 /Applications/Inkscape.app/Contents/Resources/extensions
 /Applications/Inkscape.app/Contents/Resources/extensions
 /Applications/Inkscape.app/Contents/Resources/python/site-packages/i386/2.6
 /usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.6/site-packages
 /usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.6/site-packages/wx-2.8-mac-unicode
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python26.zip
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-darwin
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-scriptpackages
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-old
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
 /usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.6

-- finit --

[su_v (suv-lp)]

Windell Oskay wrote
> Python version: 2.6.4
Is this the official Python version provided and updated by Apple with Snow Leopard (as of X 10.6.4)? AFAIK Snow Leopard originally ships with Python 2.6.1.

What is the output of:
 defaults read com.apple.versioner.python
 defaults read /Library/Preferences/com.apple.versioner.python
 env | grep VERSIONER_PYTHON_PREFER_32_BIT

Note: possibly the installation of wxPython changed (or at least also requires) the default 'python' to run in 32bit mode.

[Windell Oskay (windell)]

> Is this the official Python version provided and updated by Apple

Sounds like it isn't. My own system has 2.6.1, and extensions do not work.

Here are the other outputs you asked for; there's nothing there:

% defaults read com.apple.versioner.python
2010-09-14 15:20:06.835 defaults[25397:903]
Domain com.apple.versioner.python does not exist

% defaults read /Library/Preferences/com.apple.versioner.python
2010-09-14 15:20:06.847 defaults[25398:903]
Domain com.apple.versioner.python does not exist

% env | grep VERSIONER_PYTHON_PREFER_32_BIT
%

[su_v (suv-lp)]

Can you run the attached updated debug.py? It should include the Python version in detail as well as the full path of the python executable (besides outputting the complete $PATH as an unformatted, long string - sorry for that ;) ).

° Python executable:
Can you test 'lipo -info' on the python executable that Inkscape calls?

° Python exec_prefix:
Can you test these two commands on the returned string for 'exec_prefix'?
ls -l <exec_prefix>
ls -l <exec_prefix>/bin

[su_v (suv-lp)]

Correction:
- the complete $PATH as an unformatted, long string
+ the complete environment (os.environ) as an long, unformatted string

[Windell Oskay (windell)]

% lipo -info /Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
Architectures in the fat file: /Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python are: ppc i386
% ls -ld /Library/Frameworks/Python.framework/Versions/2.6
drwxrwxr-x 10 root admin 340 Oct 27 2009 /Library/Frameworks/Python.framework/Versions/2.6
% ls -l /Library/Frameworks/Python.framework/Versions/2.6
total 7768
lrwxr-xr-x 1 root admin 17 Jan 18 2010 Headers -> include/python2.6
drwxrwxr-x 3 root admin 102 Oct 27 2009 Mac
-r-xrwxr-x 1 root admin 3970996 Oct 27 2009 Python
drwxrwxr-x 5 root admin 170 Jan 18 2010 Resources
drwxrwxr-x 15 root admin 510 Oct 27 2009 bin
drwxrwxr-x 3 root admin 102 Oct 27 2009 include
drwxrwxr-x 19 root admin 646 Oct 27 2009 lib
drwxrwxr-x 3 root admin 102 Oct 27 2009 share
% ls -l /Library/Frameworks/Python.framework/Versions/2.6/bin
total 248
-rwxrwxr-x 1 root admin 150 Oct 27 2009 2to3
lrwxr-xr-x 1 root admin 7 Jan 18 2010 idle -> idle2.6
-rwxrwxr-x 1 root admin 138 Oct 27 2009 idle2.6
lrwxr-xr-x 1 root admin 8 Jan 18 2010 pydoc -> pydoc2.6
-rwxrwxr-x 1 root admin 123 Oct 27 2009 pydoc2.6
lrwxr-xr-x 1 root admin 9 Jan 18 2010 python -> python2.6
lrwxr-xr-x 1 root admin 16 Jan 18 2010 python-config -> python2.6-config
-rwxrwxr-x 1 root admin 29560 Oct 27 2009 python2.6
-rwxrwxr-x 1 root admin 1463 Oct 27 2009 python2.6-config
lrwxr-xr-x 1 root admin 10 Jan 18 2010 pythonw -> pythonw2.6
-rwxrwxr-x 1 root admin 29560 Oct 27 2009 pythonw2.6
lrwxr-xr-x 1 root admin 11 Jan 18 2010 smtpd.py -> smtpd2.6.py
-rwxrwxr-x 1 root admin 18093 Oct 27 2009 smtpd2.6.py
%

==== revised debug.py output =======================

Default Encoding: ascii
----------------------------------------
Filesystem Encoding: utf-8
----------------------------------------
Platform: darwin
----------------------------------------
Python version: 2.6.4
Python version:
2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
[GCC 4.0.1 (Apple Inc. build 5493)]
----------------------------------------
Python executable:
 /Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
Python exec_prefix:
 /Library/Frameworks/Python.framework/Versions/2.6
Python prefix:
 /Library/Frameworks/Python.framework/Versions/2.6
----------------------------------------
lxml path: /Applications/Inkscape.app/Contents/Resources/python/site-packages/i386/2.6/lxml
LXML_VERSION: 2.1.3.0
LIBXML_VERSION: 2.7.3
LIBXML_COMPILED_VERSION: 2.7.1
LIBXSLT_VERSION: 1.1.24
LIBXSLT_COMPILED_VERSION: 1.1.24
----------------------------------------
numpy path: /Applications/Inkscape.app/Contents/Resources/python/site-packages/i386/2.6/numpy
numpy version: 1.3.0.dev5986
----------------------------------------
sys.path:
 /Users/dnewman/.config/inkscape/extensions
 /Applications/Inkscape.app/Contents/Resources/extensions
 /Applications/Inkscape.app/Contents/Resources/python/site-packages/i386/2.6
 /usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.6/site-packages
 ...

[su_v (suv-lp)]

> % lipo -info /Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
> Architectures in the fat file: /Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python are: ppc i386

AFAIU that is the reason why the extensions work here: this system has a user-installed Python version which is a 32bit application and therefor can import and execute the bundled python 2.6 site packages (like it does on Leopard).

Probably the 32-bit version of Python 2.6 from python.org was installed in order to use wxPython 2.8.11.0.

[su_v (suv-lp)]

Another note: the environment contains 'VERSIONER_PYTHON_VERSION': '2.5'
which tells that either
a) the test was run with a patched version of the official Inkscape.app (as mentioned in comment #33 and earlier): this of course would have made the extension work even without a user-installed 32bit Python version, or
b) the shell environment of this computer has this variable set globally or in your account specifically (e.g. in one of the shell startup files or in ~/.MacOSX/environment.plist).

It also confirms that only Apple's Python knows about the specific versioner mechanism [1] and the variable is ignored by other python builds (comment #35).

For further tests please use the original Inkscape.app, or document any patches you had applied before running the tests.

[1] <http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/python.1.html>

[su_v (suv-lp)]

Looking for confirmation/answers:

a) Can others confirm that Inkscape's python-based extensions work on a Snow Leopard system with Python 2.6.4 downloaded and installed from <http://www.python.org/download/releases/2.6.4/>?

b) Can others confirm that Python 2.6.x from python.org installs into '/Library/Frameworks/Python.framework/' as opposed to Apple's Python in '/System/Library/Frameworks/Python.framework/'?

c) Are all Python 2.6.x versions downloaded and installed from python.org 32bit only?

d) Does anyone have any experiences with later 2.6.x releases from python.org?
- Python 2.6.5 <http://www.python.org/download/releases/2.6.5/>
- Python 2.6.6 <http://www.python.org/download/releases/2.6.6/>

[Windell Oskay (windell)]

@Andre Dejam:

The Mac installer for the Egg-Bot Inkscape extensions automatically applies this patch:

http://code.google.com/p/eggbotcode/downloads/detail?name=EggBot200r4.mpkg.zip

(It also adds an "Eggbot" submenu to your Extensions menu that can be safely ignored.)

[su_v (suv-lp)]

@Michael - could you please test the attached patch on Snow Leopard and consider it for the upcoming release of Inkscape 0.48.1 to make extensions work on Snow Leopard with the currently bundled python modules (32bit)?

(tested with Inkscape 0.48.1 r9699 on OS X 10.5.8 to make sure it doesn't break things on Leopard).

[su_v (suv-lp)]

updated version of 'debug.py': better readable output of environment variables as seen by the python process

[Michael Wybrow (mjwybrow)]

Okay, I've updated the nightlies to hopefully fix this problem. The first build with this fix is r9873
http://inkscape.modevia.com/macosx-snap/Inkscape-r9873-10.5+-UNIVERSAL.dmg

Could people please test this build and give feedback?

I've tested it on four machines with a mix of 10.5/10.6 and with/without Macports. If the fix works for others, I'll commit it to Bazaar.

What I've done:
1) Made /usr/bin be at the beginning of the path when running Inkscape, so the MacOS python version is used.
2) Added VERSIONER_PYTHON_PREFER_32_BIT=yes to force use of the 32-bit python.

[Michael Wybrow (mjwybrow)]

Also, thanks everyone for your work in tracking down and trying fixes for this issue. It's much appreciated!

[Windell Oskay (windell)]

Michael,
I've tested this version and confirmed that it does fix the problem on my computer, running 10.6.

And, *thank you*-- it's great to see this coming along!

[su_v (suv-lp)]

Fix confirmed (extensions work, as before) on OS X 10.5.8 (no MacPorts in default prefix, no MacPython or Python.org installation)

Thanks, Michael, much appreciated :)

[industrie13 (industrie13)]

I can confirm, that with this version Inkscape-r9873-10.5+-UNIVERSAL.dmg I did NOT get any error messages regarding the python version, so extensions seem to work now.
I did run this build on a virgin (no macports, no additional python than the systems one) OS X 10.6.4.

I get error messages by using some extensions like Gcodetools --> Engraving:
"Das aufgerufene Skript hat zusätzliche Daten an Inkscape übergeben. Es wurde keine Fehlermeldung vom Skript zurückgegeben, doch das Resultat ist möglicherweise unbrauchbar."

and

"Select one of the active tabs - Path to Gcode, Area, Engraving, DXF points, Orientation, Offset, Lathe or Tools library."
but that without any effect.

But I don't know, if this is related to the original problem. At least the python version error is gone for now.

[Michael Wybrow (mjwybrow)]

Fixed in revision 9883.

[Rig Out (rigout)]

Hi,
Firstly, I'm not a developer. I just wanted to say thank you for fixing this long running bug. Its going to be great to have this issue finally fixed. Thank you guys for your hard work and persistence.

Secondly, while I was here I saw that you wanted people to try the updated (beta?) version.

I have downloaded the latest version r9888-10.5+Universal.dmg ( http://inkscape.modevia.com/macosx-snap/Inkscape-r9888-10.5+-UNIVERSAL.dmg )

I don't have macports or anything fancy like that- I'm just an 'ordinary' mac user. However I am running Snow Leopard 10.6.5. I uninstalled my previous version of Inksacpe before trying this beta.

Unfortunately Inkscape r9888 won't launch for me I get this error "Inkscape encountered and internal error and will close now"

[su_v (suv-lp)]

@Rig Out - the latest snapshot builds from modevia don't work (known issue, affects r9886 and r9888 so far). This can happen any time with nightly builds from the development branch (they are built and uploaded by a script). Please use an earlier package: either the one linked to in comment #59 or one in-between: r9873, r9878 and r9882 should work fine.

> I uninstalled my previous version of Inksacpe before trying this beta.

Not needed, you can keep the stable release version installed. Just drop the development version into a different folder (maybe rename the app so you know which revision of the development branch you are using). Inkscape packaged as OS X application is fully relocatable i.e. it can run from any folder on your system, not just from '/Applications'.

[Rig Out (rigout)]

I installed r9873 and it works

I tested the extensions and I'm delighted to say most that I tried worked.

One that didn't work and gave an error that may be related to this bug was:
Visualize Path/Measure Path

The error it gave:
Inkscape has received additional data from the script executed. The script did not return an error, but this may indicate the results will not be as expected.

Traceback (most recent call last):
  File "measure.py", line 35, in <module>
    locale.setlocale(locale.LC_ALL, '')
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/locale.py", line 494, in setlocale
locale.Error: unsupported locale setting

***
I made a list of the other ones that didn't work for me. That could be because I wasn't using them properly or that there is an issue with the extension itself or maybe because of this bug we're dealing with here. Anyway for what its worth here is the list:

Arrange/restack
render/parametric curve
Modify Path/convert to dashes
Modify Path/fractalize
Text/Convert to braille
Vizualize Path/Draw Handels
Generate from Pat/ Interpolate

***
And extensions I didn't test: (don't know how to use them)

Gcode
Export/Guillotine
Web
Images

Jessy (-it returned this message:)
The JessyInk script is not installed in this SVG file or has a different version than the JessyInk extensions. Please select "install/update..." from the "JessyInk" sub-menu of the "Extensions" menu to install or update the JessyInk script.

***

Thanks again for fixing this issue :)

[Rig Out (rigout)]

I forgot to ask, is r9873 ok to use regularly? Obviously it's not a finished version, but is it ok to take it that it's a 'reliable' beta version? -what ever that is :)

[su_v (suv-lp)]

> is r9873 ok to use regularly?

Do save often :) or wait for soon-to-be released next stable version 0.48.1 (development snapshots are not recommended for productive work). Also note that some of the features in the development builds are not part of the 0.48 branch (milestoned for 0.49 [0]).

> One that didn't work and gave an error that may be related to this bug was:
> Visualize Path/Measure Path

Not related to this bug (or Snow Leopard): it was discussed in the comments of bug #406662 (and related issue bug #476678), but has not yet been addressed or solved in the sources. You could file a new report though (the error happens on Leopard, too).

> I made a list of the other ones that didn't work for me.

These seem questions about correct usage and are outside of the scope of this bug report. Use the 'Answers' section here at launchpad [1] for support, or the Inkscape forum [2], but read the manual pages about the extensions [3] first. For JessyInk, see the documentation at its homepage [4].

[0] <http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49>
[1] <https://answers.launchpad.net/inkscape>
[2] <http://www.inkscapeforum.com/>
[3] <http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Extensions.html>
[4] <http://code.google.com/p/jessyink/>

[Rig Out (rigout)]

>Also note that some of the features in the development builds are not part of the 0.48 branch

I didn't know that. I think I will wait for 0.48.1. Thanks

>These seem questions about correct usage and are outside of the scope of this bug report.

No problem. I wasn't sure if I should list them or not. I just ran through as many extensions as I could and tried to get them to work as best I could so that I could give some feed back here.

Thanks again for fixing this bug.

[su_v (suv-lp)]

backported to 0.48.x in r9719

[su_v (suv-lp)]

> Unfortunately Inkscape r9888 won't launch for me I get this
> error "Inkscape encountered and internal error and will close now"

The issue has been solved (thanks to Michael!) and the most recent snapshot build available (r9889 as of today) works fine again.
<http://inkscape.modevia.com/macosx-snap/?C=M;O=D>

[Nathan Orloffmo (nathan-orloff)]

I have tried everything in this thread. I mean everything. Now, Inkscape runs, but the extensions don't do anything. They execute but the image is not modified. Even simple things like changing an image to grayscale. I have not idea how to fix this. My wife has her thesis due tomorrow and I really need to help her make a figure.

[su_v (suv-lp)]

@Nathan - download a recent development snapshot as mentioned in comment #59 - the workarounds described here are not intended for users, they are discussed here to pin-point the error and fix it so that Inkscape extensions work out-of-the-box on all supported versions of Mac OS X.

If you need a working version ASAP and can't wait for the soon-to-be-released stable version 0.48.1 (which will include the fix), browse to <http://inkscape.modevia.com/macosx-snap/?C=M;O=D> and download the top-most (newest) DMG listed there. You can keep the stable version installed, just drag&drop the development snapshot into a different folder, and use it with care (i.e. save often), until 0.48.1 is out.

[su_v (suv-lp)]

Nathan Orloffmo wrote
> Even simple things like changing an image to grayscale.

Are you trying to change an embedded or linked bitmap? Then of course 'Extensions > Color > Grayscale' doesn't do anything: the extension modifies the style attributes of vector objects and has no effect on bitmap images. For bitmap (aka raster) graphics (linked or embedded), you could 'Filters > Color > Desaturate' or maybe one of the raster extensions (Extensions > Raster), though I don't know at the moment which one of those would allow to convert the image to grayscale or desaturate it.

[Nathan Orloffmo (nathan-orloff)]

Maybe I am an idiot. I thought I should use embedded?

[Nathan Orloffmo (nathan-orloff)]

No. No. I am an idiot.

[Melissa Bruninga-Matteau (melissa-bruninga)]

Yeah! It worked! Thanks for the fix! I was in despair!

[Nigel Frampton (nigel-frampton)]

I have downloaded r10022 and the extensions seem to be working fine on Mac OS X 10.6.6. With the stable version (0.48.0) the extensions were still generating the error message about the wonderful lxml wrapper!

Thanks for the solution!

[Salvatore (george-raul)]

Still happens, under Mac OS X 10.7.2 and Inkscape 0.48.2 r9819...

[su_v (suv-lp)]

@Salvatore - that's (different) known issue tracked in
 Bug #819209 in Inkscape: “Extensions do not work with Mac OS X Lion”
 <https://bugs.launchpad.net/inkscape/+bug/819209>

[Salvatore (george-raul)]

Oh I'm sorry, it is this one instead https://bugs.launchpad.net/inkscape/+bug/819209 which is specific about Mac Os X 10.7

[thomas (tblond)]

I downloaded inkscape and launched it. The icon in the docking keeps jumping up and down x11 is loaded and hen it does load a window comes up with the following bash-3.2$ and nothing else happens. Inkscape does not load no matter how long I wait.
XII must be working ok since gimp is able to open with no problem.

[Windell Oskay (windell)]

#83 (thomas): Your report does not appear to be related to bug #482993, which has been fixed in distribution as of March, 2011.

Make sure that you have the latest version of XQuartz installed before trying to launch Inkscape. If you are still not successful, please post your question in Inkscape Answers ( https://answers.launchpad.net/inkscape/ ) or at one of the Inkscape forums, or to the inkscape-user mailing list. (This is not the appropriate location.)

[Jan-Peter (ftjp)]

Hi. I tried to find a solution in different forums, but was not successful... :-(

Brief description of my problem: Similar to the earlier posts here, I try to export to tikz from Inkscape and get the lxml error message. The tikz-file has been created, but is empty.

I am running Mac OS 10.8.2
Xquartz 2.7.4
Inkscape 0.48.2 r 9819
Installed python 2.6 and 2.7 via macports

Has anybody seen this before and maybe found a solution?

Inkscape launches and produces nice .svg and .tex-files (by pstricks extension). Since beamer and pstricks do not go together well, I was hoping to export to tikz from Inkscape.

Your help will be much appreciated!

[su_v (suv-lp)]

> Similar to the earlier posts here, I try to export to tikz from Inkscape
> (…)
> I am running Mac OS 10.8.2

Issues with the bundled extensions on Lion and Mountain Lion are tracked in bug #819209 (you'll find a link to instructions how to make the bundled extensions work with Inkscape 0.48.2 on Lion/Mountain Lion there). This report (bug #482993) is about issues with older Inkscape versions on Snow Leopard, and is closed (aka fixed) in Inkscape 0.48.2.

> Installed python 2.6 and 2.7 via macports

Is this a requirement by a custom extension you plan to use to export to 'tikz'? Or why did you think that it is required? (Hint: it is not, at least not for those python-based extensions bundled with Inkscape).

[Jan-Peter (ftjp)]

Hi ~suv,

Thanks for the comment, I will write a new posting there.

Trying to install an lxml version, I installed macports and I think the python versions just came with it.

Greets
J-P