[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Openexr-devel] UNICODE support in openexr file I/O
From: |
Luc-Eric Rousseau |
Subject: |
RE: [Openexr-devel] UNICODE support in openexr file I/O |
Date: |
Fri, 20 Jan 2006 12:03:24 -0500 |
> -----Original Message-----
> From: Drew Hess
>
> I (and, I'm pretty sure, Florian) don't really know the in's and out's
> of Windows's internationalization support. Are you saying that
> supporting UTF-8 filenames and StringAttributes would not suffice for
> international Windows users?
>
My apologies, I thought this is was only about file names.
For the issue of filenames, UTF8 support will not allow you to open
Japanese-named files on Windows.
On UNIX what's happening is that you're passing this string, it gets down in C
to 'fopen' and eventually to the OS and file system which recognizes the string
as a UTF8-encoded name.
Windows does not recognize UTF strings in API that take 'char *'. In the case
of 'fopen', there is an 'fopen' for ascii names, and 'wfopen' for wide-char
strings (which eventually call the OS's CreateFileA, CreateFileW). (It's
possible Visual C++ 2005 Run-time library's implementation of fopen has changed
and can recognize and convert UTF8 to WCHAR before calling the OS, but previous
versions do not)
I haven't comb the OpenEXR library closely, but if you use ifstream, there is
an equivalent wifstream.
Typically what people do is strategically place an #if defined(WIN32) &&
defined(UNICODE), and let the developer build a Unicode version of the library,
although it can indeed be handled by implementing a custom low-level I/O. I've
noticed however that the IStream has a method that returns a "const char *",
which would produce garbled error messages if you're using it to create error
message strings.
For saving attributes in a file, utf-8 really makes sense. Saving wchar_t is
not something one would do because its definition is not standard, it isn't
even the same size between between Windows (16 bit) and Linux (32-bit). It's
completely fine to use that type for function and method parameters at
run-time, however, it's standard c++.
- Re: [Openexr-devel] UNICODE support in openexr file I/O, (continued)
- Re: [Openexr-devel] UNICODE support in openexr file I/O, Florian Kainz, 2006/01/19
- Message not available
- Message not available
- Re: [Openexr-devel] UNICODE support in openexr file I/O, Bob Friesenhahn, 2006/01/19
- Re: [Openexr-devel] UNICODE support in openexr file I/O, Yves Poissant, 2006/01/20
- Re: [Openexr-devel] UNICODE support in openexr file I/O, Drew Hess, 2006/01/20
- Re: [Openexr-devel] UNICODE support in openexr file I/O, Yves Poissant, 2006/01/20
- Message not available
- Re: [Openexr-devel] UNICODE support in openexr file I/O, Daniel LĂ©onard, 2006/01/20
Re: [Openexr-devel] UNICODE support in openexr file I/O, Drew Hess, 2006/01/19
Re: [Openexr-devel] UNICODE support in openexr file I/O, Florian Kainz, 2006/01/19
RE: [Openexr-devel] UNICODE support in openexr file I/O, Luc-Eric Rousseau, 2006/01/19
RE: [Openexr-devel] UNICODE support in openexr file I/O,
Luc-Eric Rousseau <=
[Openexr-devel] UNICODE support in openexr file I/O, Santiago , 2006/01/23
RE: [Openexr-devel] UNICODE support in openexr file I/O, Nick Porcino, 2006/01/23