Summary: | eps2eps fails to convert EPS file to level 1 EPS file with "/syntaxerror in -file-" | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Rune Svendsen <runesvend> |
Component: | General | Assignee: | Default assignee <ghostpdl-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | 8.70 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: |
eps2eps.log
Envelope-Icon.eps.bz2 |
Description
Rune Svendsen
2009-09-09 05:56:14 UTC
Created attachment 5364 [details]
eps2eps.log
Output of eps2eps when trying to convert EPS file to level 1 EPS file
Please attach a copy of the original EPS file. It may be some time before this gets investigated and the file may not be accesible at that time. The EPS file is invalid. There's some HTML junk appended to the file. You need to delete everything from <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML to the end of the file to make the file a valid EPS file. Thanks for letting me know. I didn't think of checking the file when it opened fine in other programs. When cutting away what you mention (so the file ends with "PrivateDataEnd"), and running the aforementioned command on it (eps2eps -dLanguageLevel=1), the resulting file is still 127.6 MB in size and when I run the following command on the file: "pstoedit -f plot-svg", in order to convert it to an svg file, it seems that pstoedit hangs while writing to a temporary file (I stopped it after around 15 minutes when the temporary file had reached a size of 500 MB and it was still growing). Should I report this as a bug in pstoedit and leave this bug closed? Is it normal for level 1 EPS files to be almost 130 MB in size? eps2eps uses the epswrite device which is basically the same as the pswrite device. This device converts an awful lot of PostScript into low level primitives and often into images (especially text). Many operations are 'scan converted' and produce a long list of rectangles. All of this can produce extremely large files. Whether it is 'normal' depends almost entirely on the content of the original file. The fact that the temporary file was still growing when running pstoedit suggests to me that it had neither hung, nor crashed, it was simply still processing the input PostScript. Since pstoedit uses Ghostscript to interpret the PostScript you can always try opening the file with Ghostscript to see if that works. Why are you running the file through eps2eps, to get a level 1 file ? Why are you then running the converted file through pstoedit, wouldn't it make more sense to use the original EPS file ? I see, thank you for the explanation. The reason I'm converting to a level 1 file is because I read somewhere that the pstoedit program doesn't support higher than level 1 EPS files. And I took this to be true since it didn't work with my EPS file. But now that I've been told that there was HTML garbage in the end of the file, I've tried using pstoedit to convert the EPS file (with the HTML stuff removed) directly to SVG which doesn't produce errors (besides me missing a specific font). However, the resulting file doesn't exactly look like the source file. It's basically a little grey circle with a grey rectangle above it. I just tried opening the original EPS file (from which the HTML junk has been removed) with 'gs', and it displays fine. Pretty envelopes and everything. However, the output of the conversion to SVG with pstoedit produces the output explained above. Should I report a bug in pstoedit? Ghostscript has its own svg converter but it fails with SEGV when used on the sample file. gswin32c -sDEVICE=svg -dEPSCrop -sOutputFile=foo.svg Envelope-Icon.eps >nul 2>&1 SEGV is always a bug, even if it happens on a little-used device or a specially constructed file. I'm reopening the bug report. I believe the segfault occurs because the device stores the current color as a string in the device structure, and the garbage collector frees these strings because they're not enumerated. I'm unclear how to add such enumeration to a device structure. Running with -dNOGC there is no segfault, and the output looks something like the input, although not perfect. There are some halftone colour spaces (I think) which the svg device doesn't handle, in addition to the turning-everything-into-rectangles problem. Created attachment 5366 [details]
Envelope-Icon.eps.bz2
Sample file without HTML trailer.
The segfault with the svgwrite device should be resolved by r10067. There are still problems with this file, but the original intent was to get svg output, which now works for the most part. It would be nice to get things working better, but I don't have bandwidth to address them at the moment, so I'm closing the bug. Please reopen if you want any specific issues with the file addressed. |