Runtime Error when loading specific .eps file

the file itself is fine, it is viewable using GSView32.

running Win32 nightly build May 2.
In order to view this file in Inkscape you need pstoedit in the path.
When I do that, I get a crash with the DOS message:
C:\Python25\APP>python inkcl.py
return code: 3
terminate called after throwing an instance of 'Glib::SpawnError'

Emergency save activated!

backtrace follows:

(gdb) symbol-file inkscape.dbg
Reading symbols from C:\Program Files\Inkscape/inkscape.dbg...done.
(gdb) run
Starting program: C:\Program Files\Inkscape/inkscape.exe
[New thread 3620.0x9c8]
[New thread 3620.0xc6c]
[New thread 3620.0xf58]
[New thread 3620.0xd7c]
[New thread 3620.0xcec]
[New thread 3620.0xdfc]
warning: Lowest section in C:\WINDOWS\system32\xpsp2res.dll is .rsrc at 20001000

warning: Lowest section in C:\WINDOWS\system32\odbcint.dll is .rsrc at 20001000
[New thread 3620.0xe00]
[New thread 3620.0xca8]

Program exited with code 03.
(gdb) bt
No stack.

> terminate called after throwing an instance
> of 'Glib::SpawnError'

The runtime error is due to an uncaught exception. See bug 173116 for what seems to be the root cause.

For *why* there is an exception you could try the import steps by hand: run pstoedit and open the resulting svg file.

yes, if I run pstoedit directly from a DOS prompt then the conversion to svg works well, with no error messages.
the resulting .svg file loads well into Inkscape with no errors.

attached is an .eps file.
it causes an identical crash when loaded, because it also uses pstoedit as an extension

this sounds very similar to the situation that existed with uniconv, see Bug 197617
Is it possible that the uniconv-ext.py file could be modified to deal with pstoedit just like it did with uniconv?
what is the origin of this file?

uniconv-ext.py is something I wrote to replace a shell script that didn't work on Windows. That specific problem (a shell script) doesn't exist in the case of EPS import, and I don't know why EPS import is crashing on Windows. A Python script could no doubt solve this too, but there might be a better way.

As an experiment I took the file uniconv-ext.py and modified it to be pstoedit-ext.py and replaced uniconv with pstoedit everywhere in the file and it worked perfectly, I was able to import both .ps and .eps with it after changing the .inx files as well.
However, there may be an easier way...

fwiw, when I run this modified file I get the following message, even though the import was successful and I am not aware of any explicit references to pythonw

C:\Python25\APP>python inkcl.py
** Message: Found local interpreter, 'C:\Program Files\Inkscape\python\pythonw.exe', Size: 24576

C:\Python25\APP>python inkcl.py
** Message: Found local interpreter, 'C:\Program Files\Inkscape\python\pythonw.exe', Size: 24576

That's not really a problem, just the dumb behaviour of Inkscape under Win32 whenever it makes a call to python. It wants to fire up a command window just to say it's found the windows version of python every time, even when using the windows version of python (pythonw.exe), which is meant to run in quiet mode. That is the cause of the problem where the DOS prompt pops up briefly and disappears, but since you're running Inkscape from a command window anyway, it doesn't just pop up. This message should really divert to stderr or something similar, but someone with more programming ability than me will need to fix that.

just confirming that the same crash occurs under the original release of Inkscape 0.46 for windows

if I modify the .inx file to have a dependency on a python file as well, and if that python file consists of the following 2 lines of code :
import sys, subprocess
subprocess.Popen('pstoedit -f plot-svg "%s"' % (sys.argv[1]))

then the pstoedit program appears to execute normally and it appears to generate proper svg output, and that output shows up in the popup DOS window for one second and then disappears.

So there seems to be some confusion as to who is "stdout"
There are in this case no crashes and no unusual messages other than the message saying "Failed to Load"

In view of the discussion in Bug 190424 involving .eps, it sounds like it might be better to first solve the .pdf import crash, Bug 229524 , and then consider trying to use ghostscript 8.61 instead of pstoedit.

However, apart from that, it is possible that the problem with pstoedit may be that it generates a one-line header on every output, namely :
pstoedit: version 3.45 / DLL interface 108 (build Sep 10 2007 - release build - MS VC++ 1300) : Copyright (C) 1993 - 2007 Wolfgang Glunz
This header does not show up in the svg file if it is specified, but it does show up in stdout.
Other programs, such as wmf2svg, for example, do not generate this header, and I know that I have successfully run wmf2svg directly from an .inx file into Inkscape with no .py file.

attached is a response from Wolfgang Glunz in response to a question about the first line.
It appears that the first line goes to stderr and not stdout, so all that is needed is to make sure that these two devices are not the same.

.....................................................................

X-RCPT-To: <email address hidden>
From: "Wolfgang Glunz" <email address hidden>
To: "'Alvin Penner'" <email address hidden>
Subject: RE: pstoedit first line of output
Date: Thu, 22 May 2008 20:39:37 +0200
Organization: none
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
Importance: Normal
Thread-Index: Aci5KJphxPeS4kirRRSlOvhzKYf21QDAFmsg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-Provags-ID: V01U2FsdGVkX1/wJLotflkY0RxtjW3blfRUJfm09Gt6oGlIwoo
 3KIA6QTrdtDJ4rB5WVvVjCJelewh6RPQWIXdodfngtaxDe1meU
 yVslyUsa4DSq6YcGcDKXQ==
