That reminds me. The key, I think, about this whole keyboard switching mess,
is to adopt a stateful mode for entering the hex value (to prevent having to
switch keyboards: it's just too messy).
Assuming that your keyboard HAS an "ASCII" mapping, if you are holding down
Ctrl-Shift (or whatever the magic key is) then your keyboard keys 0-9 and
A-F respond AS IF the keyboard were in a Latin entry mode--provided you
enter exactly four values in the range 0-F. This removes the objection about
having six steps to type one character: it works just as smoothly as the
existing alternate key entry.
From: Peter_Constable@sil.org [mailto:Peter_Constable@sil.org]
Sent: mardi 8 juin 1999 17:13
To: Unicode List
Subject: Re: Hexadecimal in many scripts (ISO 14755)
I get the feeling this thread is going around in circles, touching on but
hitting the key points. I sent the message below yesterday, but I haven't
any responses to it, and wonder if it landed in a vacuum somewhere. I
provided some needed clarification to this discussion, though.
We've gotten onto telephone keypads originally because of the claim that
have made 0-9 universal, but there has been some digression onto using a
telephone/ATM keypad for hex entry. I don't think that ever was the point.
John Cowan reminded us:
>Anyhow, the point is to type Unicode characters on computer keyboards, not
People seem to have given up on the suggestion that be entered in terms of
decimal representations (no objections on my part). So the issue then is
to 'localise' hex codes. The issues here are:
- Does everyone in the world have a keyboard that has a Latin mode?
- Is switching to a Latin mode too much of a hassle?
- Even if switching to a Latin mode isn't too inconvenient, should a
develop that accommodates such cultural differences anyway?
- Is the latter idea feasible?
Sandra Martin O'Donnell has also provided a reminder which touches on the
of these issues:
>Throughout this voluminous thread, I've seen several people ask whether
has a keyboard that does NOT include the Latin letters A-Z and a-z, or the
digits 0-9. So far I haven't seen an answer. It seems that information is
before worrying much about determining the first six "letters" in every
On the second issue, in my reckoning, we're talking about a need that should
only occur *infrequently*. (Read my message below to see why I assume this.)
can talk about the inconvenience of switching keyboard modes in order to key
Latin hex sequence, but if people are only doing that only infrequently, I
think that's a problem.
The third issue is open to lots of subjective opinion, but I've given some
reasons (see below) why I think this isn't necessary.
The fourth issue is something I've questioned in previous messages, and I
repeat those concerns here.
Summarising the way it all seems to me, we haven't seen evidence that Latin
*can't* be used by any group of users; I've presented arguments why using
hex is not too inconvenient; I've presented arguments that using Latin hex
not actually necessary; and I've raised several questions about the
of specifying a bunch of localised versions of hex digits. This is not to
that the standards folks can't choose to pursue it anyway, but I would
them to decide where they stand on these issues before they get too far.
---------------------- Forwarded by Peter Constable/IntlAdmin/WCT on
04:51 PM ---------------------------
Subject: Re: Hexadecimal in many scripts (ISO 14755)
John Cowan wrote
>I chose U+2323 for a reason: it is very unlikely to appear on any keyboard,
even fairly unlikely to appear in any list of "frequently used non-keyboard
characters" that a particular
IME may provide. It's just a freak, a highly specialized character that you
want when you want it and not otherwise.
Let's distinguish among the following:
1. writing systems that a person uses regularly
2. characters that an individual wants to use on an occasional but somewhat
3. a character that an individual wants to use in an isolated instance
Situation 1 is typically, and generally should, be provided for by IMs made
available to the user, usually with the OS.
Situation 2 should best be met by user-definable IMs. John is right that
will be characters that are unlikely to appear as part of any packaged IM
that an individual may want to use regularly. These are generally specific
the individual, and the preferred way of keying them is also specific to the
individual since there is (by definition) no standard keying. The number of
users that want to use unusual characters is not a majority, and this group
could probably be motivated to come up with their own IM definition if they
given tools that made it easy enough to implement.
Situation 3 should be met by exactly the kind of mechanism being suggested
ISO 14755. For this reason, I think the idea should be pursued. The open
Q: Should codes be entered according to decimal or hexadecimal
As has already been indicated, people are *very* unlikely to find decimal
representations in a table, unless they create the table themselves and do
conversions. These should be hex.
Q: Should users be able to enter using transliterations of hex codes (what
referred to in earlier messages as "localising" hex)?
I think there are some significant concerns about such a plan, and I've
mentioned them previously. In addition, I think it's probably highly likely
anyone who wants to enter an uncommon character into their document -
who has an awareness of the character, who has a wish to use it in a
and who has access to the standard - is the type of person who has a
that supports a Latin layout and/or is familiar with some Latin layout.
kind of person surely works with Latin - at least, they need to be able to
the standard and/or type in the URL to the charts on the Unicode web site,
they probably work with a lot of other Latin URLs as well.) My guess is that
this person would probably prefer to enter hex codes in terms of the actual
Latin characters, even if they had a way to enter the code in terms of a
transliteration of hex.
Between the problems involved in transliterating hex into other scripts and
question about whether it is really needed or would be used, I think this
of the plan needs to be thought through much more carefully before it is
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:46 EDT