Bug 695184 - Error: /undefinedfilename
Summary: Error: /undefinedfilename
Status: RESOLVED WORKSFORME
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: 9.14
Hardware: PC Windows 7
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-24 02:07 UTC by Harry McKame
Modified: 2014-04-24 07:18 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
PDF file with problem (4.26 MB, application/pdf)
2014-04-24 02:07 UTC, Harry McKame
Details
screen capture of error message (40.52 KB, image/jpeg)
2014-04-24 02:08 UTC, Harry McKame
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harry McKame 2014-04-24 02:07:37 UTC
Created attachment 10849 [details]
PDF file with problem

The attached PDF file file works fine without parameters by causes "Error: /undefinedfilename" when run with the following parameters :

"C:\Program Files (x86)\gs\gs9.14\bin\gswin32.exe" "-IC:\Program Files (x86)\gs\gs9.14\lib;C:\Program Files (x86)\gs\gs9.14\fonts" -dNOPAUSE -dBATCH -dSAFER -sDEVICE=jpeg -dEPSCrop -f -q -dTextAlphaBits=4 -dUseCropBox -dDOINTERPOLATE -sOutputFile="%%d.jpg" "Michelin_Dossier de Presse_Commémorations Guerre 14-18.pdf"

PDF file and screen capture are attached.
Comment 1 Harry McKame 2014-04-24 02:08:21 UTC
Created attachment 10850 [details]
screen capture of error message
Comment 2 Ken Sharp 2014-04-24 04:26:35 UTC
It would help a lot if you could try cutting down the parameters to just those which cause a problem.

You have specified -dEPSCrop and -dUseCropBox, which doesn't make sense. EPSCrop isn't going to have any effect with a PDF input file, and you shouldn't try to specify multiple crops anyway. 

You have specified two '%' characters in the -sOutputFile, this will escape the second '%' and cause the output to be written to a single file called '%d.jpg' which almost certainly isn't what you want.

You have specified -f without a preceding -c so it has no effect.

You don't need to supply these parameters :
"-IC:\Program Files (x86)\gs\gs9.14\lib;C:\Program Files (x86)\gs\gs9.14\fonts"

as these are already built-in to the GS executable. If you do decide to include them then you should specify them as -I"...", ie put the command line switch *before* the quotes.

Having said all that, running the exact command line given, on Windows 7 and using the 9.14 32-bit release, the file runs to completion for me without error. 

The error message makes it clear that the source file can't be found, and there are two 'unusual' characters in the filename '\303\232' (decimal values 195 154) yet the filename only contains one unusual character, e acute. I'd have to guess that the input filename is not correct.

Try copying the file to a new name which doesn't include the eacute, if that works, then this would seem to be the problem.
Comment 3 Harry McKame 2014-04-24 05:54:59 UTC
Thanks for your comments.

Just to defend my honor:
* Both -dEPSCrop and -dUseCropBox are used since we use the same software for PDF and EPS.
* The double '%%' is necessary since the command-line is in a .bat file.
* The other parameters were remnants of the past and are now deleted. Thanks.

I think you have exactly pointed to the problem, which is the accented character in the file-name.

We thought that GS uses UTF8 internally, so we passed GS the file-name in UTF8. The file will not be found if opened in Windows using an ANSI call, which is what I think that GS does.

If GS opens the file using (for example) the CreateFileA() function, ANSI variant of CreateFile(), then the open will fail.

If you used instead the CreateFileU() function (Unicode-16 variant), then either :
1. I would pass a Unicode-16 string that GS uses as-is, or
2. I pass a UTF8 string that GS converts to Unicode-16.

What is the solution for accented characters in the file-name?
I have found in your knowledge base the advice to rebuild GS with USEUNICODE=1. Is that still the case or do you have a ready-made binary?
Comment 4 Harry McKame 2014-04-24 07:05:45 UTC
Remark: A very simple workaround of using accented characters with an ANSI program, is to use the short form of the file name (8.3).

This is described in  http://support.microsoft.com/kb/142982
Comment 5 Ken Sharp 2014-04-24 07:08:28 UTC
(In reply to comment #3)
> Thanks for your comments.

> Just to defend my honor:
> * Both -dEPSCrop and -dUseCropBox are used since we use the same software
> for PDF and EPS.

You really ought to change the command line then so that you use one switch for each. While I don't know of any likely problems with these two switches interacting I can't rule it out either.


> * The double '%%' is necessary since the command-line is in a .bat file.

Yes, that makes sense, it doesn't work well if you run directly from the command line though, which is what I was doing.

 
> We thought that GS uses UTF8 internally, so we passed GS the file-name in
> UTF8. The file will not be found if opened in Windows using an ANSI call,
> which is what I think that GS does.

The short answer there is 'its complicated', and it depends on which operating system you are using and how you use the Ghostscript library. Broadly speaking, on Windows, we use wide-characters for filenames.


> What is the solution for accented characters in the file-name?

Well for me, running on Windows 7, using the executable that we build and ship, the file works absolutely fine using the original command line, so I would say that the solution is that it 'just works'. As far as I know it also 'just works' with more exotic languages such as Chinese as well. We did recently have some problems with temporary directories which contained non-Latin characters but I believe these were all resolved in the 9.14 release.

> I have found in your knowledge base the advice to rebuild GS with
> USEUNICODE=1. Is that still the case or do you have a ready-made binary?

Are you building Ghostscript yourselves from source ? That might explain the discrepancy, I'm using the binary we release, you can pick it up from here :

http://www.ghostscript.com/download/gsdnld.html
Comment 6 Harry McKame 2014-04-24 07:17:36 UTC
"It just works" because, as in my previous remark, Windows converts the file-name for you.

Many thanks for your help - much appreciated.
Comment 7 Chris Liddell (chrisl) 2014-04-24 07:18:52 UTC
USEUNICODE=1 is now the default.

IIRC, you should pass the filename in wchars (you need do no conversion), and we'll convert automatically to UTF8 for our internal use, and then back to wchars in the platform specific file handling code.

If you use the API, rather than the exe, things might be slightly more complicated.