by Michael S. Kaplan, published on 2009/06/18 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2009/06/18/9773077.aspx
Rimas Kudelis asked over in the Suggestion Box:
Hi Michael,
I was wondering if you know if there are any plans to extend the Windows keyboard driver in future? In particular, I'm interested about the limitations related to dead keys.
Back in 2006 (in Only ONE WCHAR per dead key) you said that the dead key infrastructure is actually here only for legacy reasons. However, I'm pretty sure that you know how widely it's being used. One case where dead keys are very handy is adding stress marks to letters. For example, Lithuanian alphabet has 32 pairs of upper/lower letters, and that's fine, they all have distinct positions in Unicode. However, there also exist 34+34 possible combinations of these letters with the three stress marks used in Lithuanian, only 33 of them having distinct Unicode positions. Employing dead keys to enter them is a very intuitive solution. However, it doesn't work for 35 cases that have to be composed from the base letter and a combining accent mark...
The answer is not going to inspire warm fuzzies, sorry. :-(
The blog in question (Only ONE WCHAR per dead key) and the ones it links to (in particular Dead keys are not intuitive) clearly explain the architectural limitation, and the basis for the feature.
And they explain that the only reason this feature exists at all is a legacy of typewriters not smart enough to handle not advancing on a letter when the accent is typed after the letter.
I mean, is it really expected that people would WRITE the language this way? Would you write the accents and stress marks and then write the letter?
Of course not!
So, as I have said before many times, the way to do this is the way that even children in school learn to write the language, and that Unicode encodes scripts -- first type the base and then type the combining character or characters.
It works well, it is well supported, and it gets the job done. For Vietnamese, and Lithuanian, and all of the other languages that need this functionality....
# Tom Gewecke on 19 Jun 2009 6:34 AM:
Deadkeys don't require that you type the accent first, do they? On a Mac you can make layouts where the vowel is the deadkey and what diacritic is added depends on the next key you hit.
# gbella on 19 Jun 2009 9:29 AM:
Hi, I just discovered your blog while searching for a solution for a MSKLC-related bug (? to be confirmed). I wonder if this is the right place to post such reports, but it will also allow me to reflect on your opinion about dead keys.
So let’s see this dead key issue first. Yes, combining characters are great, and I have nothing against the Unicode principle of them following the base character. However, and I’m sure you know this just as well as me, dead keys are commonplace for several non-US (e.g., French) keyboards. People are pretty well used to them, and these kinds of habits just don’t go away. Moreover, support for combining characters is a very recent addition to Windows: I am told they work under Word 2007 but, in my experience, not under Word 2003, which an awful lot of people still use. Also, under XP (e.g., Notepad), the equivalence of the base+combining pair and the precomposed character is not respected, which is a major issue (when searching for the word passé I won’t find passé, see the difference?).
Recently I considered deploying combining character-equipped custom keyboard layouts in a big company, but I immediately discarded the idea once I realised that these issues could not be resolved.
Which brings me to my main topic: while developing a custom French keyboard with MSKLC, I ran into a strange error which might be a bug. I was trying to reproduce some Word-specific French character combinations such as Ctrl+' which is basically a dead key for the acute accent. So in MSKLC I defined Ctrl+' (that is, VK4) as a dead key that gives ÁÉÍÓÚáéíóú when followed by AEIOUaeiou. Also, I wanted to used the same dead key to type a regular (i.e., typographic) apostrophe U+2019 when followed by a space:
U+00B4 (dead) followed by U+0020 => U+2019
It all works perfectly fine in the test window of MSKLC. However, when I create and install the DLL, the behaviour is altered: Ctrl+' is not a dead key anymore, and pressing it results in two (!) apostrophes (U+2019) being displayed. Upon opening the installed keyboard with MSKLC, I see that the key’s definition has indeed changed: Ctrl+VK4 gives U+2019 U+2019.
A similar, although not equivalent, problem occured when trying to define Ctrl+è (that is, VK7) as a dead key for the grave accent. This time, once the custom keyboard installed, the combination Ctrl+è becomes AltGr+è.
The KLC source file contains the right information. These alterations occur with the installed package only.
Any solutions or ideas? I can provide you with more information or the source KLC file if necessary.
Thanks a lot in advance, cheers,
Gábor
# Michael Everson on 19 Jun 2009 10:05 AM:
Lots of people are very happy with dead keys, and have been for decades. Irish keyboards, for instance, and most of the keyboards on the Mac OS, used deadkeys. You might (and do, as you say) prefer other methods of input, but there's a big difference between that and telling those who don't that they are benighted and should adopt different methods of input.
# Michael S. Kaplan on 20 Jun 2009 1:55 PM:
Hey Tom -- on Windows, the dead key architecture is only accent+base. The Mac has many clever additions that make dead keys more usable, but as I said Microsoft does not consider the are worth expanding on, so they do not plan to....
# Michael S. Kaplan on 20 Jun 2009 1:59 PM:
Michael, I don't know what to tell you -- I am describing things as they are and (barring some tumultuous intervening event by someone a lot more powerful than either of us) as they will be on Windows.
People who want to work on Windows can use the dead key support that is there and which works for many languages, or they can use other methods. There are realistically no other options....
# Michael S. Kaplan on 20 Jun 2009 2:06 PM:
Gábor, for your bug you should see other blogs I wrote like this one and this other one....
# RQ on 26 Jun 2009 4:00 AM:
Michael,
thanks for answering! :)
I had read many of your posts (especially those related to the question) before, but the reason why I re-asked this question was because it seemed to me that this limitation is mostly kept just to be kept. You said:
Even if this ever were changed in a future release of Windows, it could not be used on existing versions due to the backcompat break that this would cause -- and the future version of MSKLC would have to support different keyboard layout DLLs for different versions of Windows. Which as I am sure people can imagine is not a terribly popular plan....
So, it seems to me that it's not being updated purely for the sake of backwards compatibility, and while backcompat is a good thing, I don't believe that it should block progress (otherwise we would still be using DOS, wouldn't we?). Sure, I understand that even if Windows 8 would extend the possibilities here, we would still have to work around the limitation for Windows 7, Vista, XP etc. That's normal. Not so normal is limitations in legacy systems causing limitations in new ones. I hope you get my point... :)
# Michael S. Kaplan on 27 Jun 2009 12:14 PM:
The code is very solid as is and rearchitecting it to support a new scenario is considered out of scope (plus would add huge complexity to layout maintenance given the forward and backward compatibility issues.
This is not "kept just to be kept" this is kept to avoid a huge engineering cost for Microsoft and third parties and a huger authoring/maintenance cost for third parties.
It will not happen for the USER-based keyboarding architecture on Windows.
Now this does not mean the general problem has no possibility of solution; it just means that the one technology in question does not have it. There are methods to make the old architecture work (as I mentioned) and explorable avenues to use new architectures (like the text-based TIPs I have discussed previously)....
referenced by