On Wen 29 Jul 2015, at 20:57, Richard Wordingham wrote: > On Wed, 29 Jul 2015 10:10:02 +0200 (CEST) > Marcel Schneider wrote: > > > 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. > > Your lament is a bit vague - I'm not sure what U+2060 is doing in a > 'ligature table'. I can say that a Windows keyboard mapping that > maps AltGr-M to WJ which was created using MSKLC on Windows 7 in April > 2011 still works.
I'm really pleased to learn about every initiative to implement Unicode in input practice, and I take notice that an MSKLC layout with U+2060 does not make Windows block heavy applications. Indeed I wasn't very clear, as in the deadlist I can keep 0x2060 without any problem (Compose, Space, G). This is just not very speedful. The so-called ligatures, by contrast, must not be constructed with 0x2060. This however was the case of three items: - A justifying no-break space emulation 0x2060 0x0020 0x2060, for use in word processors where the NBSP is not justifying, unlike as in desktop publishing and high-end editing software as Philippe Verdy referred to, where U+00A0 is justifying. It not being in word processing is consistent with the need of using U+00A0 along with punctuations in French, and the lack of U+202F in many fonts. - A colon with such a justifying no-break space, for use in documents that imitate the usage of at least a part, if not mainstream, old-fashioned typography: 0x2060 0x0020 0x2060 0x003a. - A punctuation apostrophe emulation 0x2060 0x0027 0x2060, mapped to Kana + I. I'm about to test on another Windows Edition. I wonder if there is a real issue or not, as you are suggesting. Nevertheless I believe that no such bugs must occur in whatever version and edition of Windows. Thank you for your feedback. Best regards, Marcel
