Re: 001B, 001D, 001C

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon Jul 12 2010 - 05:11:47 CDT

  • Next message: Philippe Verdy: "RE: UTS#10 (collation) : French backwards level 2, and word-breakers."

    "a a" <abysta@yandex.ru> wrote on 2010-07-08 at 14:21:
    >
    > Thanks for your replies.
    > I’m developing a keyboard layout based on US (Custom) which has 001B, 001D, 001C, 0020 defined for the Ctrl shift state. I don’t know should I leave them or not. The MKLC help recommends to avoid defining characters for both the Ctrl and Ctrl+Shift shift states, but also says: “You may notice specific keys in the Ctrl shift state are assigned when you load an existing keyboard layout. These key assignments are used in certain legacy applications like Microsoft HyperTerminal and should usually not be removed.”

    Note that there are still a lot of applications that depend on being
    able to enter ALL the possible ASCII controls, and this includes
    various terminal protocols, including those for Unix/Linux (notably
    CTRL+D which should still be mapped to an ASCII control, even if those
    keys are marked, on Windows and X11 protocols at least, as out-of-band
    non-character system commands, just like other function keys like
    F1..F12, cursor control arrows, and even the Enter or Backspace and
    Delete keys)

    But if you use a VT-like terminal emulation, including the
    DOS-compatible "ANSI" emulation in the Windows console, or
    applications that just use the low-level BIOS emulation (or other
    legacy protocols through a serial link) that does not support marking
    those sequences as out-of-band, the only thing that will be
    transmitted is the control itself for each function key (that's why
    Unix/Linux shells and editors like Vi or Emacs do not depend on
    out-of-band marking of function keys, but still depend on the keyboard
    driver to generate these controls or escape sequences, both for input
    and output).

    So keyboard drivers will require you to assign somewhere on the
    keyboard map a position appropriate for each ASCII control. Note that
    these positions are dependant of the national layout of letters
    (notably CTRL+Q vs. CTRL+A, or CTRL+W vs. CTRL+Z vs. CTRL+Y), but even
    more critically all those controls that are typically entered as
    CTRL+ASCII punctuation (e.g. CTRL+@ for entering NUL : on the French
    keyboard '@' is entered as AltrGr+0 or Ctrl+Alt+0, without a Shift,
    and CTRL+@ used to enter the NUL would fall on Ctrl+0, without using
    Shift).

    But if you look at the various national keyboards, those punctuations
    are only accessible with the Shift key, and even sometimes using the
    AltGr key, so these controls will also be entered at the same mnemonic
    positions, sometimes with a needed Shift because two of the needed
    ASCII punctuations fall on the same key).

    The 'Esc' key should also be mapped to the ESCAPE control of ASCII,
    but there will still be a distinction from the regular input of Ctrl+[
    in terminals, because the Esc key will be also marked as a system
    function, notably for GUI applications (e.g. to close a dialog). So
    the Esc key is not the proper way to enter the ESCAPE control needed
    in terminals or Unix editors for escape sequences.

    What Microsoft says is that all CTRL+key or CTRL+SHIFT+key, where key
    is on one of the four rows of the alphanumeric and punctuation area,
    should be reserved for entering ASCII controls, and should not be used
    for entering ASCII control characters (and you cannot expect that
    CTRL+1..CTRL+9 and CTRL+0 will be available for other
    application/system commands. A keyboard validation should ensure that
    all ASCII controls are mapped on the keyboard layout, along with other
    printable characters needed for ISO 646 IRV; some other ASCII
    punctuation that are not in the ISO 646 IRV may require using
    AltGr=Ctrl+Alt on the keyboard map.

    If an application still wants to assign a function to CTRL+digit (or
    CTRL+SHIFT+digit if digits), should not assume that it will be
    available (as it may be mapped in a layout to enter a regular control
    character). One way to solve the problem is to make sure that the
    application allows user configurable shortkeys for system commands.

    Windows for example allows the user to specify his shortcuts as
    CTRL+SHIFT+alphanumeric, or SHIFT+ALT+alphanumeric, but also allows
    the user to select the modifier keys ; but it correctly forbids, in
    the standard GUI of its builtin applications, shell and control
    panels, and in its international design guides for conforming
    applications, the assignment of CTRL+ALT+alphanumeric key (equivalent
    to AltGr+alphanumeric) and of CTRL+ALT+SHIFT+alphanumeric (equivalent
    to AltGr+SHIFT+alphanumeric) because it may conflict with keyboard
    drivers or input methods needed to enter some characters.

    But NO keymap should assign any character to CTRL+key or to
    CTRL+SHIFT+key, where the key pressed alone is mapped for letters
    A..Z: these 26×2 positions in the keyboard layout mapping should be
    left free for applications (that will chooe themselves if they want to
    use them for entering applications functions, or if they want to
    generate a control, with or without the Shift distinction).

    Given that the controls U+0000, U+001B..U+001F, and U+007F do not map
    traditionally as CTRL+ASCII letter, you can (and should) perfectly
    place them all, on any other non-letter key of the keyboard layout
    that will be convenient and mnemonic, using either CTRL or ALT,
    possibly in combination with SHIFT, but not CTRL+ALT (or ALTGR)
    together, and not CTRL+ALT+SHIFT (or ALTGR+SHIFT) : all the remaining
    CTRL+keys, where key is in the main alphanumeric part but not part of
    the alphabetic keys [A]..[Z], are perfectly assignable for mapping
    these seven controls.

    Note that most keyboards don't have two ALT keys : the ALTGR is placed
    where the US keyboard places the second (right) ALT key. Applications
    should not depend on which ALT has been pressed, except in
    applications not using them for entering text (such as games), in
    which case the ALTGR key will behave exactly like the second ALT (but
    it will also activate the CTRL state at the same time, that can't be
    disabled as it is full part of the national keyboard behavior...).

    Some applications may still detect if a CTRL key was really pressed or
    if the CTRL state is enabled as the result of pressing AltGr, by
    looking at extended state bits (but many applications forget to look
    at those extra state bits, and behave extremely badly when one just
    wants to enter a national character with AltGr and the applications «
    thinks » that a system command was requested, for example by closing a
    window of flushing/resetting an input form): these applications have
    typically been designed by poor US programmers that are not aware of
    international requirements where the second ALT (AltGr) should never
    be used as an application command even if the CTRL state is enabled.

    Note that Windows keyboard drivers contain a flag bit in their layout,
    saying if the AltGr semantic is needed and fully reserved for the
    national layout use (it will fully replace the second ALT feature). In
    this case, it will NEVER generate a WM_SYSCHAR containing a
    system/application command to applications, but may generate a WM_CHAR
    if there's a character mapped on this key, after it has been
    translated to a character using the layout data.

    Applications can then behave correctly, if they are correctly
    programmed and never mix WM_CHAR and WM_SYSCHAR messages in their GUI
    message loop, and if they severely restrict their own assignments of
    keyboard shortcuts within the alphanumeric and punctuation areas of
    the keyboard

    There's much less restrictions for the numeric keypad, and for the
    "Function" keys (excepting the few global system shortcuts for Shell
    controls, that are now preferably mapped using the separate "Windows"
    and "Menu/Application" keys on PC keyboards, or the Apple "Option" and
    "Cmd" keys on Mac keyboards.

    And the "Fn" key typically found on notebooks are reserved for
    controlling media-player and hardware features (like Volume +/-/Mute,
    Play/pause/stop, Next/previous track, Wifi on/off, image
    lightness/contrast, or switching on/off alternate display outputs,
    entering/resuming power sleep mode, or user-configurable shortcuts to
    launch a browser or read emails), that national keyboard maps should
    not use for entering actual characters, as these mappings will remain
    invisible to applications, but visible only to specific low-level
    hardware drivers with their specific system control panels for their
    configuration by the user.

    -- Philippe.



    This archive was generated by hypermail 2.1.5 : Mon Jul 12 2010 - 05:18:58 CDT