On Sat, 8 Aug 2015 17:05:26 +1000 Andrew Cunningham <[email protected]> wrote:
> On Saturday, 8 August 2015, Richard Wordingham< > [email protected]> wrote: > > Michael did do a series of blog posts on building TSF based input > methods years ago. Something I tinkered with off and on. Does this mean that one can put it all together from his reconstituted blog? I don't know how much was salvaged. Michael has publicly complimented Marc Durdin on being able to find his way through the published Microsoft documentation to make TSF work for him once Microsoft had fixed the bugs he had identified. > > What we're waiting for is a guide we can follow, or some code we can > > ape. Such should be, or should have been, available in a > > Tavultesoft Keyman rip-off. > I don't believe in rip-offs esp when there a free versions and the > enhanced version doesn't cost much. > But that said there is KMFL on linux which handles a subset of the > keyman definition files. And Keith Striebly, before he died, did a > port of the kmfl lib to windows. But I doubt anyone is maintaining it. I was thinking that, at the very least, that his package was working code that one could study. While the porting was morally questionable, I'm not aware of any issues with the code obtaining the keyboard input, discovering the current text context or delivering the text changes once derived. > But reality is that the use cases discussed in this and related > threads do not need fairly complex or sophisticated layouts. So kmfl > and derivates should be fine respite how limited I consider them. Do very recent systems allow ibus input for one's password when logging in? On Ubuntu 12.04 I only see the keyboards defined via X, which only guarantee codepoint by codepoint input. Application compatibility with KMfL has increased, but sophisticated layouts are liable to break. I have seen regressions. For example, when using an XSAMPA-inspired NFC-generating IPA keyboard layout that changes the characters sent (it uses backslash cycles through sets of characters), rescinding characters has failed and the application has stored both sets of characters. Admittedly, last time the problem came and went the set up was a bit complex - I was using Ubuntu as the X-client, Windows 7 as the X-server, and using the X-client to provide the IME. I should be thankful it ever works. I suspect the problem was in the application. Last month Google document wasn't working with the same IPA keyboard on Firefox on Ubuntu, though I don't know if it has ever worked - I don't have much occasion to type IPA in Google document. > I don't see much point bleating about the limitations of the win32 > keyboard model. Just use amlternative input framework .. wether it is > TSF table based input, keyman , kmfl port to windows or any of a > large slather of input frameworks that are available out there. The interface structure used by DLL for win32 supports arbitrary (well, up to 60 at least) ligature lengths. Therefore it isn't obvious that 4 should be the maximum length, especially as I have seen code around that implies that the maximum length is extended by 3 in 'FE' versions. 4 *characters* isn't an unreasonable limit. However, we are now getting minor scripts in modern use that are encoded in the SMP, and for them the limit drops to 2 characters. They also lose the deadkey capability from MSKLC. Richard.
