Re: Windows keyboard restrictions

On Sat, 8 Aug 2015 17:05:26 +1000
Andrew Cunningham <lang.support_at_gmail.com> wrote:

> On Saturday, 8 August 2015, Richard Wordingham<
> richard.wordingham_at_ntlworld.com> 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.
Received on Sat Aug 08 2015 - 05:06:30 CDT