The customer reports: We’ve run across a potential issue while testing our Japanese Server 2003 VMs. When the attached postscript file is converted from a folder in the desktop, the GhostScript conversion attempt fails. After subsequent investigation it appears to have something to do with the combination of the Japanese characters in the file path and the length of the path. I was able to reproduce the error using the following path: C:\Documents and Settings\Administrator\デスクトデスクト
Created attachment 10332 [details] ps.log Log file, including command line and error message.
Added customer 32 to the list. Email rec'd 2013-12-09 No other information yet from that customer (request sent).
Removed customer 32. They just solved it themselves. Customer wrote: This problem cannot be reproduced using the command line, it is only manifested via the API. Basically, the arguments passed into ‘gsapi_init_with_args’ need to be passed in as UTF-8 encoded strings. I was able to modify the usage on our end to fix the issue. Simply trying to pass in a path such as “C:\Administratör” without encoding as UTF-8 will not work. We are still working to load a Japanese Windows Server 2003 to investigate the problem reported by customer #1. It may be worthwhile making sure that customer 1 is not passing in the path using gsapi_init_with_args, vs. the command line.
(In reply to comment #4) > Removed customer 32. They just solved it themselves. Customer wrote: > > This problem cannot be reproduced using the command line, it is only > manifested via the API. Basically, the arguments passed into > ‘gsapi_init_with_args’ need to be passed in as UTF-8 encoded strings. Technically, no. The arguments passed into gsapi_init_with_args should be encoded using the scheme given by the call to gsapi_set_arg_encoding. To quote from API.htm: gsapi_set_arg_encoding() Set the encoding used for the interpretation of all subsequent args supplied via the gsapi interface on this instance. By default we expect args to be in encoding 0 (the 'local' encoding for this OS). On Windows this means "the currently selected codepage". On Linux this typically means utf8. This means that omitting to call this function will leave Ghostscript running exactly as it always has. Please note that use of the 'local' encoding is now deprecated and should be avoided in new code. This must be called after gsapi_new_instance() and before gsapi_init_with_args(). If they are running on non-windows, calling gsapi_set_arg_encoding with GS_ARG_ENCODING_UTF8 (or not calling it at all), and then passing a non UTF8 encoded string, then clearly they are at fault. If they are running on windows, calling gsapi_set_arg_encoding with GS_ARG_ENCODING_UTF8, and then passing a non UTF8 encoded string, then clearly they are at fault. If they are running on windows, calling gsapi_set_arg_encoding with GS_ARG_ENCODING_LOCAL (or not calling it at all), and passing a string encodable in the current windows code page, then they can reasonably expect us to get it right. If they are running on windows, calling gsapi_set_arg_encoding with GS_ARG_ENCODING_LOCAL (or not calling it at all), and passing a string that is not encodable in the current windows code page, then we cannot be expected to cope.
Created attachment 10719 [details] screenshot.png My attempts to reproduce this using Windows 7 Ultimate with the Japanese language pack installed have not been successful (see the attached screenshot.png).
(In reply to comment #7) > Created attachment 10719 [details] > screenshot.png > > My attempts to reproduce this using Windows 7 Ultimate with the Japanese > language pack installed have not been successful (see the attached > screenshot.png). But your screenshot doesn't show an input file name. Likewise, this (on its own, without an input file): gs -sDEVICE=pdfwrite -o a.pdf does not show an error. Besides encoding issue, btw, some path API in windows has a rather ridiculously low limit of 128 *unicode* characters, and "C:\Documents and Settings\Administrator\デスクトデスクト" is close to half of that.
Robin suspect that commit 9a68412d171e5c998026a13dffcbc90ef9d477b9 may fix this problem.
Closing this bug since it's been two months since I contacted the customer recommending they apply the patch mentioned in comment #9 and they haven't responded.