Ilya Zakharevich > UI-KeyboardLayout-0.65 > UI::KeyboardLayout::izKeys


Annotate this POD

View/Report Bugs
Source   Latest Release: UI-KeyboardLayout-0.68


UI::KeyboardLayout::izKeys - example keyboard layout generated with UI::KeyboardLayout


  #!/usr/bin/perl -wC31
  use UI::KeyboardLayout; 
  use strict;
  for my $F (qw(US CyrillicPhonetic)) {         
        # Open file, select() 


Ilya Zakharevich,

Design goals ^

Design goals for izKeys keyboard group:


No gotchas for people who cannot remember anything.



      for Ancient Greek than for Math Symbols.





Have whole coverage of certain ranges of Unicode.

Currently achieved (ranges as of Unicode v6.1):

Not yet implemented, or lost by upgrades to other goals:

Possible roadmaps:

Personalities of keyboard ^

General architecture


Currently, the result of a key press is governed by two modifiers: Shift and AltGr; so a key may generate 4 characters. On letter keys, Shift changes a case; so there are 2 case pairs assigned to a key (the "base" character, and "alternative" one); on symbols, there is usually no relationship between Shifted and unShifted symbols (compare / and ? on the US keyboard); to compensate for this, a lot of effort goes to make AltGr-ing a key to have more logical connections.

Every personality has a few personality-specific prefix keys (to access accented and other "more exotic" characters of Latin/Cyrillic scripts). Additionally, there are prefix keys to access "common pools" of extra characters (so-called Green Keys, Greek, Business symbols etc). To finish, there is a common "AltGr-access" prefix key which emulates pressing the AltGr-modifier with the key (especially useful when an application or a system steals some particular AltGr-letter combinations to become hotkeys). (Currently, this prefix key is AltGr-Shift-SPACE.)

The Base Layer of Latin Personality

This base layer is identical to US keyboard. In particular, there is no prefix keys on the base layer (except Shift-SPACE!); all other prefix keys require pressing AltGr-modifier. So there is no gotchas with this leyout if one does not use AltGr-modifier or Shift-SPACE.

NOTE: Many people do not realize this, but there is one scenario where people actually press Shift-SPACE: it happens when typing CAPITALIZED PHRASES by keeping Shift pressed all the time. When Shift-SPACE is a prefix key, when pressed between ZED and PHR in CAPITALIZED PHRASES, it would consume the following keypress for P. In particular, the SPACE will not entered, and instead of P the Cyrillic counterpart П will appear. Since the result CAPITALIZEDПHRASES differs so much from the original, such situations are easy to recognize and compensate for.

AltGr-access to Latin-1 characters

The most widely used Latin characters outside the ISO basic Latin alphabet (which is the PC name for "English Alphabet") are made accessible via AltGr-modifier. The leading principle of assigning positions to these letters is not the considerationa of mechanics of finger movement, but a simplicity of memorization of position of these keys on keyboard.

These characters are the vowels AEYUIO with "simplest" accents diaeresis=umlaut=trema, acute and grave (except for extremely rare Ë and Ỳ), "the additional" Latin-1 letters ÆÅÇÐĲÑŒØßÞ and symbols ªº¡¿№ which cannot be entered using most obvious prefix keys - and we throw in the most useful of other letters, êÊ.

Two rules govern the allocation of the letters to alphabetic keys (modified by AltGr):

  1. The "additional" letters ÆÅÇÐĲÑŒØßÞ are assigned to the "closest" base Latin letters (ACDINOST). (When conflicts arise - Æ vs Å, Œ vs Ø - the digraph wins.)
  2. The characters with simplest accents ¨´` are assigned in the "diagonal of the base vowel" in ¨=top, ´=middle, `=bottom rows of the 3 alphabetic rows of the keyboard.

For example, the wishful-thinking positions for characters ÄÁÀ is on keys QAZ (left-hand vowels' diagonals are sloping to the left) and the wishful thinking positions for characters ÖÓÒ are on keys OKM (right-hand vowels' diagonals are sloping to the right). When conflicts arise, the rule 1 wins, and the losing ¨´`-accented vowel is pushed away 1 step from the diagonal (down if possible, otherwise down). For example, by rules above, both Æ and Á want to be on the A key; so Á is pushed away; there is no key "away from QAZ-diagonal down", so it goes "away from QAZ-diagonal up" to W key. Likewise, Œ pushes away Ö is from O down to L.

This does not say what to do with ÅØÏÌ, and alphabetic keys RP are not used. Moreover, this does allocate ỲË which are (comparing to unallocated letters) not in widespread usage. So one adds:

EXCEPTIONS: Ê is on E, Ì is pushed away 2 steps left to the wishful-thinking position of on V, Ø is pushed 1 step to the right to P, and Å is on R.

For non-alphabetic symbols, ¡¿№ are on most natural positions !?#; ª is put on the closest non-alphabetic key @, and º is put on the same key but without Shift.

NOTE: our sloping rule for right-hand diagonals makes all diagonals go over alphabetic keys of US keyboard. This allows for AltGr-alphabetic keys generate alphabetic characters, and AltGr-symbol keys generate symbols.

AltGr-access to non-math symbols

is put at the position on the keyboard most often etched with this symbol (which is 5), and ¥ is on the same key shifted. ¢£ are put on 4$ (but AltGr-$ is a dead key for Business-related symbols, follow it by SPACE to get the £ character!).

The Base Layer of Cyrillic Personality


Where are two remaining Russian alphabet characters, ъЪ and ёЁ? On the base layer, they are on Shifted digit keys 3456 (in other words, on #$%^ - which is not very intuitive. (To compensate, these letters are considered AltGr-variants of ЬЕ, so they are available on both the Base Layer, and on AltGr-layer. [Unfortunately, this leads to certain problems on Windows - so called ъЪёЁ-mirroring; more on this later.])

In particular, the most commonly used symbols are available at the same locations as on US keyboard, but the symbols `~#$%^+=[{]}\| cannot be entered from the base layer of the Cyrillic personality. (To compensate, they are all available when one types them with AltGr-modifier; and for #$%^ obscured by ъЪёЁ one does not need to use Shift-modifier.)

What follows is a collection of odd pieces of old documentation ^

... but most of it is relevant, though not necessarily exposed in the most convenient order...








Unicode table examiner

distills relations between different Unicode characters from the Unicode tables, and combines the results with user-specified "manual mogrification" rules. From these automatic/manual mogrifications, it constructs orthogonal scaffolding supporting Unicode characters (we call it composition/decomposition, but it is a major generalization of the corresponding Unicode consortium's terms).

Layout constructor


System-specific software layouts

may be created basing on the "theoretical layout" made by the layout constructor (currently only on Windows, and only via KBDUTOOL route).

Report/Debugging framework


The last (and, probably, the most important) component of the distribution is an example keyboard layout created using this toolset.

Keyboards: on ease of access ^




For them, the details of the keyboard layout are important mostly in the relation to how much they distract the writer from the other things the writer is focused on. The primary question is now not "how easy it is to type this", but "how easy it is to recall how to type this". The focus transfers from the mechanics of finger movements to the psycho/neuro/science of memory.




NOTE: the version 0.01 of this module supports only the standard US layout of the base keys.



Essentially, this means that as far as it does not impacts other accessibility goals, it makes sense to have unified memorizable access to as many symbols/characters as possible. (An example of impacting other aspects: MicroSoft's (and IBM's) "US International" keyboards steal characters `~'^": typing them produces "unexpected results" - they are deadkeys. This significantly simplifies entering characters with accents, but makes it harder to enter non-accented characters.)





By parts:



Quick access:

As many non-basic letters as possible (of those expected to appear often) should be available via shortcuts. Same should be applicable to starting sequences of composition rules (such as "instead of typing StartCompose and ' one can type AltGr-').

Smart access

Certain non-basic characters may be accessible by shortcuts which are not based on composition rules. However, these shortcuts should be deducible by using simple mneumonic rules (such as "to get a vowel with `-accent, type AltGr-key with the physical keyboard's key sitting below the vowel key").



NOTE: This does not seem to be easily achievable, but it looks like a very nifty UI: a certain HotKey is reserved (e.g., AltGr-AppMenu); when it is tapped, and a character-key is pressed (for example, B) a menu-driven interface pops up where user may navigate to different variants of B, Beta, etc - each of variants with a hotkey to reach NOW, and with instructions how to reach it later from the keyboard without this UI.


Here are the finer points elaborating on these levels of complexity:



  4. One should consider what the Quick_Access_Key does when the layouts A and B are identical on a particular key. One can go with the "Occam's razor" approach and make Quick_Access_Key the do-nothing identity map. Alternatively, one can make it access some symbols useful both for script A and script B. It is a judgement call.

    Note that there is a gray area when layouts A and B are not identical, but a key K produces punctuation in layout A, and a letter in layout B. Then when in layout B, this punctuation is available on AltGr-key, so, in principle, Quick_Access_Key would duplicate the functionality of AltGr. Compare with "there is more than one way to do it" below; remember that OS (or misbehaving applications) may make some keypresses "unavailable". I feel that in these situations, having duplication is a significant advantage over "having some extra symbols available".



  7. for symbols that are naturally thought of as sitting in a table, one can create intuitive mapping of quite large tables to the keyboard. Split each key in halves by a horizontal line, think of Shift-key as sitting in the top half. Then ignoring `~ key and most of punctuation on the right hand side, keyboard becomes an 8×10 grid. Taking into account AltGr, one can map up to 8×10×2 (or, in some cases, 8×20!) table to a keyboard.

    Example: Think of IPA consonants.



  9. "There is more than one way to do it" is not a defect, it is an asset. If it is a reasonable expectation to find a symbol X on keypress K', and the same holds for keypress K'' and they both do not conflict with other "being intuitive" goals, go with both variants. Same for 3 variants, 4 - now you get my point.

    Example: The standard Russian phonetic layout has Ё on the ^-key; on the other hand, Ё is a variant of Е; so it makes sense to have Ё available on AltGr-Е as well. Same for Ъ and Ь.

  10. Dead keys which are "abstract" (as opposed to being related to letters engraved on physical keyboard) should better be put on modified state of "zombie" keys of the keyboard (SPACE, TAB, CAPSLOCK, MENU_ACCESS).

    NOTE: Making Shift-Space a prefix key may lead to usability issues for people used to type CAPITALIZED PHRASES by keeping Shift pressed all the time. As a minimum, the symbols accessed via Shift-SPACE key should be strikingly different from those produced by key so that such problems are noted ASAP. Example: on the first sight, producing NO-BREAK SPACE on Shift-Space Shift-Space or Shift-Space Space looks like a good idea. Do not do this: the visually undistinguishable NO-BREAK SPACE would lead to significantly hard-to-debug problems if it was unintentional.

Explanation of keyboard layout terms used in the docs ^


Unfortunately, being on unchartered territories, in my explanations I'm forced to use home-grown terms. So be patient with me... The terms are keyboard group, keyboard, face and layer. (I must compare them with what ISO 9995 does:

In what follows, the words letter and character are used interchangeably. A key means a physical key on a keyboard clicked (possibly together with one of modifiers Shift, AltGr - or, rarely Control. The key AltGr is either marked as such, or is just the "right" Alt key; at least on Windows it can be replaced by Control-Alt. A prefix key is a key tapping which does not produce any letter, but modifies what the next keypress would do (sometimes it is called a dead key; in ISO 9995 terms, it is probably a latching key).

A plain layer is a part of keyboard layout accessible by using only non-prefix keys (possibly in combination with Shift); likewise, additional layers are parts of layout accessible by combining the non-prefix keys with Shift (if needed) and with a particular combination of other modifiers (AltGr or Control). So there may be up to 2 additional layers: the AltGr-layer and Control-layer.

On the simplest layouts, such as "US" or "Russian", there is no prefix keys - but this is only feasible for languages which use very few characters with diacritic marks. However, note that most layouts do not use Control-layer - it is stated that this might be subject to problems with system interaction.

The primary face consists of the plain and additional layers of a keyboard; it is the part of layout accessible without switching "sticky state" and without using prefix keys. There may be up to 3 layouts (Primary, AltGr, Control) per face (on Windows). A secondary face is a face exposed after pressing a prefix key.

A personality is a collection of faces: the primary face, plus one face per a defined prefix-key. Finally, a keyboard group is a collection of personalities (switchable by CapsLock and/or personality change hotkeys like Shift-Alt) designed to work smoothly together.







Assume that the layout does not use the Control modifier. Then each of these faces would consists of two layers: the plain one, and the AltGr- one. For example, pressing AltGr with a key on Greek face could add diaeresis to a vowel, or use a modified ("final" or "symbol") "glyph" for a consonant (as in σ/ς θ/ϑ). Or, on Latin face, AltGr-a may produce æ. Or, on a Cyrillic personality, AltGr-я (ya) may produce ѣ (yat').





CORE faces



Universally accessible faces


satellite faces



Access to diacritic marks ^

The logic: prefix keys are either 8-bit characters with high bit set, or if none with the needed glyph, they are "spacing modifier letters" or "spacing clones of diacritics". And if you type something after them, you can get other modifier letters and combining characters: here is the logic of this:

The second press

The principal combining mark.

Surrogate for the diacritic

(either " or '): corresponding "prime shape"-modifier character


The modifier character itself.



Some stats on prefix keys: ISO 9995-3 uses 26 prefix keys for diacritics; bépo uses 20, while EurKey uses 8. On the other end of spectrum, there are 10 US keyboard keys with "calculatable" relation to Latin diacritics:


To this list one may add a "calculatable" key $ as the currency prefix; on the other hand, one should probably remove ? since AltGr-? should better be "set in stone" to denote ¿. If one adds Greek, then the calculatable positions for aspiration are on [ ] (or on ( )). Of widely used Latin diacritics, this leaves ring/hacek/breve/horn/ogonek/comma (and doubled grave/acute).

CAVEATS for BÉPO keyboard:




The keyboard generated with this layout:

The generator module: UI::KeyboardLayout and reference therein: see "SEE ALSO" in UI::KeyboardLayout.

On diacritics:                 (Chars of languages)

     Accents in different Languages:,12,inne_diakrytyki.htm#07
     Typesetting Old and Modern Church Slavonic

On typography marks

On keyboard layouts:           (used almost nowhere - only half of keys in Canadian multilanguage match)
      Discussion of layout changes:                     (Old Irish mechanical typewriters)                    (One-handed layout)   (and references there)
      Images in (download of)
      Neo2 sources:
      Shift keys at center, nice graphic:
      Physical keyboard:
      Portable keyboard layout
      Typing on numeric keypad
      On screen keyboard indicator
      With 2-letter input of Unicode names:

      Chaining dead keys:
      Mapping VK to VSC etc:
      [Link] Remapping CapsLock to mean Backspace in a keyboard layout
            (if repeat, every second Press counts ;-)
      Scancodes from kbd.h get in the way
      Keyboards with Ctrl-Shift states:
      On assigning Ctrl-values
      On hotkeys for switching layouts:
      Text services
      Low-level access in MSKLC
      On font linking
      Unicode in console
      Adding formerly "invisible" keys to the keyboard
      Redefining NumKeypad keys
      And backspace/return/etc
      Doing one's own WM_DEADKEY processing'
      Dead keys do not work on SG-Caps
      Dynamic keycaps keyboard
      Backslash/yen/won confusion
      Unicode output to console
      Install/Load/Activate an input method/layout
      Suggest a topic:

VK_OEM_8 Kana modifier - Using instead of AltGr Limitations of using KANA toggle

HTML consolidated entity names and discussion, MES charsets:


Low level scancode mapping


CapsLock as on typewriter:

Problems on X11:                   (definition of XKB???)                     (current???)                       (current???)        (current???)                  (documents almost 1/2 of the needed stuff)                                        (2005++ ???)    (2009++ HAS: How to make CapsLock change layouts)                                (of 2008???)                                     (of 2005???)                           (of 1999???)



Note: have XIM input method in GTK disables Control-Shift-u way of entering HEX unicode.



Latin paleography       (Uncomplete???)        (No prioritization...)

Summary tables for Cyrillic                 - per language tables

     Extra chars (see also the ordering table on page 8)

    Table with Unicode points marked:
    (Extended) IPA explained by consortium:
    IPA keyboard

Is this discussing KBDNLS_TYPE_TOGGLE on VK_KANA???

Windows: fonts substitution/fallback/replacement

Problems on Windows:

          (preferably newer versions).

Display (how WikiPedia does it):

Windows shortcuts:

On meaning of Unicode math codepoints

Zapf dingbats encoding, and other fine points of AdobeGL:

Quoting tchrist: You can snag unichars, uniprops, and uninames from if you like.




Currently no LIGATURES are supported.





APL symbols with UP TACK and DOWN TACK look reverted w.r.t. other UP TACK and DOWN TACK symbols. (We base our mutation on the names, not glyphs.)

LESS-THAN, FULL MOON, GREATER-THAN, EQUALS GREEK RHO, MALE are defined with SYMBOL or SIGN at end, but (may) drop it when combined with modifiers via WITH. Likewise for SUBSET OF, SUPERSET OF, CONTAINS AS MEMBER, PARALLEL TO, EQUIVALENT TO, IDENTICAL TO.

Sometimes opposite happens, and SIGN appears out of blue sky; compare:


ENG is a combination of n with HOOK, but it is not marked as such in its name.

Sometimes a name of diacritic (after WITH) acquires an ACCENT at end (see U+0476).

Oftentimes the part to the left of WITH is not resolvable: sometimes it is underspecified (e.g, just TRIANGLE), sometimes it is overspecified (e.g., in LEFT VERTICAL BAR WITH QUILL), sometime it should be understood as a word (e.g, in END WITH LEFTWARDS ARROW ABOVE). Sometimes it just does not exist (e.g., LATIN LETTER REVERSED GLOTTAL STOP WITH STROKE - there is LATIN LETTER INVERTED GLOTTAL STOP, but not the reversed variant). Sometimes it is a defined synonym (VERTICAL BAR).

Sometimes it has something appended (N-ARY UNION OPERATOR WITH DOT).

Sometimes WITH is just a clarification (RIGHTWARDS HARPOON WITH BARB DOWNWARDS).

  1     AND
  1     ANTENNA
  1     BACK
  1     BLACK SUN
  1     BRIDE
  1     COUPLE
  1     END
  1     FISH CAKE
  1     GLOBE
  1     HEAVY OVAL
  1     HELMET
  1     MONEY
  1     NIGHT
  1     ON
  1     OR
  1     PAGE
  1     SMALL VEE
  1     SOON
  1     SQUARED UP
  1     TOP
  1     WHITE SUN
  2     HEART
  2     LEFT ARROW
  2     PARALLEL
  2     TIMES
  3     CHART
  3     CONTAINS
  3     TRIANGLE
  4     BANKNOTE
  4     DIAMOND
  4     PERSON
  11    CIRCLE
  11    FACE
  15    SQUARE


SQUARE WITH specify fill - not combining. FACE is not combining, same for HARPOONs.

Only CIRCLE WITH HORIZONTAL BAR is combining. Triangle is combining only with underbar and dot above.


Another way of compositing is OVER (but not UNDER!) and FROM BAR. See also ABOVE, BELOW - but only BELOW LONG DASH. Avoid WITH/AND after these.


HEART means WHITE HEART SUIT. TRIPLE HORIZONTAL BAR looks genuinely missing...

SEMIDIRECT PRODUCT means one of two, left or right???

This better be convertible by rounding/sharpening, but see BUT NOT/WITH NOT/OR NOT/AND SINGLE LINE NOT/ABOVE SINGLE LINE NOT/ABOVE NOT

  2268    LESS-THAN BUT NOT EQUAL TO;             1.1
  2269    GREATER-THAN BUT NOT EQUAL TO;          1.1
  228A    SUBSET OF WITH NOT EQUAL TO;            1.1
  228B    SUPERSET OF WITH NOT EQUAL TO;          1.1
  @               Relations
  22E4    SQUARE IMAGE OF OR NOT EQUAL TO;                1.1
  22E5    SQUARE ORIGINAL OF OR NOT EQUAL TO;             1.1
  @@      2A00    Supplemental Mathematical Operators     2AFF
  @               Relational operators
          x (less-than but not equal to - 2268)
          x (greater-than but not equal to - 2269)
  2AB5    PRECEDES ABOVE NOT EQUAL TO;            3.2
  2AB6    SUCCEEDS ABOVE NOT EQUAL TO;            3.2
  @               Subset and superset relations
  2ACB    SUBSET OF ABOVE NOT EQUAL TO;           3.2

Looking into v6.1 reference PDFs, 2268,2269,2ab5,2ab6,2acb,2acc have two horizontal bars, 228A,228B,22e4,22e5,2a87,2a88,2ab1,2ab2 have one horizontal bar, Hence BUT NOT EQUAL TO and ABOVE NOT EQUAL TO are equivalent; so are WITH NOT EQUAL TO, OR NOT EQUAL TO, AND SINGLE-LINE NOT EQUAL TO and ABOVE SINGLE-LINE NOT EQUAL TO. (Square variants come only with one horizontal line?)

Set $ENV{UI_KEYBOARDLAYOUT_UNRESOLVED} to enable warnings. Then do



Copyright (c) 2011-2012 Ilya Zakharevich <>


The distributed examples may have their own copyrights.




Soft hyphen as a deadkey may be not a good idea: following it by a special key (such as Shift-Tab, or Control-Enter) may insert the deadkey character??? Hence the character should be highly visible... (Now the key is invisible, so this is irrelevant...)




Interaction of FromToFlipShift with SelectRX not intuitive. This works: Diacritic[<sub>](SelectRX[[0-9]](FlipShift(Latin)))



via_parent() is broken - cannot replace for Diacritic_if_undef.


dotted circle ◌ 25CC






Need to treat upside-down as a pseudo-decomposition.


When creating a <pseudo-stuff> treat SYMBOL/SIGN/FINAL FORM/ISOLATED FORM/INITIAL FORM/MEDIAL FORM; note that SIGN may be stripped: LESS-THAN SIGN becomes LESS-THAN WITH DOT



Inspector tool for NamesList.txt:




WarnConflicts[exceptions] and NoConflicts translation map parsing rules.












Work with slots one-by-one (so that the assignent is "monotinic" when the number of slots increases). Let m be the number of layers where slots are present. Take highest priority combinations; if the number of "extra" combinations in the primary layer is at least m, distribute the first m of them to secondary layers. If n<m of them are present, fill k layers which have no their own combinations first, then other n-k layers. More precisely, if n<=k, use the first n of "free" layers; if n>k, fill all free layers, then the last n-k of non-free layers.






  the higher priority bindings would occupy the hottest slots in both
  direct and reverse bindings...

  Maybe additional forms Diacrtitics2S_* and Diacrtitics2E_* which fight





Compare with: 8 basic accents: (English 78)


Problem: acute on acute makes double acute modifier...





╽ ╿ ╎┆┊╏┇┋






On the other hand, the behaviour of chained keys is governed ONLY by Unicode characters they generate: if there are several physical keypresses generating the same Unicode characters, these keypresses are completely interchangeable inside a chained sequence. (The only restriction is that the first keypress should be marked as "prefix key"; for example, there may be two keys producing - so that one is producing a "real dash sign", and another is producing a "prefix" -.)


The numbered choices above are determined by the state of "modifier keys" (such as Shift, Alt, Control), but not directly. First of all, VK_keys may be associated to a certain combination of 6 "modifier bits" (called "logical" Shift, Alt, Control, Kana, User1 and User2, but the logical bits are not required to coincide with names of modifier keys). (Example: bind Right Control to activate Shift and Kana bits.) The 64 possible combinations of modifier bits are mapped to the numbered choices above.

Additionally, one can define two "separate numbered choices" in presence of CapsLock (but the only allowed modifier bit is Shift). The another way to determine what CapsLock is doing: one can mark that it flips the "logical Shift" bit (separately on no-modifiers state, Control-Alt-only state, and Kana-only state [?!] - here "only" allow for the Shift bit to be ON).

AltGr key is considered equivalent to Control-Alt combination (of those are present, or always???), and one cannot bind Alt and Alt-Shift combinations. Additionally, binding bare Control modifier on alphabetical keys (and SPACE, [, ], \) may confuse some applications.

NOTE: there is some additional stuff allowed to be done (but only in presence of Far_East_Support installed???). FE-keyboards can define some sticky state (so may define some other "latching" keys in addition to CapsLock). However, I did not find a clear documentation yet (keyboard106 in the DDK toolkit???).

There is a tool to create/compile the required DLL: kbdutool.exe of MicroSoft Keyboard Layout Creator (with a graphic frontend MSKLC.exe). The tool does not support customization of modifier bits, and has numerous bugs concerning binding keys which usually do not generate characters. The graphic frontend does not support chained prefix keys, adds another batch of bugs, and has arbitrarily limitations: refuses to work if the compiled version of keyboard is already installed; refuses to work if SPACE is redefined in useful ways.

WORKFLOW: uninstall the keyboard, comment the definition of SPACE, load in MSKLC and create an install package. Then uncomment the definition of SPACE, and compile 4 architecture versions using kbdutool, moving the DLLs into suitable directories of the install package. Install the keyboard.


Several similar MSKLC created keyboards may confuse the system

Apparently, the system may get majorly confused when the description of the project gets changed without changing the DLL (=project) name.

(Tested only with Win7 and the name in the DESCRIPTIONS section coinciding with the name on the KBD line - both in *.klc file.)


  1. Click on the keyboard icon in the Language Bar - usually shown on the toolbar; positioned to the right of the language code EN/RU etc (keyboard icon is not shown if only one keyboard is associated to the current language).
  2. Go to the Input Language settings (e.g., right-click on the Language bar, Settings, General.

  3. on this General page, press Add button, go to the language in question.

  4. Check the .klc files for recently installed Input Languages.

  5. In MS Keyboard Layout Creator, go to File/Load Existing Keyboard list.


Another symptom: Current language indicator (like EN) on the language bar disappears. (Reboot time?)

Possible workaround: manually remove the entry in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Keyboard Layouts (the last 4 digits match the codepage in the .klc file).

Too long description (or funny characters in description?)

If the name in the DESCRIPTIONS section is too long, the name shown in the list 2 above may be empty.

(Checked only on Win7 and when the name in the DESCRIPTIONS section coincides with the name on the KBD line - both in *.klc file.)

(Fixed by shortening the name [but see "Several similar MSKLC created keyboards may confuse the system" above!], so maybe it was not the length but some particular character (+?) which was confusing the system. (I saw a report on MSKLC bug when description had apostroph character '.)

MSKLC ruins names of dead key when reading a .klc

When reading a .klc file, MS Keyboard Layout Creator may ruin the names of dead keys. Symptom: open the dialogue for a dead key mapping (click the key, check that Dead key view has checkmark, click on the ... button near the Dead key? checkbox); then the name (the first entry field) contains some junk. (Looks like a long ASCII string

   U+0030 U+0030 U+0061 U+0039


Workaround: if all one needs is to compile a .klc, one can run KBDUTOOL directly.

Workaround: correct ALL these names manually in MSKLC. If the names are the Unicode name for the dead character, just click the Default button near the entry field. Do this for ALL the dead keys in all the registers (including SPACE!). If CapsLock is not made "semantically meaningful", there are 6 views of the keyboard (PLAIN, Ctrl, Ctrl+Shift, Shift, AltGr, AltGr+Shift) - check them all for grayed out keys (=deadkeys).

Check for success: File/"Save Source File As, use a temporary name. Inspect near the end of the generated .klc file. If OK, you can go to the Project/Build menu. (Likewise, this way lets you find which deadkey's names need to be fixed.)

!!! This is time-consuming !!! Make sure that other things are OK before you do this (by Project/Validate, Project/Test).


Double bug in KBDUTOOL with dead characters above 0x0fff

This line in .klc file is treated correctly by MSKLC's builtin keyboard tester:


However, via kbdutool it produces the following two bugs:

  static ALLOC_SECTION_LDATA MODIFIERS CharModifiers = {
    //  Modification# //  Keys Pressed
        0,            // 
        1,            // Shift 
        2,            // Control 
        SHFT_INVALID, // Shift + Control 
        SHFT_INVALID, // Menu 
        SHFT_INVALID, // Shift + Menu 
        3,            // Control + Menu 
        4             // Shift + Control + Menu 
  static ALLOC_SECTION_LDATA LIGATURE2 aLigature[] = {
    {VK_SPACE     ,6      ,0x2009   ,0x2009   },
    {VK_SPACE     ,7      ,0x200a   ,0x200a   },

Essentially, 2009@ 200a@ produce LIGATURES (= multiple 16-bit chars) instead of deadkeys. Moreover, these ligatures are put on non-existing "modifications" 6, 7 (the maximal modification defined is 4; so the code uses the Shift + Control + Menu flags instead of "modification number" in the ligatures table.

Default keyboard of an application


AltGr-keypresses going nowhere



I found out one scenario how this might happen, and how to fix this particular situation. (Unfortunately, it is not fixed what I see, when AltGr-s [but not AltGr-S] is stolen. Installing a shortcut, one can associate a hotkey to the shortcut. Unfortunately, the UI allows (and encourages!) hotkeys of the form <Control-Alt-letter> (which are equivalent to AltGr-letter) - instead of safe combinations like Control-Alt-F4 or Alt-Shift-letter (which do not go to keyboard drivers, so cannot generate characters). If/when an application linked to by this shortcut is gone, the hotkey remains, but now it does nothing (no warning or dialogue comes).

If the shortcut is installed in one of "standard places", one can find it. Save this to K:\findhotkey.vbs (replace K: by the suitable drive letter here and below)

  on error resume next
  set WshShell = WScript.CreateObject("WScript.Shell")
  Dim A
  Dim Ag
  Set Ag=Wscript.Arguments
  If Ag.Count > 0 then
  For x = 0 to Ag.Count -1
  A = A & Ag(x)
  End If
  Set FSO = CreateObject("Scripting.FileSystemObject")
  set lnk = WshShell.CreateShortcut(A)
  If lnk.hotkey <> "" then
  msgbox A & vbcrlf & lnk.hotkey
  End If

Save this to K:\findhotkey.cmd

  set findhotkey=k:\findhotkey
  cd /d %UserProfile%\desktop
  cd /d %AllUsersProfile%\desktop
  cd /d %UserProfile%\Start Menu
  cd /d %AllUsersProfile%\Start Menu
  cd /d %APPDATA%

(In most situations, only the section after the last cd /d is important; in my configuration all the "interesting" stuff is in %APPDATA%. Running this should find all shortcuts which define hot keys.

Run the cmd file. Repeat in the "All users"/"Public" directory. It should show a dialogue for every shortcut with a hotkey it finds. (But, as I said, it did not fix my problem: AltGr-s works in MSKLC test window, and nowhere else I tried...)

"There was a problem loading the file" from MSKLC

Make line endings in .klc DOSish.

AltGr-keys do not work

Make line endings in .klc DOSish (when given as input to kbdutool - it gives no error messages, and deadkeys work [?!]).

syntax highlighting: