Re: Hexadecimal in many scripts (ISO 14755)

From: Kevin Bracey (
Date: Wed Jun 09 1999 - 05:13:40 EDT

In message <>
          Markus Kuhn <> wrote:

> John Cowan wrote on 1999-06-07 16:10 UTC:
> > Addison Phillips wrote:
> > > The decimal value is probably better than hex for human entry anyway:
> >
> > However, readily available tables and books universally use the
> > hex values; indeed, a hex mode was added to XML/SGML for this
> > very reason.
> Another reason in favour of hex entry as opposed to decimal is that
> Unicode was essentially laid out on a 16x8x512 matrix, and the
> hexadecimal notation preserves much of this layout. I recognize
> mathematical characters as having the form U+22xx and subscript digits
> as having the form U+208y (where y is the digit). All this and more is
> lost completely in the decimal notation.
> The only advantage of decimal entry that I could think of is that it
> allows use of the numeric keypad.
> However, a clever implementor could simplify hex entry on numeric
> keypads by supporting the use of the keys
> NumLock, / , *, -,
> +,
> Enter
> as hex digits A-F (and perhaps the . as an alternative to SPACE to
> separate characters). All this of course only when Ctrl-Shift is
> pressed.

Oddly enough, I implemented nearly exactly this a few months ago.
Our keyboard drivers (on RISC OS) have always had the ability to enter a
character from the current 8-bit alphabet using Alt and the keypad (eg
Alt-160 for Latin-1 hard space).

When we added Unicode for Japanese support, the keyboard drivers were all
changed to be Unicode based, and capable of adapting themselves to the
current system alphabet. When the alphabet was UTF-8, the Alt-based
keypad scheme now specified UCS codes, eg Alt-8995 for SMILE. It was clear
this wasn't terribly useful, so I added hex entry with a leading 0 -
this Alt-02323 for smile.

For A-F, you can use either /,*,-,+,.,Enter on the keypad (denoted as
physical positions, independent of labelling), or A-F on the main
keyboard section (denoted as logical positions, so changing on French or
Dvorak layouts).

I suppose the ordering Markus gave may be more logical, but using Num Lock
would have made it somewhat trickier in our implementation.

Kevin Bracey, Senior Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 725228
645 Newmarket Road                            Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW:

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