From: Ed Trager (ed.trager@gmail.com)
Date: Thu Jan 07 2010 - 08:38:53 CST
Hi, Gerrit,
On Wed, Jan 6, 2010 at 11:49 PM, Gerrit Sangel <z0idberg@gmx.de> wrote:
> Concerning this question, I always wonder why it is necessary to add layer
> over layer over layer to these kind of keyboard layouts. Wouldn't it be
> better if latin based keyboard layouts were something similar like Japanese?
>
> Type “alpha” and get α, type “Theta” and get Θ. Type “punctuation”
> (something like the japanese “kigou”) and be able to select all different
> punctuation and stuff. Write Hangeul and get Han’gŭl, type Pin1yin1 and get
> Pīnyīn. Write Kyoto and get Kyōto. You could also add smart quotations
> directly into the input method, not just in the Word processor.
>
Actually, such systems do exist -- but perhaps are not sufficiently well known:
Take a look at Yudit (http://yudit.org). This handy Unicode editor
comes with numerous keyboard layouts of exactly the type that you are
advocating. To the best of my knowledge, all of the keyboard maps in
Yudit make use of just a basic QWERTY keyboard, plus the SHIFT keys.
I believe that the vast majority of Yudit keymaps will work equally
well with AZERTY and similar layouts too.
The keyboard layout maps for Yudit are also so easy to make that
anyone can do it --without the need for special software either, as
the keyboard maps are ASCII files with hexadecimal values for the
Unicode code values that you want. Yudit includes a tool for
compiling the maps into the binary form (or at least this is true if
you compile Yudit from source code, as it is an Open Source program
released under GPL. Binaries for Windows and Mac are also available).
For example, here's a short excerpt from a "Grand Latin" or what I
prefer to call a "PanEuropean" keyboard layout map for Yudit:
...
"a`=0x00E0",
"a'=0x00E1",
"a^=0x00E2",
"a>=0x00E2",
"a~=0x00E3",
"a:=0x00E4",
"a%=0x00E5",
"a/=0x00E6",
"c;=0x00E7",
"e`=0x00E8",
"e'=0x00E9",
"e^=0x00EA",
"e>=0x00EA",
...
As you can see, the keystrokes shown to the left of the equal sign map
to the following set of letters, respectively: àáââãäåæçèéêê. The
fact that "e^" and "e>" both map to "ê" is just a convenience: the
user can type whichever combination is most comfortable. (Having
multiple options for the same output as in the case of the "â" and "ê"
shown here may be advantageous if you have to use a computer with
something like an AZERTY keyboard).
In the excerpt above, note that only n-to-1 mappings are shown.
However we are not limited to this: It is also possible to map n input
keystrokes to a set of m output code values. A phonetically-based
Devanagari keyboard map included with Yudit, inter alia, makes
extensive use of that capability.
Other systems may also exist with some of the features that you
advocate, but to my knowledge Yudit is certainly one of the best.
As a post-script to this, I will note that the original reason for me
asking about Korean input methods has very much to do with the fact
that I am now working on something related to all of this input method
business. While what I am working on is currently "under wraps", you
would be very correct if you guessed that I have been influenced by
Yudit ...
Best Wishes -- Ed Trager
> I think, this system is
> a) more intuitive - everybody knows that α is pronounced/written as alpha
> b) you don't need to remember the position of different characters.
> c) you can still add much more characters than with a keyboard with 10
> layers or even more.
> d) Because the vast majority of the characters proposed for this kind of
> “super layouts” is used extremely seldom during writing one language (I
> think, it is often only for names), it does not slow down the writing
> process if you sometimes have to type e.g. an o and check the list if you
> want ö, ó, ò, ō, ǒ e.g. If you include a dictionary with popular names, you
> don't even need to do that, because Nánjīng would (i think) be the only
> possible thing to choose if you write Nanjing.
>
> If you want to maybe switch to a language where you need these “special”
> characters more often, just write something like
>
> “Currently I am writing English and now i want to write French de<PRESS
> KEY>mit vielen möglichen Umlauten en<PRESS KEY> and now I can write English
> again”
>
> if you do it like this, it could be extremely easy to switch even the
> keyboard layout to another language inside the writing process. Just type
> the language code, press some key (e.g. caps lock) and the layout is
> automatically switched to a language which makes the characters available
> easily there.
>
> Gerrit
>
> Am 05.01.2010 11:39, schrieb Doug Ewell:
>>
>> Karl Pentzlin <karl dash pentzlin at acssoft dot de> wrote:
>>
>>> DE> How do I access this third level using a standard 101-key
>>> keyboard, if
>>> DE> the FDIS leaves the mechanism undefined but suggests a new key?
>>>
>>> The mechanisms are defined in another part of the standard, ISO/IEC
>>> 9995-2 "Alphanumeric Section":
>>>
>>>>> 8.3.2 Level 3 select
>>>>> For keyboards with characters allocated at level 3, at least one
>>>>> key for the function Level 3 select (frequently
>>>>> marked "Alt Gr") shall be provided.
>>>
>>> AltGr, as you surely know, is found on many keyboards where the "Right
>>> Alt" is found on US keyboards. Thus, on US keyboards, the "Right Alt" is the
>>> first choice to employ this function (leaving the "Left Alt" for the pure
>>> "Alt" function).
>>
>> OK, we are dealing with the same "group vs. level" terminology problem
>> that Kent and Michael were talking about. I use AltGr and Shift+AltGr
>> every day, even though the key just says "Alt" on my U.S. English
>> keyboard.
>>
>> What I was trying to say, applied to the FDIS 9995-3 keyboard, was this:
>> Appendix C shows a new "current common secondary Group layout" which
>> includes the following key assignments for key D03 (the "E" key):
>>
>> Level 1 (unshifted): œ U+0153 latin small ligature oe
>> Level 2 (shifted): ΠU+0152 latin capital ligature oe
>> Level 3 (extra): ◌̆ U+0306 combining breve
>>
>> My question was how to reach the so-called "extra" level 3.
>>
>>> The "Group select" is dealt with in 8.3.3. The "dedicated key" is only
>>> one of the possibilities described there.
>>>
>>> In fact, a "Group select" is nothing else than a "dead key", only that
>>> the destination character can be any character (specified by the layout),
>>> rather than being restricted to precomposed character with a specific
>>> diacritical mark.
>>> This "dead key" can be a dedicated new key or any free AltGr combination
>>> on your US keyboard.
>>
>> OK, that makes things a lot more understandable. I can see now how to
>> implement this. I just wish it had been made clear before now.
>>
>>> (It also can be the key combination "Shift+AltGr", to be released before
>>> the next key pressing rather than to be pressed simultaneously; this is
>>> recommended but not prescribed in 9995-2 section 8.3.3.)
>>
>> I already use plain E, Shift+E, AltGr+E, and Shift+AltGr+E. So do most
>> Windows keyboards. So a fifth level -- or if you prefer, a third level
>> within the second group -- needs to be something other than
>> Shift+AltGr+something. If it's conformant to make this, say, AltGr+/
>> followed by E, then we've got a deal.
>>
>> --
>> Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
>> RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
>>
>>
>
>
>
This archive was generated by hypermail 2.1.5 : Thu Jan 07 2010 - 08:43:26 CST