GNOME Bugzilla – Bug 114430
GtkIMContextSimple can't output 2-character per one key-sequence
Last modified: 2008-11-12 16:13:48 UTC
I want to assign a sequence of 2 unicode characters, to a sequence of keys, but there isn't any way. In Persian, sometimes ZWNJ comes in middle of words, deppending of it's previous character. I think IM doesn't have this feature yet.
Such a restriction is only for input methods that derive from GtkIMContextSimple and only use GtkIMContextSimple style tables. An input method can certainly output multiple characters at once (and can modify surrounding text, and all sorts of things) I'm not really sure if it is worth fixing, but if I was doing so, what I'd probably do is augment gtk_im_context_simple_add_table() with an additional: gtk_im_context_simple_add_records (GtkIMContextSimple *context_simple, void *records, gint n_records, gsize record_size, git n_compose, gsize str_offset); And you'd define a record type like: struct MyRecord { guint16 compose_keys[MAX_COMPOSE]; guchar8 output_str[MAX_STR_LEN]; /* UTF-8 encoded; }; gtk_im_context_simple_add_records(my_records, G_N_ELEMENTS (my_records), sizeof (MyRecord), MAX_COMPOSE, G_STRUCT_OFFSET (MyRecord, output_str)); Something like that.
Alog with Owen's suggestion, I start creating a patch. Attaching a half-way done patch, only with add_record() part, to make sure I'm doing things right. I'm going to add check_record(), doing actual composition, which will be called from key_press method. shouldn't be hard.
Created attachment 17407 [details] [review] a patch for add_table() part.
Created attachment 17413 [details] [review] a tentative patch - I'll test this with a sample IM backends
please review the attached patch. Here are my self review comments... - should combine tentaive_match and tentative_match_utf8? - should try more code merge of check_table/check_record()? - In add_record(), I'm making own copies of compose_table and outstr_tables from the given data, in order to use bsearch in check_record(). But, wondering a better approach...any suggestion? Please advise... Meanwhile I'm going to test this by creating sample IM backends.
I just realized the previous patch was the same as the 1st patch... Anyway, I'm going to attach a new patch, which seems to work with a sample input method module. My comments above are still valid to this new patch. Please review.
Created attachment 17473 [details] [review] a proposed patch.
Created attachment 17477 [details] [review] drawing intermediate text in preedit when there can be longer sequence.
preedit-draw was not working in the previous patch. This contains a fix for it. Assigning the bug, and adding PATCH keyword.
Created attachment 17524 [details] [review] a new proposed patch + modules/input/Makefile.am for imhiraga.c
Created attachment 17525 [details] Japanese Roman-Hiragana input method backend
For proof of concept and testing purpose, I prepared a backend to use the new add_record API. It does Japanese Romaji-Hiragana conversion, taking 3 or less compose sequence to compose 3 or less Hiragana characters.
BTW, with the proposed API and the record struct, the ROMAN-KANA backend cannot handle the case that a compose sequence results in commit string and leave some as a part of the next compose sequence. For example, suppose to input "kitte". (japanese for "stamp"). When "kitt" is entered, it should commit two japanese hiraga characters "KI" and small-"TSU", but it should leave the last 't' to be combined with following "e" to commit a hiragana "TE". By a little enhancement of the struct and API will enable this. I'll attach a new patch for it.
Created attachment 17589 [details] [review] a patch to handle pended compose sequence.
Created attachment 17590 [details] and new ja romaji-hiragana backend. E.g. "kit[t+]e" should work recursively.
Not sure if this has any bearing on what should be done with this bug, but I've used an imho relatively nice approach to this problem, as in for instance: http://cvs.sourceforge.net/viewcvs.py/gtk-im-extra/gtk-im-extra/src/imtamil99.c?view=auto
Mark as duplicate of a newer bug that has a more recent patch *** This bug has been marked as a duplicate of 537457 ***