Re: Dead keys (was: "Re: Monetary decimal separators")

From: Philippe Verdy (
Date: Sun Sep 18 2005 - 03:38:10 CDT

  • Next message: Lateef Sagar: "Re: Arabic Script: A new Hamza is required for Urdu and Sindhi"

    From: "Jukka K. Korpela" <>
    > On Sun, 18 Sep 2005, Philippe Verdy wrote:
    >> From: "Anto'nio Martins-Tuva'lkin" <>
    >>> On 2005.09.17, 19:23, Philippe Verdy <> wrote:
    >>>> keyboard in Widows drivers, by SILENTLY replacing the keys for ASCII
    >>>> backquote and ASCII tilde by deadkeys for the COMBINING GRAVE ACCENT
    >>>> and COMBINING TILDE.
    >>> Are you sure these keys were assigned to U+0300 and U+0303? I'd bet not.
    >> Don't bet, I am sure they are, but only as *dead keys*, they don't
    >> produce a
    >> character until a second character is entered which determine the final
    >> character(s) which are output.
    > I'm not sure I can follow. Are you referring to some recent change that
    > modified the effect of those keys? It seems to me that you are describing
    > the usual behavior of "dead keys" (a somewhat misleading, but established
    > term) but do so in terms of combining characters (which is just wrong).

    When I say "they are", this is semantically, with the same meaning as
    characters, even if keys are not characters themselves. But in the time of
    typewriters, the key was unambiguously associated to a character. That
    character was effectively a non-spacing diacritic.

    > Dead keys are an important practical problem. People have difficulties in
    > learning to use them. People may have used computers for many, many years
    > without ever realizing how they can use dead keys to type letters with
    > diacritic marks. They have just wondered why typing "~" or "^" behaves
    > somewhat oddly, in a delayed manner.

    At the time of typewriters, there was no delay. And it was really not
    difficult to learn, and helped reduce the number of keys needed to compose
    text. With more keys on the keyboard, the keyboard would have been in fact
    more difficult to use.

    Don't be fooled by the behavior of computers. If they delay the input, it's
    just because displays were not able to compose multiple characters into a
    single display glyph, so character sets have been created with precomposed
    characters in which diacritics were absent.

    On computers before the introduction of CRT displays, characters could be
    composed, but the diacritics were all spacing ones, so one had to use
    backspace (that's why the old standard for the ISO-646 French character set
    included sequences with spacing diacritic + BC + letter, or the reverse);
    the main origin of this odd behavior, where the non-spacing property of the
    diacritic was lost, comes from the secundary need to enter non French
    characters for American ASCII characters. This was really odd and has been

    If displays did not have this limitation, diacritics would have been entered
    normally and made immediately visible on display, without advancing the
    cursor, and the next input character would have been composed with the
    existing diacritic displayed under the cursor. You should really know that
    some computers were behaving this way, and effectively produced a visible
    glyph on screen immediately, without delay. It's just a shame that PCs have
    abandoned this behavior.

    But if it had not, Unicode would have probably been created by encoding also
    the base characters AFTER the diacritics instead of before them (the
    Teletext and Videotex encodings which are still in use today also encode
    diacritics before the base character... and the French keyboards for the
    associated devices also don't have "dead" keys but compose the diacritic; to
    avoid composition errors however, for composed sequences that the display
    can't handle, it was allowed to delay the input until the base character was
    composed; then the whole sequence for the diacritic and the base character
    was output; if a composed sequence was not supported by the display, the
    whole input was not output, and there was an error indication with a audible
    beep and a fast flashing cursor).

    This archive was generated by hypermail 2.1.5 : Sun Sep 18 2005 - 03:41:27 CDT