On 02 Jul 2015, at 12:22, I replied:
> However, I believe that WJs being a part of plain text, they should be properly supported on all text handling applications. And they should be on the keyboard.
> The solution I suggest is therefore to have the word joiner (and the sequences containing it) on Ctrl+Alt or Kana, and the zero width no-break space on Shift+Ctrl+Alt or Shift+Kana, so that users working efficently on good software may access the preferred character a bit easier than users who must use the deprecated character because their word processor does not properly support the preferred one.
Unfortunately that doesnʼt work on at least one recent version of Windows. An unambigous bug was due to the presence of 0x2060 in the Ligatures table. This has cost me a whole workday to retrieve, fix, and verify.
The effect of the bug was that Word, Excel, Firefox and Zotero were unstartable.
As a result, the WORD JOINER cannot be implemented on a driver based keyboard layout for general use on Windows. By contrast, the ZWNBSP can.
Consequently we hope that such kind of bugs are being fixed on Windows 10, that is to be released today. If everybody using Windows 7 or 8 is being updated for free, Windows 10 will become the standard and we will be able to build upon.
It needs to be underscored that this kind of keyboard driver related bugs is normally impossible when using Keyman. I don’t see any way for the OS to detect the presence of 0x2060 in a ligatures table in order to block the full execution of the system, when this character is a part of some keyboard layout software that is fully managed and executed by an additional framework like Keyman. Under the actual overall circumstances, and for ease and flexibility of development and use, Keyman appears to me as an indispensable software for thorough and complete Unicode implementations.
Best regards,
Marcel Schneider
Received on Wed Jul 29 2015 - 03:11:24 CDT
This archive was generated by hypermail 2.2.0 : Wed Jul 29 2015 - 03:11:24 CDT