From: Addison Phillips [wM] (aphillips@webmethods.com)
Date: Thu Jun 24 2004 - 11:28:19 CDT
Philippe wrote:
<quote>
In Windows standard keyboard drivers, there's no integrated support to enter Unicode codepoints transparently in all applications.
I wonder if there exists a keyboard driver that would support ALT+NumPadPlus followed by 1 to 4 hex digits to enter at least UTF-16 code points (possibly extended to enter 5 or 6 hex digits for easy access to supplementary planes, by splitting internally the supplementary code point into surrogates when feeding applications which will only treat surrogates).
</quote>
The "Chinese (Taiwan) - Chinese Traditional Unicode" keyboard allows you to type UTF-16 hex sequences into ANY Windows application transparently. It's available on Windows 2000 and later. Supplemental characters have to be entered as surrogate pairs, of course. It's easy to install from the Regional Options control panel. You can find instructions in my little document "Learn to Type Japanese and Other Languages" here:
http://www.inter-locale.com/whitepaper/LearnToType.pdf (Acrobat PDF format)
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
-----Original Message-----
From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]On Behalf Of Philippe VERDY
Sent: 2004年6月24日 7:36
To: Joe Speroni; unicode@unicode.org
Subject: Re: Latin Characters
"Joe Speroni" wrote:
> I was reminded that ALT+UNICODE (decimal) inputs characters into Windows (...)
Wrong statement here: ALT+decimal is supported in keyboard drivers but is limited to enter ONLY decimal values between 1 and 255. This value can be entered and will be interpreted in two ways:
* The decimal code specified is not the Unicode code point, but the OEM charset supported by your selected keyboard driver (typically codepage 437 in US, 850 in Western Europe). This is provided for compatibility with Console apps emulating DOS that use the currently selected DOS codepage (see the command CHCP which allows setting the codepage used in the Console; other GUI Windows apps use the currently selected OEM codepage).
* If you prefix the decimal code by entering a zero digit key, the decimal value is interpreted by your keyboard driver as the local "ANSI" codepage of your OS (the codepage cannot be changed at run-time like the OEM codepage, and is fixed in your local Windows installation). This code is then NOT Unicode (most often Windows 1252). The keyboard driver interprets the decimal value in the Windows ANSI codepage and converts it to Unicode. This makes a difference for all "ANSI" codes entered with ALT+0128 to ALT+0160 (which get mapped to Unicode code points above 255... according to the definition of the Windows ANSI codepage), and if your ANSI codepage is not Windows 1252 (Western European localizations of Windows) with ALT+0161 to ALT+0255 (which will not be converted equally to Unicode codepoints by your Windows keyboard driver's keymap).
>and discovered UNICODE (hex) +ALT-X inputs into Word.
Not a Windows standard, this is just an enhanced keybooard function which treats ALT+X specially in Word. Windows itself does not have this feature.
In Windows standard keyboard drivers, there's no integrated support to enter Unicode codepoints transparently in all applications.
I wonder if there exists a keyboard driver that would support ALT+NumPadPlus followed by 1 to 4 hex digits to enter at least UTF-16 code points (possibly extended to enter 5 or 6 hex digits for easy access to supplementary planes, by splitting internally the supplementary code point into surrogates when feeding applications which will only treat surrogates).
This can be developped quite easily as a separate keyboard driver (easily changeable by users in Windows XP which supports multiple language/keymap combinations). But each application has its own use of keyboards, and generally, Windows only provides ALT+decimal and ALT+0+decimal only for compatibility with legacy DOS and Windows 3.x applications, leaving all extra combinations out of the "standard" key mappings (each application may have its own existing keyboard shortcuts which may stop working if this was done by default in keyboard drivers.)
Instead of forcing new key combinations for easier keyboards, it seems that Microsoft has promoted the definition and use of supplementary keys on keyboards to allow system shortcuts (for example the newer Windows and Menu and Sleep/WakeUp keys, or Internet navigation keys, Media Player controls...) without impacting the existing key mappings for language/plain text use.
It's noticable that you'll find some other keys on all notebooks that don't exist on desktop keyboards, notably additional key modifiers (a "Fn" key for example, or a key to enable/disable the numeric pad emulation mode). Applications may detect these keystrokes but generally leave them interpreted and mapped to characters or system functions by calling the default Windows message translation API which maps the keystroke into system functions or character input, according to the current application profile and user preferences or system capabilities...
This archive was generated by hypermail 2.1.5 : Thu Jun 24 2004 - 11:32:45 CDT