Summary: | language switch build can't process pdf files on windows | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Hin-Tak Leung <htl10> |
Component: | Language Switch | Assignee: | Henry Stiles <henry.stiles> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | bountiable |
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows Vista | ||
Customer: | Word Size: | --- |
Description
Hin-Tak Leung
2010-08-26 08:41:26 UTC
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. |