| Summary: | ps2pdf in gswin32 has unexpected behaviour: PDF output overwrites PS input | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Mike Toews <mwtoews> |
| Component: | Other Driver | Assignee: | Ray Johnston <ray.johnston> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | alex, ken.sharp |
| Priority: | P4 | ||
| Version: | 8.61 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Customer: | Word Size: | --- | |
|
Description
Mike Toews
2008-02-03 14:27:46 UTC
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 *** |