X-UID: 10736

Hi Alvin,

Short answer - "no this is currently not possible".
Long answer. I wonder why this hasn't come up before. Inkscape is using
pstoedit for years already. Further, I wonder whether this is really a
problem since the line is being written to stderr and not stdout.
However, one know problem is slightly related to this. Some PostScript files
write some diagnostic messages to stdout. These messages then also appear in
the output stream which then usually causes the output to be scrambled.
Luckily, such cases are rare.
One option would be to write the normal output always to a temporary file
and redirect the "rest" to nowhere and then flush the content of the temp
file to stdout. However, this somehow violoates the Unix pipe paradigm,
since the first line of the result output would come only after the whole
file has been processed. With the current implementation, the output is
written to stdout as it is produced hence allowing some sort of pipelined
processing.
Coming back to the first line issue. Of course, I can add an option to
suppress this first line but as explained, it solves either a non-problem or
only half of the problem.

Best Regards

Wolfgang

> -----Original Message-----
> From: Alvin Penner [mailto:<email address hidden>]
> Sent: Sunday, May 18, 2008 10:47 PM
> To: <email address hidden>
> Subject: pstoedit first line of output
>
>
> Hello Dr. Glunz,
> First of all, thank you very much for your product
> pstoedit. I have been using it to convert to .svg and it is
> extremely useful. I am running on Windows so I have no other
> support for postscript other than pstoedit.
> I have a question about running it from a script file :
> is it possible to suppress the output of the first line which
> normally says:
> pstoedit: version 3.45 / DLL interface 108 (build Sep 10 2007
> - release build - MS VC++ 1300) : Copyright (C) 1993 - 2007
> Wolfgang Glunz
> What I am trying to do is use pstoedit to import files
> into Inkscape (http://www.inkscape.org/). Inkscape has a
> system of extensions, one of which tries to do a file import
> from pstoedit using the command :
> <command reldir="path">pstoedit -f plot-svg</command>
> Both input and output are the default stdin and stdout,
> but the stdout appears t...

Using pstoedit 3.45 on Windows XP, I find that that the copyright message goes to stdout, and not to stderr. For example,

  pstoedit -f plot-svg -ssp in.eps out.svg 2> NUL

prints the message, while

  pstoedit -f plot-svg -ssp in.eps out.svg > NUL

doesn't.

In any case, because of what Wolfgang Glunz says about some PostScript files writing to stdout, we should write to a temporary file, like we do for UniConvertor.

By the way, I've realised that I shouldn't have used the subprocess module in uniconv-ext.py, as it isn't included in Python 2.3 (which we still need to support, if only for OS X). So I'll redo uniconv-ext.py to use os.popen3() instead, and we can handle pstoedit in the same way.

sounds great !
it's good to finally get some understanding of what's going on here, makes me wonder just how long some of these things were broken...
in any event, thanks for doing this.

Here's a Python script for EPS input. To use it, unzip the zip file into the Inkscape extensions directory. This will overwrite three existing files, and add two new ones.

This fixes plain PostScript import too, as that was also crashing (on Windows).

There was a lot of code duplication between this new script (pstoedit-ext.py) and uniconv-ext.py, so I ended up moving almost all of it into a separate module. So pstoedit-ext.py and uniconv-ext.py are little more than one-liners now.

Thanks for another excellent patch! I applied it but with a change: as discussed on the list, I switched PS and EPS input to using ps2pdf from Ghostscript and then importing PDF via a helper extension, and also fixed run_command to handle binary output file. Works fine for me, please test.

BTW if you don't yet have devel access, let me know your sourceforge handle and I'll set you up. Thanks!

Just tested this with the latest SVN. Seems to be problematic with bulia's latest changes.

When I select File->Import, no dialogue pops up until I click on the Inkscape window, as if it was already up, but somehow behind in window order. Then the images all import as blank.

If I overwrite the files from SVN with the zip from sas, the dialogue comes up immediately on top. It also doesn't use the PDF import dialogue, but ps2edit, which complains that "This application has failed to start because CORE_RL_Magick++_.dll was not found. Re-installing the application may fix this problem.", and yet it still imports the same images fine that came up blank with the current SVN versions.

HTH.

just downloaded win32 build Inkscape0806131634.7z and implemented patch Bug227449.zip.
Both .eps and .ps import appear to work fine, thanks for the fix!
There is a significant difference in the size of the image, depending on whether File | Open is used, or File | Import is used, but that is outside the scope of this discussion.
- don't have the very latest version, so will check back later...

Like Rygle, I was getting blank pages with Bulia's version. The problem was that, in Windows, stdout is set to text mode by default, which will corrupt most PDF files. I've fixed this in SVN revision 18918.

Rebuilt and everything seems good now on Windows. Great work sas and bulia!

Still need some Linux and Mac testing on this, I think.