[10539] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: Future work on GTK
daemon@ATHENA.MIT.EDU (Owen Taylor)
Mon Nov 30 10:42:23 1998
To: Jeff Garzik <jgarzik@pobox.com>
Cc: gtk-list@redhat.com
From: Owen Taylor <otaylor@redhat.com>
Date: 30 Nov 1998 10:42:39 -0500
In-Reply-To: Jeff Garzik's message of "Mon, 30 Nov 1998 10:17:34 -0500 (EST)"
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
Jeff Garzik <jgarzik@pobox.com> writes:
> Preben Randhol wrote:
> > o> Owen
> > GTK+
> > Currently I am working on getting the 1.2 release of GTK+
> > finished. This will include a lot of significant changes. Recent
> > work of mine includes rewritting the drag-and-drop code in GTK+
> > and integrating Raster's theme code into the main branch of GTK+.
> > For the next development cycle of GTK+, I want to work on getting
> > really high quality internationaliation into GTK+. This will mean
> > switching over to Unicode and supporting right-to-left languages
> > like Arabic and Hebrew.
>
> Regarding this last item, internationalization, will Gtk+ include a new,
> basic type that holds an international string, kinda like an XmString?
>
> (or does that sort of thing already exist?)
yes and no.
Currently, if the font for a widget is a fontset (i.e., created with
gtk_fontset_new() or with a "fontset = ..." declaration in a RC file),
then the string will be interpreted according to the current locale,
and drawn with appropriate fonts taken from that fontset.
That gives about 75% of the functionality of XmString, with about 1%
of the complexity.
But since locale-dependent multibyte encodings are also nasty to work
with, in my vision for the future of GTK+, every string that an
application supplies to GTK+ will be taken to be Unicode encoded as
UTF-8. (Conversion functions from locale-dependent encodings, to
Unicode will be supplied).
GDK will then render these strings as faithfully as it can, falling
back to other fonts with additional characters when necessary. When a
unicode string would be rendered differently in different languages
(say Japanese and Chinese), it will be rendered according to the
current locale.
There will also be provisions for drawing a string according to
specific locale, so that higher-level widgets (such as the Text
widget) can support language-tagging and thus have both Japanese and
Chinese text drawn within a single set of text in such a manner as to
make everyone happy.
Regards,
Owen
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
