by Michael S. Kaplan, published on 2010/05/19 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/05/19/10009920.aspx
So, the message from Dharma via the Contact Link was:
Dear Michael,
First, I would like to thank you for your great BLOG! Well done! I've spent many hours reading and studying various articles and have found all of them helpful AND entertaining as well. And it's hard to do both of those things at once!
Although I've worked in the Java world for years, I'm new to Windows programming. So please forgive my ignorance!
1. The app that I'm building involves using 2 new keyboard layouts. So I built them using MSKLC. Everything was fine except they did not quite work in Microsoft Word 2007 running on XP. Most of the keyboard worked just fine. In particular the Devanagari layout didn't quite work in Word although it works fine in Notepad, Wordpad, and Excel 2007! It turns out that when I use a dead key to obtain some of the cerebral consonants in a glyph they don't combine! And it only happens when the dead key letter is in second position!
Let me explain more clearly with an example.
Here is what is supposed to happen (see the Devanagari Unicode table):
Let + be short for the words "followed by" in the example below
0938 + 094d + 0925
This sort of thing works just fine in MOST cases. The 2 letters are combined into a glyph & are properly rendered on-screen
However, if the last code point in the example is created by using a dead key (dead key + someKeystroke), the 2 letters do NOT combine into a new glyph as they do all the other times. If you then move the cursor backwards on the screen to select the letters of the word, then the glyph fixes itself and properly renders!
So I've found a way around this by simply not using dead keys but it makes for a less convenient keyboard mapping.
What's happening here? I saw an article where one of your readers said something about Rich Edit causing something like this. It was a small and somewhat vague remark. Could this be the case here? I don't mean for you to spend a lot of time on this. If you could just point me in the right direction to understand what is happening, I'd be grateful.
Thanks again Michael. Tell your boss that I said you're doing a great job!
Dharma
It is funny, a colleague of mine was talking about this "feature" recently.
He was talking about RichEdit though he explained how the same feature existed in Word.
The feature?
Well, providing rendering smarts by using information about the keyboard and the input stream.
This may be what is interferring here.
A good way to check is to take the text that looks good in the other apps, copy it, then paste it into Word (or RichEdit).
If it looks right in both then it is the keyboard "smarts", if not then read on....
Now that I think about it, I am goint to a priori blame Indic sequence checking in this case (ref: You're not the one out of sequence, and that's the Word), since that is one that you can verify being the problem by turning off the feature and seeing what happens!
The problem with the sequence checking is its assumptions about the way proper input looks can be entirely unforgiving in such cases if it does not recognize the nature of the input (like this keyboard may be causing for it).
The best fix there is to turn it off, always, as it breaks proper use of language in so many cases with its provincial and narrow view of what constitutes normal input....