The evolving Story of Locale Support, part 3 (working beyond one's bugs, the setup)

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

Michael, Maybe you remember – I asked you some questions once before – most of which I could actually deal with myself.

I have been creating a bunch of keyboard layouts for Windows and Mac, to be shipped with the Adobe Pi fonts. The motivation behind this project is providing the user with a method to ‘key’ their symbol glyphs. The layouts were created for the Mac first, the XML was converted to a .klc file using a Python script, the final layout being compiled with MS Keyboard Layout Creator. In the process, I made the following observation, which might be interesting material for your blog:

As of Unicode 5, Unicode values with 5 digits exist. Both Mac and Windows have (at least) four possible shift states for keyboards, I kept them unified across the platforms: ‘alt’ on the Mac would become ‘altGr’ on Windows (e.g. the right ‘alt’-key).

The observation I made has to do with the altGr/altGr+Shift states: If there is a 5-digit unicode value mapped to a key in either of those states, the respective key just won’t return anything on Windows. I filed a bug with your colleagues, and in a long email conversation we came down to the point that unicode support in the OS is – to say the least – leaving a lot to desire. It’s broken. We could rule out MSKLC being the culprit, it really came down to the OS. By the way: I tested my example layout on a developer version of Windows 8 as well, and the same problem exists.

Now here’s my question: Do you maybe have an explanation for that? I see your latest post is about keyboards, so that might fit in just nicely.

Best greetings,
Frank Grießhammer
Type Design & Font Production
Adobe Systems

Although the architecture of keyboards on Windows has been stable and unchanged since at least NT 3.1, and keyboards have been create-able via the DDK for almost as long, the creation of keyboard layouts was largely a rare operation by a few key players who provided their own runtime layers that ran atop Windows (such as Keyman), and the "competition" of those companies that did this work? Mostly hacks.

The number of DDK downloads did not increase much during this time -- people were mostly working atop the system.

And you could fit all of the people who really understood the innards of the input stack in one minivan. And you'd have room to hold the cooler containing the beer that the group would inevitably be drinking at some point. :-)

After the Microsoft Keyboard Layout Creator was released, all of that changed.

Nearly three quarters of a million downloads of two versions of MSKLC over this last almost decades and an essentially uncountable number of layouts later, and the principal means of going beyond the new bar of what is possible in keyboards has principally been based on work talked about in this Blog.

There are people writing Python scripts to generate .KLC files, and Apple's Boot Camp ships layouts using the format too.

There is a small part of me that is sad that the ownership of MSKLC is elsewhere, because there's a part of me that would love to be creating new versions that fix bugs and add features. This Blog, for all of its virtues, is a rather unwieldy tool to act as the path to upgrading the collective understanding of what can be done with input.

But I have other work now that keeps me pretty busy that I also enjoy, and there are only so many hours in a day, so....

And it is a bug in MSKLC, or to be more precise in the kbdutool.exe command line tool that MSKLC delegates its actual layout creation too.

Suddenly the number of people I helped with this widely downloaded tool and widely read Blog seems a lot less impressive to me. Even though the usage scenario is uncommon....

For my penance, I will provide the workaround for Frank and the others running into this problem of supplementary characters in the AltGr and Shift+AltGr keyboard states.

I'll warn you that it is kind of a pain in the butt and will require a bunch of the kind of work Cathy and John and I used to have to do creating keyboard text files years and years ago.

So it is a workaround, not a fix. As anyone who has ever had to author those text files by hand will readily attest.

Anyway, I'll provide the workaround tomorrow, so pop by. It will be worth your time, I promise....