The bigger they are, the worse they are when they're dead?

by Michael S. Kaplan, published on 2008/07/07 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/07/07/8697885.aspx


Any NLS testers around want to put in the bug based on this blog? :-)

Kim's message via the Contact link definitely got my attention. The message was:

Hi Michael,

I have been caught out more than once by a strange gotcha when designing kbd layouts that use dead keys. It happened again the other day when I made a layout for Ancient Greek. This required a whole lot of dead keys -- 14 I think -- and I assigned base characters to them that made sense to me. For example, the dead key for a bunch of vowel letters surmounted with the smooth breathing ('psili' -- but I learnt my Ancient Greek in English ;) ) I gave the base character U+1FBF, i.e. the smooth breathing. So smooth breathing + U+03B1 (lowercase alpha) -> U+1F00 (lowercase alpha with smooth breathing). And so on for the other 13. Everything worked as expected in the MSKLC test pane. But after building and installing the layout, nothing worked as expected in WinXP (SP3). Specifically, none of the dead keys worked. The keystroke sequence above produced a plain lowercase alpha with no breathing, i.e. the dead key was ignored.

After puzzling for a while, I eventually recalled a similar incident a few years back, when I discovered that characters above a certain limit -- I suspect it is U+0FFF but haven't confirmed this -- just won't work as base characters for dead keys. When I redefined the above dead key with U+0313 ('combining comma above') as its base character, it worked. Not all of my dead keys could be given 'sensible' base characters -- there's no reasonable look-alike for U+1FCE ('greek psili and oxia' -- smooth breathing and acute accent), nor for most of the other multi-diacritic combinations, but I just have to live with that. I've assigned them arbitrary characters (archaic Greek characters in the U+0300 range), and they work.

This is obviously a restriction in WinXP and not a bug in MSKLC. But shouldn't MSKLC issue a warning when a dead key is defined with a base character that is going to stop it from working? It's very puzzling when everything validates and test perfectly, but the installed layout doesn't work.

Thanks
Kim

Yikes, this seems like a real problem!

To make it all easy enough to verify, I created a keyboard to try and reproduce the problem -- seven Greek letters (upper and lower case) with four dead keys:

And I tried it on a Vista machine, unlike the XP machine Kim reported the problem on.

For people following along at home you can download the .KLC file I created from here. Fair warning -- this was hurriedly done and not all of the letters are right!

Anyway, here you can see the four dead keys:

   

Now for good measure, in the SHIFT state, I put four nealy identical dead keys -- though in each I used the "alternate" character that even Unicode uses for the decompositions for the four dead key characters instead:

Here you can see them on the keyboard:

    

I then tried out the dead keys.

Just as Kim indicated, all eight work just fine in the MSKLC test surface.

But the first four do not work properly as dead keys in the compiled layout (though the second four work just fine).

Now this is a genuine bug, certainly.

Though if you look at the letters in question and their Unicode decompositions, e.g.

and so on.

In other words, there is a definite set of characters that can be used instead of these compatibility characters that do not seem to work properly....

Though from a linguistic standpoint it might seem wrong to make some of these substitutions -- either the ones I did in the uppercase dead keys or the ones that Unicode does in th eull chasrscter decompositions -- because fonts that contain the compatibility characters re much more likely to look correct without needing a special Greek font.

So Kim -- a genuine bug, but at least one with a workaround in the meantime, right? :-)

To any NLS testers reading this -- I have not verified Kim's supposition of a literal cutoff at U+0fff and I don't think that is necessarily true since I vaguely recall an old Khmer keyboard of Paul Nelson's that was entirely dead key based, and the Khmer subrange is U+1780 to U+17ff. So I think there is something slightly different going on here....

 

This blog brought to you by(U+1f00, aka GREEK SMALL LETTER ALPHA WITH PSILI)


John Cowan on 7 Jul 2008 10:14 AM:

Am I to understand from this that you *can't* put the bug into the bug database yourself?  That seems ... limiting.

Michael S. Kaplan on 7 Jul 2008 10:21 AM:

Oh, not at all -- I can put in bugs.

But testers, especially area owners, will do a bit more than just enter a bug, so when something is in their area it gives them the heads up so they can *do* those things.... :-)


Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day