Created attachment 21490 [details] Zip'd example .ps file I have many *undreds) of documents (small -> huge), that I compile to PDF using .tex -> .dvi -> .ps -> pdf. Last step via gswin64c.exe. Problem has arisen in the update I tried this morning from GS 9.53.3 -> GS 9.54. Documents that convert from .ps -> .podf without any problems using 9.53.3 now throw an error using 9.54.0. Alas, the error is not in an of itself particularly informative: 'Process has been killed...' My call to gswin64c.exe uses the following arguments: -dBATCH -dNOPAUSE -dALLOWPSTRANSPARENCY -sDEVICE=pdfwrite -r1200 -dCompatabilityLevel=1.7 -dPDFSETTINGS=/prepress -dEmbedAllFonts=true So, perhaps one of these settings which works under 9.53.3 no longer 'works' under 9.54.0? When I throw the .ps file into Adobe Distiller, it tells me there is a problem with transparencies -- suggesting I try -dNOSAFER (which I did, but that made no difference). The frustrating/confusing part is that this happens for *some* conversions, but not all. Meaning (I guess) that for the failing .ps files, there is something in the code that is not playing nice with 9.54.0, but *did* play nice with 9.53.3. I've attached an example.ps file, hoping that might provide some insights. I'm happy rolling back to 9.53.3, but prefer to not fall too far behind current releases, if possible.
(In reply to evan.cooch from comment #0) > Problem has arisen in the update I tried this morning from GS 9.53.3 -> GS > 9.54. Documents that convert from .ps -> .podf without any problems using > 9.53.3 now throw an error using 9.54.0. Alas, the error is not in an of > itself particularly informative: > > 'Process has been killed...' That isn't a Ghostscript error (obviously) and I've never seen that particular message from Windows. To be honest it doesn't look much like a Windows message either. > I've attached an example.ps file, hoping that might provide some insights. > I'm happy rolling back to 9.53.3, but prefer to not fall too far behind > current releases, if possible. This looks like a duplicate of bug #703783 which was fixed in this commit: https://git.ghostscript.com/?p=ghostpdl.git;h=50dd527e638463fe036fec4b38915151aab9f940 Certainly the example file works for me without problems on Windows 10 with current code, and the process exits silently outside the debugger, or with an exception in the debugger with 9.54.0. *** This bug has been marked as a duplicate of bug 703783 ***
(In reply to Ken Sharp from comment #1) > (In reply to evan.cooch from comment #0) > > > Problem has arisen in the update I tried this morning from GS 9.53.3 -> GS > > 9.54. Documents that convert from .ps -> .podf without any problems using > > 9.53.3 now throw an error using 9.54.0. Alas, the error is not in an of > > itself particularly informative: > > > > 'Process has been killed...' > > That isn't a Ghostscript error (obviously) and I've never seen that > particular message from Windows. To be honest it doesn't look much like a > Windows message either. > > > > I've attached an example.ps file, hoping that might provide some insights. > > I'm happy rolling back to 9.53.3, but prefer to not fall too far behind > > current releases, if possible. > > This looks like a duplicate of bug #703783 which was fixed in this commit: > https://git.ghostscript.com/?p=ghostpdl.git; > h=50dd527e638463fe036fec4b38915151aab9f940 > > Certainly the example file works for me without problems on Windows 10 with > current code, and the process exits silently outside the debugger, or with > an exception in the debugger with 9.54.0. > > *** This bug has been marked as a duplicate of bug 703783 *** Thanks very much for taking a look. I tried a manual (CLI) compile of the sample .ps file, and while there was no error messages about 'Process has been killed' (which now seems perhaps to be some weird memory error with the editor I normally use), the PDF that gets generated was one I couldn't open using Adobe Acrobat. I had to resort to other PDF readers/viewers, while handled it fine. So, I remain puzzled, and perhaps not convinced the problem is indeed fixed. Anything I can provide form my end to suss things out, just let me know.
Created attachment 21526 [details] Output of example.ps with the supplied command line
> Thanks very much for taking a look. I tried a manual (CLI) compile of the > sample .ps file, I'm sorry but I don't understand what you mean here. I don't know what you mean by 'compile of the sample.ps file', nor what you mean by a 'manual (CLI)' compile. Have you taken the patch referenced in bug 703783, applied it to your local source tree and rebuilt ? If so then you need to be aware that what I tested is the current HEAD of our Git repository, it is entirely possible that there are other problems which have been fixed exhibited by this file and command line. I have attached the output I get using your command line and input file, with the current HEAD from our Git repository. > So, I remain puzzled, and perhaps not convinced the problem is indeed fixed. > > Anything I can provide form my end to suss things out, just let me know. Well, I am unable to reproduce any problem, and the output file opens for me in Adobe Acrobat X without complaint. The 9.54.0 release did indeed exit with an exception (invalid pointer IIRC), and the location was precisely the same as that in Bug 703783 which makes me think they are the same problem. This is all on Windows 10 using Visual Studio to compile, the 64-bit executable to test with and Acrobat Pro X to open the resulting file.
(In reply to Ken Sharp from comment #4) > > Thanks very much for taking a look. I tried a manual (CLI) compile of the > > sample .ps file, > > I'm sorry but I don't understand what you mean here. I don't know what you > mean by 'compile of the sample.ps file', nor what you mean by a 'manual > (CLI)' compile. Sorry for lack of clarity on my part. CLI compile means point gswin64c.exe at the .ps file, with arguments, to generate the PDF. I simply reinstalled 9.54 using the installer from the GS website, and used that gswin64c.exe > > Have you taken the patch referenced in bug 703783, applied it to your local > source tree and rebuilt ? If so then you need to be aware that what I tested > is the current HEAD of our Git repository, it is entirely possible that > there are other problems which have been fixed exhibited by this file and > command line. > > I have attached the output I get using your command line and input file, > with the current HEAD from our Git repository. OK - thanks. As per above, I didn't try a recompile with patch. If I get a chance, I will. > > > > So, I remain puzzled, and perhaps not convinced the problem is indeed fixed. > > > > Anything I can provide form my end to suss things out, just let me know. > > Well, I am unable to reproduce any problem, and the output file opens for me > in Adobe Acrobat X without complaint. The 9.54.0 release did indeed exit > with an exception (invalid pointer IIRC), and the location was precisely the > same as that in Bug 703783 which makes me think they are the same problem. > > This is all on Windows 10 using Visual Studio to compile, the 64-bit > executable to test with and Acrobat Pro X to open the resulting file. OK -- ruling out Adobe as part of the problem. Again, many thanks...
(In reply to evan.cooch from comment #5) > Sorry for lack of clarity on my part. CLI compile means point gswin64c.exe > at the .ps file, with arguments, to generate the PDF. I simply reinstalled > 9.54 using the installer from the GS website, and used that gswin64c.exe Ah, well nothing will have changed because the commit I referenced isn't in the 9.54.0 release, you will need to either wait for the 9.55.0 release or compile the Ghostscript source to get a 'prerelease' binary. > > This is all on Windows 10 using Visual Studio to compile, the 64-bit > > executable to test with and Acrobat Pro X to open the resulting file. > > OK -- ruling out Adobe as part of the problem. As far as I'm aware, there was a bug in 9.54.0, it has been fixed, output from 9.54.0 is definitely bad. > Again, many thanks... No problem, thanks for reporting the bug, it's not your fault someone beat you to it! We do appreciate people taking the time to make bug reports for us.