Dead and Compose keys (was: Re: Romanized Singhala got great reception in Sri Lanka)

Marc Durdin marc at
Mon Mar 17 15:33:56 CDT 2014

I disagree.  Making a basic keyboard layout is not hard, just like making a font without OpenType support is not that hard.   Making a keyboard layout that doesn’t force users to learn the nuances of the encoding of a script is more of a challenge, and making a high quality keyboard layout that is consistent, easy to use, and efficient is anything but straightforward.  Most keyboard layouts fail at one of these.

The story for touch device input is even more challenging.  Not being constrained to a physical set of keys increases your flexibility.  The big challenge is usually the size of the display on mobile-sized devices.

Regarding keyboard design:

·         Scan make/break codes are not really relevant to Windows keyboards – Windows has an abstraction layer of ‘virtual key’ codes, for better or worse.

·         Selecting US-English for a non-English keyboard means that all language tools will break with your text.  Spell checking, grammar checking, automatic keyboard selection, autocorrect, font selection and more.  That’s a big price to pay.  Conversely, selecting Singhala for your Romanised non-Unicode encoding will break spell checking, grammar checking, automatic keyboard selection, autocorrect, font selection and more.


From: Unicode [mailto:unicode-bounces at] On Behalf Of Naena Guru
Sent: Tuesday, 18 March 2014 3:08 AM
To: Doug Ewell
Cc: UnicoDe List
Subject: Re: Dead and Compose keys (was: Re: Romanized Singhala got great reception in Sri Lanka)

Making a keyboard is not hard. You can either edit an existing one or make one from scratch. I made the latest Romanized Singhala one from scratch. The earlier one was an edit of US-International.

When you type a key on the physical keyboard, you generate what is called a scan-code of that key so that the keyboard driver knows which key was pressed. (During DOS days, we used to catch them to make menus.) Now, you assign one or a sequence of Unicode characters you want to generate for the keypress.

Use Microsft's keyboard layout creator for all versions of Windows from XP:

Select the language carefully. I selected US-English for RS. That way, I can switch between the two keyboards quickly with Ctrl+Shift. You can change all these in the Control Panel.

Here is the keymap I made for RS in Linux:
Just scroll down for the English part. (The lines starting with double slashes are comments and have no effect on the program)

The Macintosh key layout is easy too.

The story with iOS and Android are different but not hard either.

On Sun, Mar 16, 2014 at 6:47 PM, Doug Ewell <doug at<mailto:doug at>> wrote:
Jean-François Colson <jf at colson dot eu> wrote:
The idea here was “that characters not on an ordinary QWERTY keyboard
could be entered _using_an_ordinary_QWERTY_keyboard._” Are there any
dead keys on an _ordinary_ (i.e. not one using an international(ized)
driver) QWERTY keyboard?

Not on the standard vanilla U.S. keyboard. It has to be provided by the OS, via a driver, just as Compose key support has to be provided by the OS.

The standard vanilla U.S. keyboard also doesn't provide the accented letters and other non-ASCII letters like ð that Naena Guru uses for his font hack.
If a character is available by a dead key, isn’t it on the keyboard ?

It depends on what you mean by "on the keyboard." Thanks to John Cowan's delightful Moby Latin keyboard layout, I can type AltGr+\ followed by 7 to get the fraction ⅐ (one-seventh). That character is not "on the keyboard" in any sense other than what the driver provides.

Doug Ewell | Thornton, CO, USA | @DougEwell ­
Unicode mailing list
Unicode at<mailto:Unicode at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unicode mailing list