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


Previous blogs from this series:

I got mail yesterday from Frank Grießhammer of Adobe:

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

It's funny how definitions shift and change over time.

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....

Anyway, on to the email from Frank.

It's a bug.

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.

More to the point, it's a bug I introduced....

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.

Sorry about that....

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


comments not archived

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.

referenced by

2012/10/26 The evolving Story of Locale Support, part 28: We finally fixed that 'Install New Languages' thing!

2012/10/02 The evolving Story of Locale Support, part 27: No, the T and the H aren't silent...

2012/08/20 The evolving Story of Locale Support, part 26: Hey Windows 8, there's someone on the phone for you.

2012/07/11 The evolving Story of Locale Support, part 25: Something old, something new, something repurposed, and something...

2012/06/07 The evolving Story of Locale Support, part 24: I Adar you! Hell, I Double Adar you! (Windows 8 ed.)

2012/06/05 The evolving Story of Locale Support, part 23: Tamazight? Outta sight!

2012/04/12 The evolving Story of Locale Support, part 22: Digit Substitution 2.0

2012/03/08 The evolving Story of Locale Support, part 21: The Windows 8 Hijripalooza extraordinaire!

2012/03/02 The evolving Story of Locale Support, part 20: Yes, it's Bangla. Not Bengali!

2012/02/21 The evolving Story of Locale Support, part 19: In honor of International Mother Language Day...

2012/02/15 The evolving Story of Locale Support, part 18: Two scripts that share ten digits can be trouble

2012/02/02 The evolving Story of Locale Support, part 17: Today I feel like translating you more than before

2012/01/24 The evolving Story of Locale Support, part 16: We can't scale to a Xishuangbanna Dai locale, but…

2012/01/17 The evolving Story of Locale Support, part 15: Fixing our listings up in Windows 8!

2011/12/22 The evolving Story of Locale Support, part 14: Tifinagh, Tamazight, and Berber? Oh my!

2011/12/21 The evolving Story of Locale Support, part 13: Divvying up locales, yet again!

2011/12/09 The evolving Story of Locale Support, part 12: Logic dictates that we keep a sense of proportion about the RATIO

2011/11/23 The evolving Story of Locale Support, part 11: What language is that keyboard for?

2011/11/22 The evolving Story of Locale Support, part 10: Perhaps it is best to think of it as unintelligent design?

2011/11/16 The evolving Story of Locale Support, part 9: Nastaleeq vs. Nastaliq? Either way, Windows 8 has got it!

2011/11/15 The evolving Story of Locale Support, part 8: [Finally] taking care of some [more] languages in Pakistan

2011/11/11 The evolving Story of Locale Support, part 7: That would be a "call and a raise" for Hawaiian

2011/11/09 The evolving Story of Locale Support, part 6: Behind the Cherokee Phonetic layout in Windows 8

2011/11/08 The evolving Story of Locale Support, part 5 (...until the decision was made to not refuse to add it)

2011/11/04 The evolving Story of Locale Support, part 4 (working beyond one's bugs, and the case for an MSKLC update)

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