Re: widechar support

[Owen Taylor <otaylor redhat com>]

phil@bolthole.com (Philip Brown) writes:

> Arrrg. I had written this nice long letter, and my computer crashed JUST as I
> was going to send it.
> Sigh. Here goes again.
> 
> I see you folks have added localization, to some degree. But gtk is still
> missing one major thing right now: wide-char (16-bit) support.

Hmmmmm, actually, GTK has fairly good support for CJK languages.
Most of it is formulated in terms of multi-byte characters,
not wide-characters, but it comes down in the end to the
same thing for the user.

If you locale is set to a CJK locale, then all of the text
related widgets (Label, Entry, and Text) support international
input and output.

GTK+ 1.4 will have much better support for international
charactersets, formulated in terms of Unicode. My goal is
to have the framework (if not, initially, the set of supported
languages) be as good as NT 5.0. (Or whatever MS is calling it now...
he published set of character-handling API's is in any case
very good)
 
> I'm willing to write most of it,but I'm completely new to gtk, so I need
> pointers as to WHERE to add it.
> 
> I've used 16-bit chars under Xaw and Motif, so the two methods I know of are:
> 
> Motif: Every string is "special". Widgets auto-detect whether string is
>    "wide-char" or not, and do the right thing.
> 
> Xaw/Athena: text widgets have an "encoding" property, that is set to either
>    8 bit or 16 bit. 
> 
> For easy coding, I would do the latter. It also would make porting my
> kdrill program to gtk a lot easier.
 
Hmmmm, for something like kdrill, requiring the user to
have a functional japanese local is a bit much,
admittedly.

But the Japanese output needs of kdrill (the version
I have here anyways) are simple enough, that you
can probably just draw your characters "by hand"
using a different form of "wide character" support
in GDK. For 16-bit fonts, the gchar * input to gdk_draw_string
(and a number of similar functions) is intepreted as
a (guint16 *) cast to (gchar *). 

This is distinct from gdk_draw_string_wc which takes
real localized wide characters and thus requires functional
locales.

For a program that takes that approach, see 
http://www.gtk.org/~otaylor/kanjipad/. Let me know
if you have questions or want to borrow code.

> But Aaaaanyway... here's where I figure I should NOT add it:
> 
>   gdk
>   GtkStyle  (since that's a wrapper for a GC?)

Well, sort of. A GtkStyle encapsulates information about
the appearance of widths - GdkFont and colors, basically.
GdkFont already supports both straight 16 bit fonts
and fontsets. (Though trying to stick 16 bit fonts into
labels or other GTK+ widgets doesn't work too well
any more - GTK+ has gotten too smart for that)
 
> The best I can come up with, is:
> 
>    gtk_text_set_charwidth(int);   (8 or 16 are only acceptible inputs)
>
> However, that would seem to also mandate a completely separate
> 
>    gtk_button_set_charwidth(int);
> 
> and possible others. It's too bad there isn't some kind of uniform text
> control other than what's in the GtkStyle stuff. But anyways. What
> do you folks think?

(Buttons and most other widgets are just containers for labels
in GTK+ ... so the number of places support is needed is
more limited than you might expect)

> PS: I would only code the DISPLAY part. I'm not touching 16-char input
> with a 10 foot pole, since that is locale specific, and I don't need it.

Luckily, you don't have to. It already works. (Well, again,
multi-byte works) 

Regards,
                                        Owen