#2678 MS Windows: Input: chars ĉ, ĝ, ĵ, ... come out as c, g, j...

[Thomas Winkler]

System: Windows XP SP3 on Athlon XP
Problem occurs with:
*ActiveTcl 8.5.7.0
*ActiveTcl 8.4.19.1
*tclkit-8.5.7-win32.upx.exe
*tclkit-8.4.17-win32.upx.exe
*tclkit-8.4.1-win32.upx.exe
*tclkit-8.4.0-win32.upx.exe
(Other versions have not been tested but are likely to suffer as well).

(1) install Esperanto keyboard from http://sites.google.com/site/windowskeyboards/Home
(2) run this script:
entry .e
pack .e
console show
bind .e <KeyPress> [list puts %k:%K:%N:%A]
(3) now change to the newly installed keyboard layout and you will see that when typing "ŝ" into the entry (on your "q" key if you're using a standard english keyboard), Tk will only get a normal "s" instead of a "ŝ".
This is not a font problem, as it works correctly to paste a ŝ copied from another app like notepad into the entry and copying the wrongly obtained "s" and pasting it into notepad only gives an "s". The problem lies somewhere in the keyboard input.
See the log of the sample script when consecutively hitting: c, ĉ, g, ĝ, h, ĥ, j, ĵ, s, ŝ, u, ŭ:
67:c:99:c
88:c:99:c
71:g:103:g
219:g:103:g
72:h:104:h
221:h:104:h
74:j:106:j
89:j:106:j
83:s:115:s
81:s:115:s
85:u:117:u
87:u:117:u
Obviously, the keycodes differ, but for some reason not the characters interpreted by Tk.

Note that this only happens on Windows; on linux/X with epo keymap it works like a charm.

Bug #1572922 might be related (but then again, it happens on Linux, and this one on Windows).

[Donal K. Fellows]

Probably a failure to act correctly in response to the event sent when the keyboard mapping is changed. No idea what this will look like at the level of code. :-)

[Thomas Winkler]

@dkf: I don't think so. Making the esperanto keyboard layout the system default so that it's already selected when starting Tcl/Tk by this script results in the same problems. Also note that typing Russian into the entry works fine – even when switching the keyboard layout while the script is already running.

[Thomas Winkler]

Maybe I should also note that I'm using a German Windows version with German (Germany) as codepage for unicode disabled apps. But then again, there doesn't exist any special Esperanto codepage, so this problem should appear on any language version/setting of Windows...