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: <[EMAIL PROTECTED]>
