Re: Windows and MacOS keyboard layouts in human-readable format?
From: "Adam Twardoch" <[EMAIL PROTECTED]> > I agree with Michael that the simplistic approach I have envisioned would be > rather incomplete -- I'm willing to accept that limitation. I am aware of > many issues involving IMEs, "chaining" dead keys etc. I would be willing to > leave them out of the scope, i.e. I'd be willing to accept as much as it > gets within a somewhat "flat" table. Fair enough. Note that even normal dead keys will not be very useful in a flat table -- you will have to have a way to map two keystrokes to one UTF-16 code point, > I have since then read some descriptions of Windows API functions. For > example, I found out that the Windows user32.dll function VkKeyScanEx > translates a character to the corresponding virtual-key code and shift > state. This makes me conclude that Windows developers already had this kind > of "back-lookups" in mind, and were willing to accept the limitations. Well, I never said it was impossible to get the information (in fact MSKLC uses the keyboard APIs in user32 extensively to do its work to "load from an existing layout"). Just that it is nowhere near a flat table, by any means. > (Michael,) > > from my understanding, when I have a Unicode character, I should be able to > translate it to a virtual key code via VkKeyScanEx, then the virtual key > code to a scan code using MapVirtualKey, and finally translate the result to > a human-readable name using GetKeyNameText. Is that a correct approach? Does > anybody happen to have a ready-to-use function (C++, VB, Python)? :D This will not work well for several reasons: ** GetKeyNameText only works witth the current layout and there is no GetKeyNameTextEx. If you ask me, GetKeyNameText is a little silly API, which relies on the strings added in each individual DLL (some localized, some not). The "localization" not very consistent between keyboards, either. You would essentially be reading information from specific keyboards and then trying to describe them as one particular one (whichever one you happened to be using as your keyboard in the current thread). ** Another problem is in using VkKeyScanEx here. Do you plan to throw all of Unicode at every single keyboard? ** Yet another problem with this approach is that none of the dead keys will show up with it; it will only find single characters that came from single keystrokes. ** And yet another problem is that no ligatures will work (same problem as above). Could we take a step back for a moment? If you could clearly explain what you planned to do with the files it might be easier to suggest a course of action. All I can do with the current plans is poke holes in the problems based on my own experience with "keyboard interrogation". You may also want to mark the thread "OT" since its not really much to do with Unicode MichKa [MS] NLS Collation/Locale/Keyboard Development Globalization Infrastructure and Font Technologies
Re: Windows and MacOS keyboard layouts in human-readable format?
Michael, Peter, and others: Thank you for the responses. I agree with Michael that the simplistic approach I have envisioned would be rather incomplete -- I'm willing to accept that limitation. I am aware of many issues involving IMEs, "chaining" dead keys etc. I would be willing to leave them out of the scope, i.e. I'd be willing to accept as much as it gets within a somewhat "flat" table. I have since then read some descriptions of Windows API functions. For example, I found out that the Windows user32.dll function VkKeyScanEx translates a character to the corresponding virtual-key code and shift state. This makes me conclude that Windows developers already had this kind of "back-lookups" in mind, and were willing to accept the limitations. I guess with some API calls, I should be able to put together such table, or even a mechanism to gather the information dynamically. I will be writing in Python for Windows, so it's a bit awkward to gather all that information. But maybe I'll try to prototype in C++ (a pity I'm so bad at C++ programming). (Michael,) from my understanding, when I have a Unicode character, I should be able to translate it to a virtual key code via VkKeyScanEx, then the virtual key code to a scan code using MapVirtualKey, and finally translate the result to a human-readable name using GetKeyNameText. Is that a correct approach? Does anybody happen to have a ready-to-use function (C++, VB, Python)? :D (Peter,) I am aware that there is a XML-to-driver mechanism that can be used. But is there a way the other way around? I.e. a way from the existing system kyboard mappings to a human-readable form? Thank you, Adam
Re: Windows and MacOS keyboard layouts in human-readable format?
Michael (michka) Kaplan wrote: > Adam was looking for this work, already done. And he gave a sample of > what he was hoping would exit, out in the wild. What he said was, "I'm looking for a way to compile a table..." > So I was merely pointing out a bunch of reasons why this was not a > practical thing to want, so he should not be too disappointed when he > did not find it (since by its very nature it would be incomplete). Clearly, the success or failure of a project like this depends entirely on expectations. > If there is interest in trying to develop a format and subsequently > fill it, then that is great. But is it really a good idea to discuss > such a project in *this* forum? And does it really meet the criteria > Adam laid out? I can think of many discussions we've had here lately that were much farther off topic. At least Adam's prototype table defined the characters by USV. As for his criteria, they didn't seem fully specified to me (except that he wanted to be able to find out how to type a-acute on different keyboards), so I guess only Adam could be the judge. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
Re: Windows and MacOS keyboard layouts in human-readable format?
Adam Twardoch wrote: > Do you know if there are human-readable versions of Windows and/or > MacOS keyboard layouts available somewhere? > > I'm looking for a way to compile a table that could look a bit like > the following: > > Platform LanguageLayoutUnicodeKeystroke > WindowsPolish Polish (Programmers) 0105AltGr+A > WindowsPolish Polish (Programmers) 0041A > ... > > where I could, for example, look up which exactly keyboard layouts let > the user input, say, a with acute, and how he can do that. and Michael (michka) Kaplan responded: > Such a format for Windows would be quite inadequate since it is > missing many things, such as: I was sorry to see Adam's idea shot down so quickly, because it seemed like a pretty good thought to me, assuming the practical limitations are understood. Michael is right, of course, that the differences between keyboards amount to more than just the basic layout and Shift and AltGr keys. There are custom shifting keys, dead keys, and unusual uses of Caps Lock, not to mention Far Eastern IMEs. But I don't think the whole idea needs to be scuttled because of these problems. Let's see if we can expand Adam's chart to cover some of these extra needs. > 1) The version of Windows in which it first shipped (there were minor > differences in what was in 9x vs. NT, and on NT some characters were > added to keyboards in later versions). If this is really necessary -- aren't updated drivers available? -- it can be added as another column. > 2) The fact that many keystrokes produced more than one keystrokes > (called ligatures there athough the technology can apply to code point > combinations that do not, in fact make up ligatures) The "Unicode" column in Adam's table would have to allow combinations of code points. Keyboards for Indic scripts, in particular, frequently have keys that generate at least three Unicode characters. This is the "1-to-many" problem. > 3) The fact that in many cases combinations of keystrokes produce a > single code point (called dead keys) -- best described by the many > combining characters that go with individual base characters Similarly, the "keystroke" column would need to be expanded to handle sequences of keys. This is the "many-to-1" problem. > 4) No completely consistent description of OEM keys that is based on > letters that would work for all keyboard hardware If Michael means what I think he means, the solution is to use ISO 9995 terminology (at least for the basic letter-generating keys, if not for shifting keys). Don't say "A" for the keystroke, say "C01" (or "D01" if you're talking about a French keyboard). It's really not that hard to get used to this naming convention. > 5) Naming inconsistencies between different versions (rare but present > on occasion) You mean the name of the keyboard layout? Any examples that would make the list unusable? > 6) No good way to explain when CAPS lock is being used for casing, > etc. Good point. I remember hearing that German keyboards don't use Caps Lock the same way U.S. keyboards do; apparently they apply Shift to all keys, not just letters. I don't know how to handle this, but I'll bet someone could figure it out. > 7) No way to explain SGCAPS use of the CAPS lock, used by Hebrew, > Czech and others. Can't comment, since I'm not familiar with this issue. > 8) No way to describe "custom" shift keys like seen in the > [unfortunate] Canadian Multilingual Standard keyboard Instead of saying "AltGr+A", assign one column to each special shifting key. And so on. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
Re: Windows and MacOS keyboard layouts in human-readable format?
From: "Doug Ewell" <[EMAIL PROTECTED]> > Michael is right, of course, that the differences between keyboards > amount to more than just the basic layout and Shift and AltGr keys. > There are custom shifting keys, dead keys, and unusual uses of Caps > Lock, not to mention Far Eastern IMEs. But I don't think the whole idea > needs to be scuttled because of these problems. Let's see if we can > expand Adam's chart to cover some of these extra needs. Adam was looking for this work, already done. And he gave a sample of what he was hoping would exit, out in the wild. So I was merely pointing out a bunch of reasons why this was not a practical thing to want, so he should not be too disappointed when he did not find it (since by its very nature it would be incomplete). If there is interest in trying to develop a format and subsequently fill it, then that is great. But is it really a good idea to discuss such a project in *this* forum? And does it really meet the criteria Adam laid out? MichKa [MS] NLS Collation/Locale/Keyboard Development Globalization Infrastructure and Font Technologies
Re: Windows and MacOS keyboard layouts in human-readable format?
Mac OSX keyboard layouts can be defined in XML which is a close as we get to human readability - see http://developer.apple.com/technotes/tn2002/tn2056.html This format has been available for over a year, so there may be some published data files from 3rd Parties. Michael Everson is one such person in your time zone who has defined a number of Mac OS keyboards via the XML format and has some up on his web site http://www.evertype.com/software/apple/index.html Best wishes Peter At 11:03 PM +0100 12/29/03, Adam Twardoch wrote: Do you know if there are human-readable versions of Windows and/or MacOS keyboard layouts available somewhere? I'm looking for a way to compile a table that could look a bit like the following: Platform LanguageLayoutUnicodeKeystroke WindowsPolish Polish (Programmers) 0105AltGr+A WindowsPolish Polish (Programmers) 0041A ... where I could, for example, look up which exactly keyboard layouts let the user input, say, a with acute, and how he can do that. Thank you in advance, Adam Twardoch
Re: Windows and MacOS keyboard layouts in human-readable format?
From: "Philippe Verdy" <[EMAIL PROTECTED]> > If the intent is to display in a user interface which keystroke the user > must press to create a character sequence it can be useful to know the > character generated in the default state without modifiers (or the character > generated in CAPSLOCK mode). Since the majority of keystrokes in ALL keyboards are created in different shift states, I am not sure why this relates to the question that Adam was asking at all (he clearly referenced AltGr out of the starting gate). > This is an issue for example when creating "accelerators" or keyboard > shortcuts in an application and one wants to display this shortcut in menu > items or in button tooltips. (For example, how do you display the "mnemonic" > in Java menu items, or the "&"-selected character in Windows resources, fo > menu items that display non Latin strings such as Chinese or Arabic? You > need to display it at end of the menu item, and the underlined convention > for mnemonics is not usable. But which string will you display? You need > this information support from the keyboard driver itself or an OS API). This is an interesting but mostly unrelated topic to either Unicode in general or Adam's question in particular, but if you understand IMEs and all of the existing CJK input methos then you know that it is impossible to have CJK accelerators or keyboard shortcuts. > Designing keyboard shortcuts that will work in internationalized > applications is a difficult problem for the localization of applications, > and there's no way to do it without knowing the exact keyboard layout > actually used, but that may not be knowed precisely at run-time, or may be > customized by the user. Not supporting shortcuts is also a problem for > accessibility. Very true -- but also off of the topic -- its not polite to take over a thread and push it off in unrelated directions -- lets stick to Adam's query, here. K? > Unfortunately, Windows does not help the application to select appropriate > shortcuts to use to match some prefered "accessible characters present in > menu items. There's no automatic generation of these shortcuts from menu > item strings, and no automatic display. Um, I guess you mean application tools, right? Again offtopic, but this is a problem that is not very easy to solve and which will often fail even when it is solved since it assumes that the language to which an application is localized is also the input language (which is often false). Lets drop this one, since it is REALLY not what was being asked. Hijacking of threads is poor netiquette. > > 2) The fact that many keystrokes produced more than one keystrokes (called > > ligatures there athough the technology can apply to code point > combinations > > that do not, in fact make up ligatures) > > I suppose you speak about complex keyboards that generate variable-size > sequences of characters from multiple keystrokes, using complex input > methods, such as Pinyin input method editors for Chinese. No, I do not. I am speaking of the fact that any keystroke can be mapped to between one and four UTF-16 code points. No CJK implied or expressed, as IMEs have their own unrelated rules. > > 7) No way to explain SGCAPS use of the CAPS lock, used by Hebrew, Czech > and > > others. > > Also the Swiss German keyboard... Actually, ironically, no. The "feature" was added for the sake of that keyboard (thus the "SG" in the name) but it was not, eventually, used there. The name simply stuck. > > 8) No way to describe "custom" shift keys like seen in the [unfortunate] > > Canadian Multilingual Standard keyboard > > Do you mean here a sort of a second AltGr modifier mapped onto an OEM key? Yes > Or about the many dead keys it supports to enter accents used in various > languages? No > > I could go on. but you get the idea. There is no simple list because there > > is no simple format that can describe them. > > Notably the complex keyboards that support multiple scripts or large > scripts: would you show Kangxi radicals on a Chinese keyboard used with a > ideographic radical composition mode, or the ASCII keycap in the Romaji mode > of a Japanese keyboard? Again unrelated to keyboards -- this is an IME issue, not a keyboard issue. It is also nothing to do with Adam's question. Lets get back on topic, please MichKa [MS] NLS Collation/Locale/Keyboard Development Globalization Infrastructure and Font Technologies
Re: Windows and MacOS keyboard layouts in human-readable format?
From: "Michael (michka) Kaplan" <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> > Such a format for Windows would be quite inadequate since it is missing many > things, such as: > > 1) The version of Windows in which it first shipped (there were minor > differences in what was in 9x vs. NT, and on NT some characters were added > to keyboards in later versions). If the intent is to display in a user interface which keystroke the user must press to create a character sequence it can be useful to know the character generated in the default state without modifiers (or the character generated in CAPSLOCK mode). This is an issue for example when creating "accelerators" or keyboard shortcuts in an application and one wants to display this shortcut in menu items or in button tooltips. (For example, how do you display the "mnemonic" in Java menu items, or the "&"-selected character in Windows resources, fo menu items that display non Latin strings such as Chinese or Arabic? You need to display it at end of the menu item, and the underlined convention for mnemonics is not usable. But which string will you display? You need this information support from the keyboard driver itself or an OS API). Designing keyboard shortcuts that will work in internationalized applications is a difficult problem for the localization of applications, and there's no way to do it without knowing the exact keyboard layout actually used, but that may not be knowed precisely at run-time, or may be customized by the user. Not supporting shortcuts is also a problem for accessibility. Unfortunately, Windows does not help the application to select appropriate shortcuts to use to match some prefered "accessible characters present in menu items. There's no automatic generation of these shortcuts from menu item strings, and no automatic display. > 2) The fact that many keystrokes produced more than one keystrokes (called > ligatures there athough the technology can apply to code point combinations > that do not, in fact make up ligatures) I suppose you speak about complex keyboards that generate variable-size sequences of characters from multiple keystrokes, using complex input methods, such as Pinyin input method editors for Chinese. > 7) No way to explain SGCAPS use of the CAPS lock, used by Hebrew, Czech and > others. Also the Swiss German keyboard... > 8) No way to describe "custom" shift keys like seen in the [unfortunate] > Canadian Multilingual Standard keyboard Do you mean here a sort of a second AltGr modifier mapped onto an OEM key? Or about the many dead keys it supports to enter accents used in various languages? > I could go on. but you get the idea. There is no simple list because there > is no simple format that can describe them. Notably the complex keyboards that support multiple scripts or large scripts: would you show Kangxi radicals on a Chinese keyboard used with a ideographic radical composition mode, or the ASCII keycap in the Romaji mode of a Japanese keyboard?
Re: Windows and MacOS keyboard layouts in human-readable format?
Such a format for Windows would be quite inadequate since it is missing many things, such as: 1) The version of Windows in which it first shipped (there were minor differences in what was in 9x vs. NT, and on NT some characters were added to keyboards in later versions). 2) The fact that many keystrokes produced more than one keystrokes (called ligatures there athough the technology can apply to code point combinations that do not, in fact make up ligatures) 3) The fact that in many cases combinations of keystrokes produce a single code point (called dead keys) -- best described by the many combining characters that go with individual base characters 4) No completely consistent description of OEM keys that is based on letters that would work for all keyboard hardware 5) Naming inconsistencies between different versions (rare but present on occasion) 6) No good way to explain when CAPS lock is being used for casing, etc. 7) No way to explain SGCAPS use of the CAPS lock, used by Hebrew, Czech and others. 8) No way to describe "custom" shift keys like seen in the [unfortunate] Canadian Multilingual Standard keyboard I could go on. but you get the idea. There is no simple list because there is no simple format that can describe them. MichKa [MS] NLS Collation/Locale/Keyboard Development Globalization Infrastructure and Font Technologies - Original Message - From: "Adam Twardoch" <[EMAIL PROTECTED]> To: "Mailing List Unicode" <[EMAIL PROTECTED]> Sent: Monday, December 29, 2003 2:03 PM Subject: Windows and MacOS keyboard layouts in human-readable format? > Do you know if there are human-readable versions of Windows and/or MacOS > keyboard layouts available somewhere? > > I'm looking for a way to compile a table that could look a bit like the > following: > > Platform LanguageLayoutUnicodeKeystroke > WindowsPolish Polish (Programmers) 0105AltGr+A > WindowsPolish Polish (Programmers) 0041A > ... > > where I could, for example, look up which exactly keyboard layouts let the > user input, say, a with acute, and how he can do that. > > Thank you in advance, > Adam Twardoch > > > >
