Hi, Please see attached bug, which I originally found through MiKTeX GPL Ghostscript, but have verified in the latest version of GPL Ghostscript (not from MiKTeX). ------------------------------------------------------------------------ Symptoms: Attempting to convert a ps file to pdf using ps2pdf command overwrites PDF output to PS input file. This behaviour was first encountered while using ps4pdf in MiKTeX 2.7, and can be reproduced in GPL Ghostscript 8.61 from cmd.exe (using example pstricks-example-pics.ps): > ps2pdf -dAutoRotatePages#/None pstricks-example-pics.ps After this command, pstricks-example-pics.ps is now a PDF file (overwritten original), and pstricks-example-pics.pdf is not created (as would be expected). It is important to note that the typical usage (without -dAutoRotatePages#/None) works as expected; particularly: > ps2pdf pstricks-example-pics.ps where pstricks-example-pics.ps is not overwritten and pstricks-example-pics.pdf is created, as expected. ------------------------------------------------------------------------ Ghostscript version (or include output from "gs -h"): GPL Ghostscript 8.61 (2007-11-21) ------------------------------------------------------------------------ Where you got Ghostscript: http://pages.cs.wisc.edu/~ghost/doc/GPL/gpl861.htm for 32-bit Microsoft Windows or gs861w32.exe ------------------------------------------------------------------------ Other comments: As noted previously, the ps4pdf command under MiKTeX command does not work properly, due to the error in ps2pdf. The pstricks-example-pics.ps file can be made with latex using the following TeX source file, named "pstricks-example.tex": \documentclass[11pt,oneside]{article} \usepackage{pst-pdf} \begin{document} Top of page. \begin{figure} \begin{pspicture}(0,0)(6,6) %\psgrid[gridcolor=lightgray,gridlabels=0pt] \psline[linecolor=red](1,1)(5,1)(1,4)(1,1) \pscurve[linecolor=green,linewidth=2pt,% showpoints=true](5,5)(3,2)(4,4)(2,3) \pscircle[linecolor=blue,linestyle=dashed](3,2.5){1} \end{pspicture} \caption{The PSTricks figure should be here} \end{figure} \end{document} From cmd.exe: > latex pstricks-example.tex > dvips -o pstricks-example-pics.ps pstricks-example.dvi End of report. Thanks! +mt
You can specify the output file explicitly to work around this bug. Batch programming is like shell programming -- with your hands tied behind your back. I don't think this problem can be solved without using Ghostscript (what else?) to parse the arguments. Current batch file generates the following arguments: -sOutputFile#foo.ps -c .setpdfwrite -f -dAutoRotatePages#/None The arguments are syntacticly correct and Ghostscript proceeds to write an empty PDF file into foo.ps. By using -f-dAutoRotatePages#/None we can escape the special meaning of the leading dash and get an /undefinedfilename in (-dAutoRotatePages#/None) before trashing foo.ps
I'll take a look at fixing this, but I'd like to make .setpdfwrite implicit. It seems like it could be similar to the way we hook the DSC comments ONLY when the device is pdfwrite.
A partial fix based on the comment #1 ic committed as a rev. 8547. http://ghostscript.com/pipermail/gs-cvs/2008-February/008131.html The patch doesn't fix the bug but prevents input file corruption and makes the failure mode easier to understand and work around.
Do we really still need .setpdfwrite ? I never use it and I don't see any ill effects. All it apparently does is set a large VM threshold: /.setpdfwrite { % - .setpdfwrite - % Set a large VM threshold to reduce garbage collection. currentuserparams /VMThreshold get 3000000 .max setvmthreshold } bind def I'm not sure how useful this really is and would be inclined to drop it.
Removing the recommendation for /.setpdfwrite is reasonable. Unfortunately, about all we can say is that it is 'deprecated', but we can't remove it immediately without warning since it would break clients that use this in their own invocations of gs to generate PDF's. It doesn't hurt having it, but I'd recommend just removing the contents and keep the procedure with a comment in the source that it is no longer needed.
(In reply to comment #5) > Removing the recommendation for /.setpdfwrite is reasonable. Unfortunately, > about all we can say is that it is 'deprecated', but we can't remove it > immediately without warning since it would break clients that use this in > their own invocations of gs to generate PDF's. Oops! Sorry I wasn't clear, I just meant removing its use from the scripts :-) I wasn't proposing removing the operator at this time, not even just removing the contents....
This problem has been fixed by the following revision: ------------------------------------------------------------------------ r11743 | alexcher | 2010-09-24 22:08:22 -0400 (Fri, 24 Sep 2010) | 4 lines For long time ps2pdf*.bat files failed when they were used with some options and a single argument. findstr is now used to identify options by the leading '-' and handle this case. New scripts require Windows NT or higher. Bug 691622. The merits of .setpdfwrite and its usage in the scripts is not significant for argument parsing. *** This bug has been marked as a duplicate of bug 691622 ***