On Thu, Dec 12, 2002 at 11:14:42PM -0800, Guy Harris wrote:
> 2) As long as we're going down that path, should we store *all*
> strings as Unicode in the protocol tree, and just keep the
> existing FT_STRING types, and:
>
> perhaps have the byte-order argument to
> "proto_tree_add_item()" specify, for FT_STRING types,
> the character set and, in cases where a multi-byte
> character type can come in either byte order, the byte
> order;
>
> add a character set+byte order argument to
> "proto_tree_add_string()"?
>
> That complicates life for GTK+ 1.2[.x], as you have to figure
> out what character encoding is being used for the font, and
> translate into that. However, GTK+ 2.x, and the Win32 GTK+
> 1.3[.x], use UTF-8, so we should be able to make that work
> reasonably well. Doing so *might* fix *some* of the problems
> people are reporting on Windows.
Hmm.
It may be that, in GTK+ 1.2[.x], we can load fontsets rather than fonts
for the main text fonts, in which case it appears that the GDK functions
that take "gchar *" pointers as arguments treat the pointers as pointing
to strings that are multibyte-encoded strings according to the current
locale. GDK includes "gdk_wcstombs()" and "gdk_mbstowcs()" functions to
convert between "wide character" strings (in which each character is the
same number of bytes long, and is a GdkWChar) and multibyte-encoded
strings.
I don't know offhand whether the character set for "wide character"
strings is always UCS-2 or UCS-4, or depends on the locale.