From: Robert Baer
X-Mailer: Mozilla 4.75 [en] (Win98; U)
Subject: Re: How does a computer keyboard generate ASCII code or signals?
Date: Thu, 19 Sep 2002 07:33:17 GMT
NNTP-Posting-Date: Thu, 19 Sep 2002 00:33:17 PDT
Organization: EarthLink Inc. -- http://www.EarthLink.net
Monowara Begum wrote:
> Many thanks to Robert Baer and Ian Stirling for very helpful answers. May I
> beg your indulgence to add a bit of clarification how the consumers may
> percieve their needs and problems, outside the English speaking world.
> 1. English does not need any more than 96 characters, but many writing
> systems need as many as 224 characters (leaving 32 for non-printing
> characters), still within the 8-bit limit. China, Japan and Korea require
> thousands of ideographs. The problem for character-rich languages is to have
> an intuitive way of invoking the [remote] character beginning from location
> 121 through 256 in the ASCII-8 set.
> 2. English-based software developers have liberally preempted the Alt+key,
> Ctl+Alt+Key, Alt+Shift+Key and similar combinations for shortcuts to
> function calls, not to characters. There is no standard. These combinations
> are not used by English to invoke characters (since the need is well met by
> using the normal key and the shift+key combination). Non-English languages
> now use thousands of software to generate the [remote] characters. These are
> not portable or compatible in the absence of standards. We do not see much
> web material in character-rich languages for this reason.
> 3. The problem is really so acute that Unicode devised something that
> appears as the worst nightmare to an economist. Instead of using 8 bits to
> identify a character, Unicode needs 16 bits, instantly doubling the storage
> and transmission load, in the hope that 65536 spots would give room to all
> languages. Who will pay for this increased cost? The composite characters
> are usually not provided by Unicode, so that while Hindi has a composite
> character (say by pre-adding n to t), still within the size limit of 224
> characters in 8-bit, Unicode would have you use three 16-bit letters (n, +,
> t) and still not give a composite character. (Some software will have to
> create the composite outside Unicode provisions.) This means that Unicode
> requires 48 bits to store and transmit what should be possible to do with
> just 8 bits. In their infinite wisodm, Unicode creators have assigned more
> than 20 spots for exactly the same character in common alphabets, but no
> place for composites. That is, instead of providing a single code space for
> all languages using a common alphabet, (though with different glyphs of the
> same character), Unicode has wasted space, and asks you to invest in 16 bit
> storage and transmission. Sanskrit-based languages all share the same
> alphabet, and they can simply switch to a different font for their different
> glyphs. The Unicode <> is indeed a problem.
> 4.Most people like me cannot even remember where the k key or y key is and
> must optically scan the keyboard to find it. It is out of question for them
> to press Alt+0221 to generate the charcater stored at the font location
> 0221. How are they going to remember which combinations to use? A sensible
> and intuitive keyboard can impose a physical standard to avoid such costly
> Meanwhile, have lots of fun.
> M Gani
Mr. R. P. Henry eloquently expressed the fact that each key has its
own code, passed to the BIOS (which i indicated in a different way).
No new keyboard is needed, and proper software can interpret these
keys any way one wishes.
I had obtained some English/Amharic software to send on to a pen pal
in Addis Ababa, Ethiopia which worked but was a bit quirky and i think
unwieldy; it required a special DOS driver for the Win3.x application,
as well as a 2-key code for most glyphs (first one for the "root" glyph
and the second one for the vowel modifier - and not at the same time).
And it had to be "enabled" for usage.
It is my opinion that this foolishness is not necessary, and that
*any* combination whether "simultaneously" or sequentially can be
implemented with ZERO regard to control characters, alt characters etc.
"pre-empted" by *any* other program, function, whatever.
What one does is assign a key as an "escape" character and somewhere
"nice" on the screen, display the MODE of operation (e.g.: Standard or
Amharic). And what key is the most natural for that function? the
When in Amharic mode, all control, alt, etc. combos are useable for
the program as one wants and *no* key combo is passed to the operating
system (unless one wants to allow the special combo
go to the OS).
How one takes these key codes (whether sequentially or
"simultaneously") and interprets them for glyphs, as well as assigning
the 255 ASCII values to them is strictly the programmers prerogative,
since this is a special program.
Ascii code zero is not easy to generate, and so i have not counted it.
Creating a new "standard" is not going to be easy, so think of ways
that various high use programs that might be translated for use in the
"new" language: (1) Word processing, (2) Spreadsheet, (3) Database, (4)
Graphics, (5) Picture manipulation.
The more the apps available that can be used in the business world,
the better the chances that the new "standard" would catch on.
Also, it is better to publish and give rights (free, or almost free)
to the underlying standard and methodology, as that allows others to
build on your foundation, thus allowing the new "standard" to grow
faster to a more widespread usage.
Proprietary, closely held "secrets" die fast.
The IBM PC grew mainly due to the disclosures IBM made; there were
makers of add-ons and then clones, creating healthy competition and
rapid spread of the PC.
Notice the Next computer died *very* fast (mainly) because they stuck
their nose in the air and would only sell to educational and
governmental institutions; the superiority of the computer just did not
make it in that stifling atmosphere.
AST, Packard Bell, Corona and others also died fast due to their
proprietary nature; Compaq was on its last legs when HP absorbed them,
and parts of HP also was dying then; only the facts of near
compatibility and quality have carried them so long (in the consumer
Once upon a time, there was a nice program for Win3.x called
FontMonger that allowed one to assign a large number of the key
combinations (not all possible ones, sadly) individually to any supplied
I think it was killed because it was too good.