#1051 Inkscape check incomplete.

Metadata

Property	Value
Reported by	Robert K (robertk@posteo.org)
Reported at	Mar 16, 2012 09:47
Type	Bug Report
Version	Git (pre2.4) [autotools]
Operating System	Unspecified / All

Description

The configure check for inkscape is incomplete. It only checks whether inkscape is there, but not, if it could be executed successfully.

If this occurs, the whole config process crashes. On could also consider to disable inkscape conversion when documentation is disabled.

I have always wondered why we need the entire inkscape suite just to convert a few images. At least on my machine, 'convert' also does the trick.

Because convert didn't do the trick back when I introduced this check. And I suspect that convert either uses inkscape as a backend, or doesn't support some of inkscape's .svg features (like arrowheads).

But I'll have a look and see if it can reasonably be replaced with convert. If it cannot, I'll add a run-check.

Hi Jö, I doubt that convert uses inkscape. At least on my machine, the 'imagemagick' package (which contains 'convert') does not depend on anything that looks inkscape related. I don't know about the arrow heads, though.

Alright, I played around a little. convert seems to be sufficient for the svg->png case. You have to say "convert -backgound none a.svg a.png" to a an image with a transparent background (like it is produced by inkscape), otherwise the background will be white.

And you were right, at least on my system convert doesn't appear to use inkscape, as determined by strace.

There is some LaTeX-documentation though, that includes some of the figures from the .svg's. Currently these figures are converted to .eps from the .png's which is quite ugly since they get all pixelated. Is there any tool, besides inkscape, that can do the vector graphic conversion directly without reverting to a bitmap inbetween? convert can't, apparently.

@Robert: I can't exactly reproduce your original report.

I put a script in my path under the name 'inkscape' that immediately kills itself. The configure test discovers this skript as inkscape. But I cannot reproduce "the whole config process crashes", as you put it. For me it finishes successfully. And after that, 'make' runs through successfully too.

The only way I can trigger a failure is by touching one of the .svg files and then running 'make doc'. Was this what your report was about?

NB, I used dune-grid to try this.

Oh, and while I'm at it, what exactly do you mean by "could be executed successfully"? In which way exactly did it fail to execute on your system? Did it give a non-zero exit status, was it killed, did the shell discover that it didn't know how to actually run it when it tried to, or did it just silently fail to produce the desired output or any output at all?

inkscape failed because of some linking error. Of course this could be fixed but it just showed that the inkscape test was not working as one could expect.

To catch that it should be enough to test whether 'inkscape --version' exists successfully. I was afraid I would have to include an .svg file inside a .m4 file :/

I'm sorry, but I still cannot reproduce "the whole config process crashes". I downloaded a binary of paraview from unstable and installed it as /usr/bin/inkscape, with the result that calling inkscape now yields a linker error:

joe@paranoia:~$ inkscape inkscape: error while loading shared libraries: libvtkViewsPythonD.so.pv3.14: cannot open shared object file: No such file or directory joe@paranoia:~$

However, the configuration still runs through sucessfully, discovering inkscape as inkscape. Maybe the same breakage that caused inkscape to fail to execute caused the config process to crash via a different means? What happens if you e.g. say './configure INKSCAPE=no'? In that case inkscape should not be detected, but does configure still crash for you?

Remove the png files that have to be converted from inkscape and you are there.

I removed those .png files corresponding to .svg files, but I still can't get configure to throw an error. Did you, per chance, get the error in a later build phase and not 'configure' itself? I mean, it is obvious that there will be an error during 'make doc', but even the normal 'make' should work fine. If the error is indeed happening during 'configure' (or even 'make'), I'm going to need logs showing the error.

mentioned in issue #1256 (closed)

Added buildsystem label

It is related to the old buildsystem so it won't be fixed.

Status changed to closed