Re: Windows 10 release (is still: Re: WORD JOINER vs ZWNBSP)

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
Received on Thu Jul 30 2015 - 10:57:40 CDT