From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Thu Sep 18 2008 - 18:01:48 CDT
On 9/18/2008 3:30 PM, Karl Pentzlin wrote:
> Am Donnerstag, 18. September 2008 um 18:08 schrieb Asmus Freytag:
>
>>> 2008/9/17 Karl Pentzlin <karl-pentzlin@acssoft.de>:
>>>
>>>> Elementary mathematical symbols:
>>>> U+2264 LESS-THAN OR EQUAL TO - no own key needed, enter as:
>>>> diacritical mark "combining macron below" + "less-than sign"
>>>> U+2265 GREATER-THAN OR EQUAL TO - no own key needed, enter as:
>>>> diacritical mark "combining macron below" + "greater-than sign"
>>>>
>
> AF> ... What's needed is another layer of software that is akin to a
> AF> (much simplified version of an) Asian Input Method Editor. Such an IME
> AF> will take multiple keystrokes and compose them into the correct symbol.
>
> This is outside the means provided by ISO/IEC 9995-3, which only uses
> diacritical marks to "combine graphical symbols".
>
Keyboards do have certain limitations and that is only proper. While
keyboards modeled more or less on the typewriter model are too
restrictive, as all of us in this discussion agree, even the more
generalized, multi-level keyboards are not as flexible as generalized
input methods.
The latter are able to use a wider array of key-stroke sequences, which
may even be mnemonic, to access a nearly infinite number of characters
(certainly the Han input methods can access tens of thousands of
characters). For symbols, the repertoire is more limited, but there are
well over a thousand, if not double that number.
An input method that is modeled after the Asian IMEs and which would use
the existing support in properly internationalized operating systems and
applications would allow the user to map mnemonic sequences like \int
for the integral sign, for example, or allow the user to type \int
followed by a special key that brings up a list of all variations of
integrals for quick selection.
For some key seqences, if a user "always" makes the same selection from
such a pick list, the IME can automatically re-order the choices, or
even make the most common one the default. Such adaptive behavior is
only possible because an IME has a user interface that lets the operator
interact with the software while using it. Keyboard drivers normally do
*not* provide such UI, and applications expect final form input from them.
The key advantages of using such a more flexible system are the
combination of mnemonics (potentially also customizable) with adaptive
behavior, and much larger repertoire. Because the repertoire that an IME
can handle is so much larger, the support of characters can be made more
systematic and avoids the use of "tricks" - which look cute on paper,
but prove difficult to master and retain in practice.
In order to properly design a keyboard, one needs to be aware of the
spectrum of input methodologies, so that it's possible to relegate
problems that don't fit the methodology of keyboard input to another
layer of software - even if that layer still needs development and is
finally developed in another context.
> A new ISO/IEC 9995-9 will probably more flexible.
> For ISO/IEC 9995-3, there only the 47 unused places in Level 3 of the
> common secondary group can be filled, two of them have already to be used
> for the disintegration of the "or"s for two current key allocations.
> Raising the number of characters which can be added beyond that
> resulting number of 45 obviously requires some tricks, like the
> "arcane" way listed for U+2264/2265.
> The question is: should such characters included by such "tricks" now,
> or not at all (i.e. be left for a later ISO/IEC 9995-9 which, whatever
> its final shape will be, will allow multiple groups)?
>
I think my comments above answer these questions.
A./
> - Karl Pentzlin
>
>
>
>
>
This archive was generated by hypermail 2.1.5 : Thu Sep 18 2008 - 18:03:41 CDT