Bug 694720 - Issue running on Japanese Windows
Summary: Issue running on Japanese Windows
Status: NOTIFIED WORKSFORME
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: 9.10
Hardware: PC Windows 2000
: P1 normal
Assignee: Marcos H. Woehrmann
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-18 09:24 UTC by Marcos H. Woehrmann
Modified: 2014-05-21 21:36 UTC (History)
3 users (show)

See Also:
Customer: 1
Word Size: ---


Attachments
screenshot.png (452.03 KB, image/png)
2014-02-21 16:12 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2013-10-18 09:24:19 UTC
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\デスクトデスクト
Comment 1 Marcos H. Woehrmann 2013-10-18 09:25:50 UTC
Created attachment 10332 [details]
ps.log

Log file, including command line and error message.
Comment 3 Ray Johnston 2013-12-10 08:32:50 UTC
Added customer 32 to the list. Email rec'd 2013-12-09

No other information yet from that customer (request sent).
Comment 4 Ray Johnston 2013-12-10 09:48:25 UTC
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.
Comment 5 Robin Watts 2013-12-11 07:48:19 UTC
(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.
Comment 7 Marcos H. Woehrmann 2014-02-21 16:12:35 UTC
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).
Comment 8 Hin-Tak Leung 2014-02-21 18:02:11 UTC
(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.
Comment 9 Marcos H. Woehrmann 2014-03-08 08:26:47 UTC
Robin suspect that commit 9a68412d171e5c998026a13dffcbc90ef9d477b9 may fix this problem.
Comment 10 Marcos H. Woehrmann 2014-05-21 19:52:45 UTC
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.