Re: Hexadecimal in many scripts (ISO 14755)

From: Mark Davis (mark@macchiato.com)
Date: Sun Jun 06 1999 - 03:06:59 EDT


On a previous system, we always had three methods of entry for Unicode
characters, aside from switching keyboards. You could pick any one of
these, or mix or match.

1. Hex input. If you typed <convertKey> while your caret was right after
a hex string, it converted that hex string to a Unicode character
inline. E.g., you'd type "2323<convertKey>" to get a SMILE character.
That has a few advantages over the "<dead key>2323" approach, since you
could actually see the hex digits before you converted instead of typing
blind.

2. Name input. If you typed <special key> while your caret was right
after a non-hex string, it interpreted the preceding characters as a
Unicode name (or approximation thereto). That meant if you typed
"SMILE<convertKey>", it would convert that to a U+2323. This is even
handier than the hex method, since you never had to remember the hex
code. This didn't work really well with long names such as "LATIN
CAPITAL LETTER N WITH CARON<special key>", so...

3. On-the-fly composition. If you typed combining marks, it would try to
(canonically) compose them with the previous characters if possible. So
to type U+0147 LATIN CAPITAL LETTER N WITH CARON, you would simply type
"NCARON<convertKey>". The CARON<convert> would produce a CARON
character, which would then compose with the preceding character ("N").

4. Another method is to have a pop-up insert-symbol box, something like
the Windows Character Map.

I am skimming over a few of the nuances, but all of these combine to
make it pretty easy to enter Unicode characters. And all of these are
very easy to either do directly (e.g. Transliterators), or make into
simple input methods on any modern OS.

[As input methods, you can provide the user more power. If you just type
CROP<convertKey> you will get (say) U+230C BOTTOM RIGHT CROP, but you
can bring up a menu of related items:
 U+230D BOTTOM LEFT CROP
 U+230E TOP RIGHT CROP
 U+230F TOP LEFT CROP
with samples of each character.]

I'm afraid that the ISO keyboard standard method just doesn't hold up to
real, live usage.

Mark

Addison Phillips wrote:
>
> Ah... but that makes U+2323 a more subtle example than it looks.
>
> Do you know of ANY keyboard layout that has a key with SMILE on it? How about the THORN character? How about the currency symbol U+00A4? I mean, my first response to this problem was "why type the expletive key value? give me the ability to switch keyboards!"... but what if I don't have an Ethopic keyboard installed? Or a Tamil keyboard? Or an Urdu keyboard? Or a "math symbols" keyboard?
>
> Since there are many symbols and characters encoded within Unicode that never appear on a keyboard anyway, what is needed is a rapidly accessible "input method" for the various regions of Unicode SEPARATE from locale based keyboards... possibly with a hex/character code... without searching through the Start or Apple menus and then mousing around in the utility/changing font/getting frustrated.
>
> Addison
>
> -----Original Message-----
> From: John Jenkins [mailto:jenkins@apple.com]
> Sent: Saturday, June 05, 1999 7:39 PM
> To: Unicode List
> Subject: Re: Hexadecimal in many scripts (ISO 14755)
>
> Peter C. observes:
>
> >
> >
> >>But consider the use cases:
> >
> > <typing along happily in Arabic>
> > <need a U+2323>
> > <switch to Latin keyboard>
> > <enable magic Unicode mode>
> > <type "2 3 2 3">
> > <disable magic Unicode mode>
> > <switch to Arabic keyboard>
> > <try to recover train of thought>
> >
> > And just how many people are likely to remember what U+2323 is?
> >
>
> Well, I sure as heck don't. And I'm too lazy it dig out my copy of the
> standard or look it up.
>
> Anything which requires people to remember an arcane four-digit code to
> input *any* character is ridiculous. The Mac has long had the ability to
> support multiple and -- in theory -- user-definable keyboards. I believe
> Windows has similar capacity. The correct approach is to provide more
> well-designed keyboards and input methods, not require users to remember
> silly codes.
>
> And don't you mean U+263A WHITE SMILING FACE instead of U+2323 SMILE?
>
> =====
> John H. Jenkins
> jenkins@apple.com
> tseng@blueneptune.com
> http://www.blueneptune.com/~tseng



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:46 EDT