SVG import / export status ?

[Korab]

Hello,

Can you try running the filter from the command line, e.g.

xarasvgfilter -i -f inputfile.svg > outputfile.xar
Gerry

Done (with full path) reply :

Segmentation fault

[Korab]

OK works, (but I can't use polish letters in name of directory)

Polish letters = Segmentation fault on reply

Size rectangle not same (154,61/115,90 mm on Inkscape, and 192,5/144,1 mm on Xara

[GerryI]

Does the -c version of the command also seg fault with Polish filenames?

It sounds like we have a general problem in the handling of unicode filenames. I'll try to find out why...

Gerry

[jedfrechette]

If you have an unusual location for the installation (i.e. not /usr/ with /usr/bin/xaralx) this could also be your problem.

Ah, this was my problem. I added symbolic links to xarasvgfilter and xarasvgfilterui in $HOME/bin (which is on my $PATH) and everything works nicely.

I was under the, apparently mistaken, assumption that binreloc would take care of finding the executables in xaralx/bin/ as well as the resources in xaralx/share/.

In any case, I'm glad to have this working. Thanks to all for your help.

[Odat]

Ah, this was my problem. I added symbolic links to xarasvgfilter and xarasvgfilterui in $HOME/bin (which is on my $PATH) and everything works nicely.

I was under the, apparently mistaken, assumption that binreloc would take care of finding the executables in xaralx/bin/ as well as the resources in xaralx/share/.

In any case, I'm glad to have this working. Thanks to all for your help.

Not entirely mistaken, because that's where I have my xaralx installed, and it works fine on this computer without my having to create any links. On my work computer however, it doesn't work for beans. When I get in today I'll see if these suggestions fix anything.

[Korab]

It sounds like we have a general problem in the handling of unicode filenames. I'll try to find out why...

Gerry

No, filenames works fine, directory names (with polish letters utf-8) not.

[Korab]

My path ~/.local/bin was added to local path (~/.bashrc). On terminal conversion works fine, on Xara import not working. Why ?

[Odat]

I may have a possible explanation for why this sometimes works and sometimes doesn't.

I have installed the same autopackage revision r1690 both here and at home, and while SVG import works just fine from home, at work it doesn't at all (tells me the file may not be SVG, and then reports that the filter reported an error with no message).

Doing some testing, I indeed discovered that if I symlinked the svg filter binaries to a directory on the path, the filter worked.

I happened to notice that at home, $(HOME)/.local/bin was a part of my path, but I wasn't the one that added it. So I checked and discovered that autopackage crammed a line into the end of my .bashrc for me.

I then checked at work, and lo and behold, $(HOME)/.local/bin is in the path as well, for the same reason. And yet, I have to symlink the binaries into a different directory on the path in order to get it to work.

So that's when the penny dropped. You can probably guess what's coming. A quick check of the uptime on my work computer shows that I've been running the same login session since the first time I installed autopackage. This isn't the case at home, as I had to reboot recently during a kernel upgrade.

Here at work my window manager hasn't been restarted in so long that as far as it's concerned, $(HOME)/.local/bin isn't in the path, so anything that it launches also doesn't know. If I launch xaralx from a terminal, it works just fine.

So, I shut down the window manager, did a ". ~/.bashrc" and restarted it, and now things work just dandy.

I'd say that anyone that installed the autopackage as their own user that has problems with SVG import should first try launching the binary from a terminal (if that's not how you're already doing it) and see if that fixes the problem. If so, you may be experiencing the same problem. Nothing a logout-then-login can't cure!

[abligh]

I was under the, apparently mistaken, assumption that binreloc would take care of finding the executables in xaralx/bin/ as well as the resources in xaralx/share/.

It should do this. I'm interested to know why it doesn't work (assuming deleting preferences didn't help). What it was doing before r1692 was "corrupting" the preferences by sticking a path in there all the time, so if you installed a new version it wouldn't work.

It should not need to be on the path. If it does need to be on the path, that's a bug we need to fix. In fact I'd go further: it shouldn't use the path at all, and if that fixes it, there's something else broken.

Alex

[abligh]

I may have a possible explanation for why this sometimes works and sometimes doesn't.

I then checked at work, and lo and behold, $(HOME)/.local/bin is in the path as well, for the same reason. And yet, I have to symlink the binaries into a different directory on the path in order to get it to work.

The only thing I can think is happening here is that something had the old stuff's inode cached (i.e. the bash shell had the inodes of the directories on the path cached on the version that didn't work). You said it (somehow) had got onto the path on both machines. This would imply the difference is actually the version of LX you were running. So you thought you were running r1692 (having installed it) but actually you weren't. This would have the additional amusing consequence of breaking the preferences every time you run it.

The only other explanation for this making a difference is binreloc failing (assuming it's not the preferences bug). It should not matter one jot whether LX is on the path provided you can run it (and adding things to your path is precisely why I hate things like autopackage). That's because what binreloc does is (effectively) take the path to the binary (from /proc/self), remove the "/bin/xaralx" and add "/share". So provided it's passed a path ending "/bin/xaralx" it should work fine.

Alex