The follow works on unix systems (and also works for tiger.eps on windows), but does not work on vista: >language_switch\obj\pspcl6.exe gs\examples\annots.pdf Unrecoverable error: undefinedfilename in run Operand stack: C:UsersHin-TakAppDataLocalTemp_te1085.tmp r PDF interpreter exited with exit code -22 Flushing to EOJ Unrecoverable error: stackunderflow in dup Unable to close out POSTSCRIPT instance. >language_switch\obj\pspcl6.exe -sDEVICE=pdfwrite -sOutputFile=a.pdf gs\examples\annots.pdf Unrecoverable error: undefinedfilename in run Operand stack: C:UsersHin-TakAppDataLocalTemp_teC74.tmp r PDF interpreter exited with exit code -22 Flushing to EOJ Unrecoverable error: stackunderflow in dup Unable to close out POSTSCRIPT instance. It appears that on windows, the language switch build can't process pdf's - some problems with temp files, it looks like. examples\tiger.eps works, so it seems to apply to pdf's.
This is svn head. (there does not appear to be any pspcl6 win32 binaries available for 8.71 or earlier ghostpdl's).
Assigned to Ken, if it is a language switch code issue please re-assigned to Henry.
Assigning to Henry. If the filename returned from gp_open_scratch_file in psitop.c:ps__impl_process contains '\' characters as path separators, then when ps_impl_dnit_job tries to run the PDF file the following will produce an incorrect path: /* run the temporary pdf spool file */ sprintf(buf, "(%s) run\n", psi->pdf_file_name); PostScript uses the '\' character as an escape (similar to C, but different) and so the path: C:\Users\Hin-Tak\AppData\Local\Temp\_teC74.tmp gets seen by the PS 'run' operator as: C:UsersHin-TakAppDataLocalTemp_teC74.tmp This is easily fixed by encoding the string as hex and enclosing it in '<' and '>' so the example would become: <433a5c55736572735c48696e2d54616b5c417070446174615c4c6f63616c5c54656d705c5f74654337342e746d70> run The only other solution would be to process the string and fix any characters that need a '\' prefix, eg. print the string as: (C:\\Users\\Hin-Tak\\AppData\\Local\\Temp\\_teC74.tmp) The first is probably easier to code.
BTW, an (untested) work around is to set the TEMP environment variable to a path with '/' characters instead of '\' as in: set TEMP="C:/Users/Hin-Tak/AppData/Local/Temp/" You could also set TMPDIR. If both are defined, TMPDIR takes precedence (see base/gpmisc.c:gp_gettmpdir)
Hin-Tak if you post a tested patch using Ray's hex encoding scheme we'll pay you a P4 bounty - you did discover the problem. I'll fix it if you don't want to do it.
(In reply to comment #5) Presumably this "shouldn't-happen" issue needs to be fixed before the new release? Either of Ray's suggestion sounds straight-forward enough, but I really have other priorities for another few weeks, so feel free to fix it yourself sooner. I am still have an eye out on Bug 691511 (nsis) and filed this bug on the way mostly because I am also using nsis for something else.
Add bountiable keyword so anyone can collect on this really easy one.
I'd just comment for somebody else wanting to have a go at this - postscript hex-encode is probably preferred as it might be possible for some locales (SJIS or big5?) to use "\" as 2nd byte of a multi-byte character in a file name. Not that it currently works faultlessly - there are a few open bugs about non-ascii input file names, etc.
Fixed in rev 11663.