Keyman Developer for free? (was: Re: Input methods at the age of Unicode)
marc at keyman.com
Sun Jul 19 01:16:44 CDT 2015
From: Marcel Schneider [mailto:charupdate at orange.fr]
Sent: Sunday, 19 July 2015 12:47 AM
Subject: Re: Keyman Developer for free? (was: Re: Input methods at the age of Unicode)
1. Does Keyman allow to place a Kana toggle? This feature available at least on Windows is useful for locales like Czech and French that use so many precomposed characters that the upper row is filled up with them to some extent. When Kana toggle is on, digits will be in Base (Kana) there. The preferred place for this toggle is E00 (ISO 9995-1).
Yes. See http://help.keyman.com/developer/9.0/docs/guide/guide_lang_options.php for one way to implement this. Note: URLs I refer to are from the beta and so are subject to change shortly, but the details will still be found on http://help.keyman.com/developer/ after the site is updated.
2. Does Keyman support extended Compose trees? An extended Compose tree allows to use ‘Compose’ as a part of Compose sequences. In fact, ‘Compose’ can convert to a dead key *any* key on the keyboard, including the Compose key itself (regardless of the fact that it is already a dead key). This allows to make sequences more user-friendly. For example, the háček dead key may be ‘Compose, v’, while ʒ may be ‘Compose, z, h’. With an extended Compose tree, users may input ǯ typing ‘Compose, v, Compose, z, h’. Otherwise it must be typed ‘Compose, z, v, h’, because ‘Compose, v, z’ is already ž. With ‘Compose’ acted by the right thumb, the first option may be appealing. One keystroke more, but one memorization less. However, I know that the second order matches the principle of double combining marks as stated in TUS §7.9. It would be interesting to know the user preferences about these Compose sequences, as implementing them both is needless if one is disliked.
Yes, although not in the way you understand Compose trees. Keyman uses a more powerful context-based mechanism. See http://help.keyman.com/developer/9.0/docs/tutorial/tutorial_keyboard.php for a starter on how the Keyman keyboard language works.
3. Does Keyman propose a spreadsheet-like UI? The use of spreadsheets for keyboard layout programming helps streamlining the development process.
Not really. Table-based setups tend to constrain the design of keyboards. Keyman uses a rule based model – see the tutorial link above for more detail.
4. Are Keyman layouts programmable in C? Windows drivers (at least, as I know little about other OSes) are. The syntax of C and C++ allows developers to use spreadsheets, from where allocation tables, deadtrans lists, and ligatures tables (that is, in keyboard driver language, Unicode character [WCHAR] sequences tables) are copied and pasted into the source.
5. Does Keyman allow to get such ligatures (sequences) accessed by dead keys? On Windows I don't see this possibility, and I never knew how to program it. But Unicode recommends that implémentations provide this facility.
Yes, although dead keys are typically not the best choice for the majority of the world’s languages. See the tutorial again, e.g. step 8.
The help site for Keyman has a stack of documentation and examples and is the best place to start, but if you don’t find answers to your queries there, I am happy to answer additional questions about the specifics of Keyman off-list, or you can simply download and try the development tools yourself from http://tavultesoft.com/beta/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Unicode