On 02/23/2002 08:58:28 PM yaapraaf wrote:
>Now I have one more question, related with the next:
> # Subject: Re: How to create Unicode input methods for MacOS? (long)
> # Our 'uchr' resources are created using an assembler. It's the
> # only tool we are aware of that can fill in the offsets the 'uchr'
> # data structure contains. We don't have a custom 'uchr' editing
> # tool at this point (we would love to have one...).
>
>If a such a comparison could be made, does the Keyman wizard
>represent the kind of 'intelligence' of the assembler, or is there
>a fundamental difference between Windows and Mac systems that
>makes keyboard editing on Windows less difficult than it is for the
>Mac in the case of 'uchr'? What's the difference?
I don't know these things in detail; when I need to know the details I go
to my co-worker Jonathan Kew. I have some ideas, though.
As I understand it, there are some significant differences. First, my
understanding is that the Mac uchr resources (and their predecessor, kchr
resources) are tables compiled in a binary format that map from scan codes
to characters, usually in a 1:1 manner, though I know kchr could support
dead keys -- i.e. a one-level subtable, so that if a key designated to be
a deadkey was pressed, then the following keystroke used a different set
of lookups. If I recall, kchr resources were part of a "script" bundle,
meaning that each kchr resource had a script code, and there could be at
most one kchr resource per script code. I seem to recall that there were
32 possible script codes, but I'd really need to check the docs to make
sure. (You can find this stuff on the Apple site if you know where to
dig.) I don't know what happens in these regards with uchr resources.
My understanding of these kinds of low-level details is also imperfect,
but a little better than for the Mac. (When I really need to know details
in this area that I'm rusty on, I ask Marc Durdin, the author of Keyman.)
From what I understand, Windows is somewhat different, and adding Keyman
into the mix makes even more different. Windows uses individual files ---
.kbd on Win9x/Me and .dll on NT/2K/XP -- that contain mapping tables to
map scan codes into virtual characters and character codes. There can be
any number of these on a system, but they have to be associated with a
LANGID to use them. Win32 allows lots LANGIDs -- way more than the number
of script codes allowed in QuickDraw. Win32 also allows multiple kdbs/dlls
to be associate with a given LANGID, except that there's something in
Win9x/Me that keeps this from working (I don't know if it's just a UI
problem or something at a lower level). I don't know exactly what kinds of
mappings can be created in a kbd/dll, but it wouldn't surprise me to learn
that it's pretty much comparable to what could be done in a KCHR resource.
Now, Keyman is really an entirely different mechanism. It doesn't create a
distinct kbd/dll, but makes use of one on the system. It will intercept
what is generated by the system, and use its own mechanisms to map to
character codes. And its mechanisms are *far* richer than 1:1 mappings or
1:1 mappings plus deadkeys. This is so because it was first created for
use with Win3.x to create presentation form-encoded data involving scripts
of SE Asia. In other words, it needed to handle some of the kinds of
transformations that are handled today by Uniscribe and OpenType.
You can think of Keyman's wizard as similar to an assembler, except that
what it generates is not processor assembly code but rather rules in the
Keyman keyboard description language. For instance, if I use the Keyman
wizard and drag the shape for a Devanagari KA (U+0915) onto the "K" key in
the screen representation of a keyboard, then it will generate the rule
+ "k" > U+0915
in the KMN text file that constitutes the programming code for the input
method being created. After you have used the wizard, you can revise the
KMN program in whatever way you want, just as if you hadn't used the
wizard but were writing the behaviour by hand -- though you wouldn't need
to do this if you're input method only requires simple, context-free
keystroke-to-character mappings.
>It may be clear I don't know an assembler from a wizard, but I'm
>just amazed about the 'problem' at Apple and the (seemingly)
>simple solution for Windows in this regard.
Several years ago, Jonathan Kew created the SILKey program, which is
basically Keyman for the Mac. (There was a misunderstanding about some
details in the Keyman documentation that resulted in some slight
differences between Keyman's description language and that used by SILKey,
but eventually both programs had been revved so that a single description
could be written to be used on both platforms.) SILKey is available from
the SIL web site. But, it has *not* been updated to support Unicode. There
are some issues that would be involved in doing so, and since there aren't
too many Unicode apps for the Mac (and even fewer that actually handle
true Unicode character input rather than KCHR characters that get mapped
through a codepage), Jonathan hasn't seen much reason to do anything about
updating SILKey.
These have been imperfect answers to your questions. I'm suspect John
Jenkins will correct errors I've made regarding details on the Mac. I hope
it has provide at least some of what you were looking for, though.
- Peter
---------------------------------------------------------------------------
Peter Constable
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <peter_constable@sil.org>
This archive was generated by hypermail 2.1.2 : Sun Feb 24 2002 - 22:08:34 EST