2013.03.21 14:22 "Re: [Tiff] TiffOpenW() not opening tiff file containing Japanese character", by Bob Friesenhahn
On Thu, 21 Mar 2013, Sunanda Chowdhary wrote:
> Thanks Edward and Bob.
> Yes I agree with you Bob. Just for sake of example I wrote that code snippet. I get NATIVE file path from OS API.
> As suggested by Edward, I tried opening the file using _wopen() and file is opened successfully. I tried using WideCharToMultiByte() to get char* path and then use TiffOpen(). This also fails. > Sorry if I missed, does Lib Tiff provide some error handling APIs as well?
You replied only to me rather than the whole list. Adding the list to
Libtiff provides the functions TIFFSetErrorHandler() and
TIFFSetWarningHandler() to support setting error and warning
callbacks, respectively. Since these are callbacks, you need to
immediately print or cache the reported error information since
libtiff continues execution (to point of return to your program) once
these functions return. Check the return status from libtiff
functions so that your program can quit processing on error.
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Bob Friesenhahn
> Sent: 21 March 2013 19:10
> To: Edward Lam
> Cc: email@example.com
> Subject: Re: [Tiff] TiffOpenW() not opening tiff file containing Japanese character
Which platform are you on? If you're on Windows with Visual Studio,
>> I've personally had problems with it recognizing UTF-8 string literals
like in the code you posted. I'd double-check what wname is actually
what you think it is. On Windows, you can confirm whether the file can
>> be opened by calling _wopen(wname, ...) and checking if you have a valid file.
The other idea is to ensure you have an error handler installed prior
to calling TIFFOpenW() and checking to see what is the error generated
>> by TIFFOpenW().
> From what I have read, the definition of a wide character is platform-dependent. I remember that Windows uses UTF-16 and OS X uses UTF-32.
Ultimately, the value needs to match the value used by the filesystem. any small encoding difference would cause a failure to match. A filename which "looks" the same might not be the same.
Some filesystems support multiple filename encodings and the filesystem remembers the encoding which was used.
The safest thing to do is to obtain the filename via an operating system API and pass that to libtiff.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/