While investigating bug 1086769, I discovered that inkscape's on-canvas text editing does not handle (some?) multi-byte character entry. Here's what I did...
I installed "scim-chinese" and "scim-gtk2-immodule" which gives me an "SCIM" input module (right-click on text-entry widget to select SCIM). Then, you can hit ctrl-space to switch to chinese-char-entry mode, which lets you type a letter (say, "a") and then select (with numbers) which character you want. In the text widgets, this works great. On the canvas, inkscape would do VERY weird things: it would add the "preedit" character to the _end_ of the string instead of at the cursor position, and then when the final char was selected, it would overwrite the char AT the cursor position.
Basically, the SPTextContext is attempting to handle the "preedit" character events itself, but it doesn't do it right. Since "preedit" handling doesn't seem to be _required_ for input to be processed, I've disabled it. This just means that the "predit" char isn't visible until you're done typing it in. What's weird is that other Input Modules (like, say "IPA") will show their preedit letters and inkscape seems to handle it correctly (type "a" "e" with the IPA IM, to see a merged "ae" character). Even with preedit disabled, this works on the canvas.
So... I'm not sure why preediting is there at all, and I've disabled it. Can anyone find any reduced functionality as a result of this? Currently this _fixes_ chinese input (at least with SCIM), so I'd like to leave it like this until I can better understand the IM system.
On Fri, 4 Feb 2005 08:47:56 -0800, Kees Cook <inkscape@...62...> wrote:
Basically, the SPTextContext is attempting to handle the "preedit" character events itself, but it doesn't do it right. Since "preedit" handling doesn't seem to be _required_ for input to be processed, I've disabled it.
It was enabled in Sodipodi code, and I never touched it, though it always struck me as something suspicious.
As far as I can see, typing English or Russian text still works as before, so this does not seem to have any harmful effect. (At least for me :)
This just means that the "predit" char isn't visible until you're done typing it in. What's weird is that other Input Modules (like, say "IPA") will show their preedit letters and inkscape seems to handle it correctly (type "a" "e" with the IPA IM, to see a merged "ae" character). Even with preedit disabled, this works on the canvas.
Two comments:
- some (long) time ago someone had a patch that added input method switching to the right-click menu of a text object, so you could switch IMs without going to the text dialog. Can you look into applying it? Here's the message:
http://article.gmane.org/gmane.comp.graphics.inkscape.devel/2045/match=input...
- Now that you disabled preedit, try to remove sptc_preedit_changed() and its connection to the preedit_changed signal, just to make code simpler.
Quoting bulia byak <buliabyak@...400...>:
On Fri, 4 Feb 2005 08:47:56 -0800, Kees Cook <inkscape@...62...> wrote:
Basically, the SPTextContext is attempting to handle the "preedit" character events itself, but it doesn't do it right. Since "preedit" handling doesn't seem to be _required_ for input to be processed, I've disabled it.
It was enabled in Sodipodi code, and I never touched it, though it always struck me as something suspicious.
It was some of my earliest code Sodipodi in Sodipodi; I implemented it without really understanding the IM system or even much in the way of testing. I'm surprised it ever worked as well as it did...
- Now that you disabled preedit, try to remove sptc_preedit_changed()
and its connection to the preedit_changed signal, just to make code simpler.
Yes. As I'm fond of saying, unused code ought to be removed with extreme prejudice. If we need something later, that's what the revision history maintained by CVS is for.
-mental
On Fri, Feb 04, 2005 at 01:28:44PM -0400, bulia byak wrote:
- some (long) time ago someone had a patch that added input method
switching to the right-click menu of a text object, so you could switch IMs without going to the text dialog. Can you look into applying it? Here's the message:
Hah! That's the _first_ thing I thought of while messing with this code. ;) I couldn't find an easy way to hook the to the textcontext, so I just went on. I'll review the patch.
- Now that you disabled preedit, try to remove sptc_preedit_changed()
and its connection to the preedit_changed signal, just to make code simpler.
Okay. I didn't want to do that until other folks had tested it with it disabled.
participants (3)
-
unknown＠example.com -
bulia byak -
Kees Cook