PATH variable for extensions (problem on OSX)
I forked the discussion from "[Inkscape-devel] Re: Using Inkscape for scientific work" because this thread was becoming very large. I should have done it before.
On 24 nov. 05, at 19:34, Bryce Harrington wrote:
the first problem is to get these EPS in Inkscape. At least on OS X, EPS import does not work because Inkscape cannot find pstoedit or ghostscript, though they are installed from fink. Where does inkscape takes the PATH from? With my fink tree added to the PATH in .bashrc or .profile in my home (.profile is the default) it does not work. With uberconverter on the way I hope all this will be solved in a not- so-far-away future.
The path stuff in Inkscape is a bit limited; it works sufficiently on linux but I'd have been surprised if it worked out of the box on OSX. I think it still doesn't work reliably on Windows.
If you'd like to dig into this problem, here are a couple starting points.
First, there is a directory where config files for the extensions are located. On Linux this is in /usr/share/inkscape/extensions. These don't include path info but you may find it illuminating to review their settings and so forth.
I think that the solution is somewhere there. All these are of the form: <inkscape-extension> <name>Postscript Input</name> <id>org.inkscape.input.ps</id> <dependency type="executable">pstoedit</dependency> <input> [...] </input> <script> <command reldir="path">pstoedit -f plot-svg</command> <check reldir="path">pstoedit</check> </script> </inkscape-extension> So the problem is to find the "executable". If I link my executables from /sw/bin to /usr/bin everything works. So when the path is standard, all work as expected. The problem is to know where the "path" of reldir="path" is defined. I found some references to the inx files in src/extensions/extensions.cpp and some references to paths to but it's only the paths where to look for the extensions... In doc/extension_system.txt the inx file are said to be read at startup but I couldn't find where.
Second, the paths are set in the src/path-prefix.h file. There is a section for ENABLE_OSX_APP_LOCATIONS. If I were you, my first step would be to verify that this define is actually set correctly on your machine. If it is, then also doublecheck that the paths match up to what you have on your system.
these are set to find inkscape files (ui, tutorials, extensions... everything that is normaly in /usr/share/inkscape/) in the app bundle. It works fine.
Third, there is a little bit of path manipulation going on in src/main.cpp in the main() routine. See line 610 for instance, where the current homedir is set for WIN32. I don't see any OSX specific hacks there though.
The home dir is non standard in OSX but ~ works so I guess everything is alright. I have never had problem at least.
The whole thing might well be a shell problem rather than an Inkscape problem after all. The only problem from the inkscape side is: what "shell" is executed to give the PATH and at what level (user configuration files are apparently omitted)?
In addition, while looking at the inx files I remarked that to open an eps file Inkscape in fact does: eps --gs--> ps --pstoedit--> sk --sk2svg--> svg which implies that you have sketch installed in order to open (e)ps files. what is the reason not to do: eps --gs--> ps --pstoedit--> svg or even: eps --pstoedit--> svg ps --pstoedit--> svg which work (I changed my inx files and tested) except for the usual problem with ps to svg conversion (see the XML repair wiki page). If using sketch as an intermediate is better, could the dependency be conditional: with only ps and pstoedit, use them, when sketch is present, add the sketch step. it's a bit weird to have to install sketch to have ps import in inkscape...
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On Fri, 2005-11-25 at 11:10 +0100, jiho wrote:
So the problem is to find the "executable". If I link my executables from /sw/bin to /usr/bin everything works. So when the path is standard, all work as expected. The problem is to know where the "path" of reldir="path" is defined. I found some references to the inx files in src/extensions/extensions.cpp and some references to paths to but it's only the paths where to look for the extensions... In doc/extension_system.txt the inx file are said to be read at startup but I couldn't find where.
Well, for PATH we get it from the glib function, but I don't think that is all your problems. You might want to also look at whether relocatable binary support might work for you. It sounds like something that would work in that it should figure out that if /sw/bin is the binary, then /sw/share/inkscape is the share directory. I'm not sure if this support works with Mac OS X, but I would see no reason why it couldn't.
The home dir is non standard in OSX but ~ works so I guess everything is alright. I have never had problem at least.
Home directory path is also grabbed from glib.
In addition, while looking at the inx files I remarked that to open an eps file Inkscape in fact does: eps --gs--> ps --pstoedit--> sk --sk2svg--> svg which implies that you have sketch installed in order to open (e)ps files. what is the reason not to do: eps --gs--> ps --pstoedit--> svg or even: eps --pstoedit--> svg ps --pstoedit--> svg which work (I changed my inx files and tested) except for the usual problem with ps to svg conversion (see the XML repair wiki page). If using sketch as an intermediate is better, could the dependency be conditional: with only ps and pstoedit, use them, when sketch is present, add the sketch step. it's a bit weird to have to install sketch to have ps import in inkscape...
The reason for this is that I've been unable to figure out how many people have the plot-svg backend for pstoedit. Or, for that mater, how to test if it is installed. I've used that same path myself sometimes, but I think we tried to get it working for Bryce one night and were entirely unsuccessful. If you could figure those issues out, I'd be happy to switch.
--Ted
participants (2)
-
jiho
-
Ted Gould