Inkscape extensions do not work on MacOS X 10.6 (Snow Leopard)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Fix Released
|
High
|
Michael Wybrow |
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://
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.
tags: | added: extensions-plugins osx packaging |
su_v (suv-lp) wrote : | #1 |
Changed in inkscape: | |
assignee: | nobody → Michael Wybrow (mjwybrow) |
importance: | Undecided → High |
status: | New → Confirmed |
Ulf Adams (ulf-ofahrt) wrote : | #2 |
Let me know if there's anything I can do to help.
su_v (suv-lp) wrote : | #3 |
there have been two further workarounds reported in this InkscapeForum topic:
<http://
A) change the default python version back to Python 2.5
terminal command:
defaults write /Library/
references:
<http://
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://
Alexey (alexey-muranov) wrote : | #4 |
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) wrote : | #5 |
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) wrote : | #6 |
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_
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) wrote : | #7 |
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/
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) wrote : | #8 |
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) wrote : | #9 |
credits for this tip:
> defaults write /Library/
go to 'blei' who added it in a comment of the mentioned topic in the Inkscape forum:
<http://
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) wrote : Re: [Bug 482993] Re: Inkscape extensions do not work on MacOS X 10.6 (Snow Leopard) | #10 |
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/
> go to 'blei' who added it in a comment of the mentioned topic in the Inkscape forum:
> <http://
>
> 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:/
> 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://
>
> 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) wrote : | #11 |
@Michael - have you tried to use one of these environment variables in 'Contents/
export VERSIONER_
or
export VERSIONER_
as described in <http://
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://
Changed in inkscape: | |
milestone: | none → 0.48 |
industrie13 (industrie13) wrote : | #12 |
Statusupdate:
I tried the recent snapshot Inkscape-
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://
Dan Michael Heggø (danmichaelo) wrote : | #13 |
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/
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/
#export PYTHONPATH=
industrie13 (industrie13) wrote : | #14 |
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) wrote : | #15 |
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://
The comments there indicate that the bug is *fixed* in the latest development versions-- can anyone confirm this?
Ad Bakker (ad-adhenniebakker) wrote : | #16 |
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) wrote : | #17 |
- inkscape_10.6_patch Edit (710 bytes, text/plain)
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_
Then, in the terminal:
cd /Applications/
patch < inkscape_10.6_patch
Again, this is a workaround, not a permanent solution.
Ad Bakker (ad-adhenniebakker) wrote : | #18 |
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_
cd /Applications
mv inkscape_10.6_patch Inkscape.
cd Inkscape.
patch < inkscape_10.6_patch
To be sure, I restarted and started Inkscape. As mentioned, it worked!!
Remigiusz 'lRem' Modrzejewski (lrem) wrote : | #19 |
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/
Forcing the user to figure out an easy_install run is much better than hacking into the bundle...
Windell Oskay (windell) wrote : | #20 |
>Forcing the user to figure out an easy_install run is much better than hacking into the bundle...
This solution (rm -r /Applications/
Alexey (alexey-muranov) wrote : | #21 |
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) wrote : | #22 |
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) wrote : | #23 |
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) wrote : | #24 |
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) wrote : | #25 |
> 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) wrote : | #26 |
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) wrote : | #27 |
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) wrote : | #28 |
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) wrote : | #29 |
> 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) wrote : | #30 |
a) The fix in #11 does work ( export VERSIONER_
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) wrote : | #31 |
> 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_
quoting <http://
"This environment variable takes precedence over the preference file settings."
su_v (suv-lp) wrote : | #32 |
> 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/
Windell Oskay (windell) wrote : | #33 |
>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_
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_
fi
su_v (suv-lp) wrote : | #34 |
> the version of this fix that I had tried previously was
> "sudo export VERSIONER_
> 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/
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) wrote : | #35 |
> 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_
- 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) wrote : | #36 |
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://
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) wrote : | #37 |
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) wrote : | #38 |
> 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/
LeWitt:i386 suv$ file 2.6/*/*/*.so
2.6/numpy/
2.6/numpy/
2.6/numpy/
2.6/numpy/
2.6/numpy/
2.6/numpy/
2.6/numpy/
2.6/numpy/
2.6/numpy/
2.6/numpy/
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/
2.5/lxml/
2.5/lxml/
2.5/lxml/
2.5/lxml/
2.5/lxml/
(...)
> 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) wrote : | #39 |
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) wrote : | #40 |
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."
Changed in inkscape: | |
milestone: | 0.48 → 0.48.1 |
Ad Bakker (ad-adhenniebakker) wrote : | #41 |
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) wrote : | #42 |
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) wrote : | #43 |
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) wrote : | #44 |
Addendum: I mean, working under 10.6, with python 2.6.
su_v (suv-lp) wrote : | #45 |
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/
su_v (suv-lp) wrote : | #46 |
Windell Oskay (windell) wrote : | #47 |
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-
Trace follows:
Default Encoding: ascii
-------
Filesystem Encoding: utf-8
-------
Platform: darwin
-------
Python version: 2.6.4
-------
lxml path: /Applications/
LXML_VERSION: 2.1.3.0
LIBXML_VERSION: 2.7.3
LIBXML_
LIBXSLT_VERSION: 1.1.24
LIBXSLT_
-------
numpy path: /Applications/
numpy version: 1.3.0.dev5986
-------
sys.path:
/Applications/
/Applications/
/Applications/
/usr/local/
/usr/local/
/Library/
/Library/
/Library/
/Library/
/Library/
/Library/
/Library/
/Library/
/Library/
/usr/local/
-- finit --
su_v (suv-lp) wrote : | #48 |
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.
defaults read /Library/
env | grep VERSIONER_
Note: possibly the installation of wxPython changed (or at least also requires) the default 'python' to run in 32bit mode.
Windell Oskay (windell) wrote : | #49 |
> 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.
2010-09-14 15:20:06.835 defaults[25397:903]
Domain com.apple.
% defaults read /Library/
2010-09-14 15:20:06.847 defaults[25398:903]
Domain com.apple.
% env | grep VERSIONER_
%
su_v (suv-lp) wrote : | #50 |
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) wrote : | #51 |
Correction:
- the complete $PATH as an unformatted, long string
+ the complete environment (os.environ) as an long, unformatted string
Windell Oskay (windell) wrote : | #52 |
% lipo -info /Library/
Architectures in the fat file: /Library/
% ls -ld /Library/
drwxrwxr-x 10 root admin 340 Oct 27 2009 /Library/
% ls -l /Library/
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/
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/
Python exec_prefix:
/Library/
Python prefix:
/Library/
-------
lxml path: /Applications/
LXML_VERSION: 2.1.3.0
LIBXML_VERSION: 2.7.3
LIBXML_
LIBXSLT_VERSION: 1.1.24
LIBXSLT_
-------
numpy path: /Applications/
numpy version: 1.3.0.dev5986
-------
sys.path:
/Users/
/Applications/
/Applications/
/usr/local/
...
su_v (suv-lp) wrote : | #53 |
> % lipo -info /Library/
> Architectures in the fat file: /Library/
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) wrote : | #54 |
Another note: the environment contains 'VERSIONER_
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/
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://
su_v (suv-lp) wrote : | #55 |
Looking for confirmation/
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://
b) Can others confirm that Python 2.6.x from python.org installs into '/Library/
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://
- Python 2.6.6 <http://
Windell Oskay (windell) wrote : | #56 |
@Andre Dejam:
The Mac installer for the Egg-Bot Inkscape extensions automatically applies this patch:
http://
(It also adds an "Eggbot" submenu to your Extensions menu that can be safely ignored.)
su_v (suv-lp) wrote : | #57 |
- 482993-python-version.diff Edit (1.3 KiB, text/plain)
@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) wrote : | #58 |
Michael Wybrow (mjwybrow) wrote : | #59 |
Okay, I've updated the nightlies to hopefully fix this problem. The first build with this fix is r9873
http://
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_
Michael Wybrow (mjwybrow) wrote : | #60 |
Also, thanks everyone for your work in tracking down and trying fixes for this issue. It's much appreciated!
Windell Oskay (windell) wrote : | #61 |
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) wrote : | #62 |
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) wrote : | #63 |
I can confirm, that with this version Inkscape-
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) wrote : | #64 |
Fixed in revision 9883.
Changed in inkscape: | |
status: | Confirmed → Fix Committed |
Rig Out (rigout) wrote : | #65 |
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.
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) wrote : | #66 |
@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) wrote : | #67 |
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.
File "/System/
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) wrote : | #68 |
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) wrote : | #69 |
> 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://
[1] <https:/
[2] <http://
[3] <http://
[4] <http://
Rig Out (rigout) wrote : | #70 |
>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) wrote : | #71 |
backported to 0.48.x in r9719
su_v (suv-lp) wrote : | #72 |
> 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://
Nathan Orloffmo (nathan-orloff) wrote : | #73 |
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) wrote : | #74 |
@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://
su_v (suv-lp) wrote : | #75 |
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) wrote : | #76 |
Maybe I am an idiot. I thought I should use embedded?
Nathan Orloffmo (nathan-orloff) wrote : | #77 |
No. No. I am an idiot.
Melissa Bruninga-Matteau (melissa-bruninga) wrote : | #78 |
Yeah! It worked! Thanks for the fix! I was in despair!
Nigel Frampton (nigel-frampton) wrote : | #79 |
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!
Changed in inkscape: | |
status: | Fix Committed → Fix Released |
Salvatore (george-raul) wrote : | #80 |
Still happens, under Mac OS X 10.7.2 and Inkscape 0.48.2 r9819...
su_v (suv-lp) wrote : | #81 |
@Salvatore - that's (different) known issue tracked in
Bug #819209 in Inkscape: “Extensions do not work with Mac OS X Lion”
<https:/
Salvatore (george-raul) wrote : | #82 |
Oh I'm sorry, it is this one instead https:/
thomas (tblond) wrote : | #83 |
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) wrote : | #84 |
#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:/
Jan-Peter (ftjp) wrote : | #85 |
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) wrote : | #86 |
> 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) wrote : | #87 |
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
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> thread. gmane.org/ gmane.comp. graphics. inkscape. devel/31846>
[2] <http://