Re: String codification

[Ondřej Hošek]

On Fri, Feb 24, 2012 at 06:25:05PM -0600, Germán Arias wrote:
> Well, I tested today in a Windows 7, but with UTF16 don't works, so
> I tried with  WindowsCP1252 and works fine. But I don't know if this
> encoding can be problematic for other languages. I did this change
> at line 302 in file WinNSMenu.m. Are there objection to do this
> change?

While I am not a GNUstep developer (and my opinion may therefore be
uncalled for), I do have a small gripe with this, since, as you
guessed, CP1252 can be problematic for other languages.

The reason UTF-16 didn't work is simple: Windows ships two versions of
any function or struct that stores a string. One of them ends with A
(for "ANSI"), the other with W (for "wide"). When the ANSI version of
the function is called, whatever codepage the user has chosen is used.
(For speakers of Spanish, French and Portuguese, this is CP1252.) The
Wide version, on the other hand, allows UTF-16. The argument type,
however, is also changed: where the ANSI version takes chars (and
types derived from char), the wide version takes wchar_ts.

Now, by default, if you call a function without the character width
suffix, the ANSI version is taken unless the macros UNICODE and
_UNICODE are defined. Of course, the ANSI functions choke on UTF-16
at least due to the NUL bytes they see.

The solution is to fetch the UTF-16 version of the string
(NSUnicodeStringEncoding), type-pun it from a const char * to a
const wchar_t *, and pass it to AppendMenu, changing the called
function from AppendMenu to AppendMenuW. (By explicitly using the
width suffix, it is guaranteed that the Wide version is called,
regardless of whether UNICODE or _UNICODE are #defined.)

Hope that clears things up.

Cheers,
~~ Ondra