On Tue, 2003-09-30 at 11:08, Danilo Segan wrote:
> уторак, 30. септембар 2003. 15:42:25 CEST — Vasilis Vasaitis
> написа:
> >
> > It's Not A Bug, It's A Feature. (TM)
> >
> > GTK+ 2.x uses by default its own input methods for character
> > composition. Nevertheless, you can force GTK+ applications to use the
> > Xlib composition mechanisms by setting GTK_IM_MODULE=xim among your
> > environment variables.
>
> But as far as I could notice, then you lose the Gtk+'s smart shortcut
> handling -- eg. if you've got Greek/Serbian Cyrillic/... map loaded
> into group1, and en_US in group2, it's enough that you press eg.
>
> Control + alpha/cyrillic a
>
> to initiate action Control+A (that being "latin A" :-).
As far as I know, you shouldn't lose that. That's done completely
separate from input method handling.
The main thing you will lose Control-shift-hex-digits Unicode input.
> So, this is not really a solution, especially not for Serbian folks who
> use latin and cyrillic interchangeably -- the same could be the case
> for some other languages.
>
>
> Actually, I think that it's good thing that Gtk+ provides all the
> compose sequences itself, because it forces some kind of
> standardization. Still, it's bad because every simple change has to be
> compiled in order to be visible.
>
> I'm not really sure about the reasons for this particular changes.
A) Operating system independence - GTK+ needs to handle compose
sequences when not running under X as well, making the operating
system independent input method the default means it gets tested.
B) Full set of Unicode compose sequences when not running under
a Unicode locale
C) Get to add some extra neat features like the control-shift
digits support.
If X actually had a genuinely nice input method system, then I'd be
more interested in making it the default for GTK+ for all languages (*)
.. but XIM and the X compose sequence stuff does not qualify.
> Btw, I'd prefer if Gtk+ (Pango, actually) supported rendering two or
> more separate combining characters with non-combining character as one
> glyph -- that's a basic Unicode thing :-)
For many scripts, Pango does that. If you have a font/script combination
that you wish that was handled, I can point out where in the code it
would need to be handled. Making Unicode normaliation forms NFC and NFD
render the same always is suprisingly tricky, but specific instances are
not hard to handle.
Regards,
Owen
(*) XIM is the default for CJK languages, for example, where real input
methods are needed.
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
