Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 23:30:59 +0000, David Starner via Unicode wrote:
> 
> On Tue, Jan 30, 2018 at 2:23 AM Alastair Houghton via Unicode  wrote:
>
> > This pattern exists across the board at the two companies; the Windows API hasn’t changed all that much
> > since Windows NT 4/95, whereas Apple has basically thrown away all the work it did up to Mac OS 9 and is
> > a lot more aggressive about deprecating and removing functionality even in Mac OS X/macOS than Microsoft
> > ever was.
>
> I'm not really clear on all the Windows details, as a long time Linux programmer, but Mac OS X (2001) was
> 16 years ago and Windows 95 (1995) is 22, so not much difference even taking your numbers. The .NET framework
> debuted in 2002, and the Universal Windows Platform debuted with Windows 8 in 2012, so Microsoft has made some
> pretty large changes since NT 4. They do seem to more focused on keeping backwards compatibility layers, but it's
> not that they've been not "prepared to make radical changes". 

I donʼt think that Alastairʼs point was about Microsoft not being innovative.
They simply allow old software to be used on new machines and Windows 
versions, something that Apple reportedly does not on macOS.

However, as of Unicode support by keyboard layouts, the current advice
is that adding new functionalities to Windows 10 would keep them out of 
reach for users of older versions of Windows, and new keyboard layouts 
relying on them would be truncated for a still huge part of the users. That is 
surely part of the “significant, perhaps insurmountable headwinds” faced by 
“making significant changes to user32.dll”, Andrew Glass warned in 2015:

http://www.unicode.org/mail-arch/unicode-ml/y2015-m08/0042.html

Perhaps there could be a way to update older frameworks via Windows Update, 
making an end with “limitation[s] of the Windows USER keyboard architecture” 
that Michael Kaplan pointed in response to Karl Pentzlin, January 2010:

http://www.unicode.org/mail-arch/unicode-ml/y2010-m01/0030.html

Several discussions, in the past years, stated that we should be able to input 
combining sequences using dead keys, a feature supported by macOS and Linux 
natively, while Windows does not come along with that kind of support, although 
this is recommended by TUS: “It is straightforward to adapt such a system to emit 
combining character sequences or precomposed characters as needed.” (5.12, p. 222)

http://www.unicode.org/versions/Unicode10.0.0/ch05.pdf#G1076

In a 2015 discussion we/I also learned that Tavultesoft Keyman, now SIL, provides 
all these features and is cross-platform, and had a free offer since long, now even 
including the Developer tooling thanks to backing by SIL. Iʼm advertising this software 
to advocate Microsoftʼs presumed position: For all that goes beyond legacy support, 
we can rely on Keyman. 

As a consequence, layouts that are to be shipped with Windows, such as the new 
French, must stick with Windows resources (input editors are excluded by spec), 
whereas minority languages needing extended functionalities can promote additional 
software for support, as far as they are not expected to be supported out-of-the-box.

Hopefully we can now expect, by contrast, that Apple will add the missing toggle, 
internally VK_KANA on Windows (Linux is reported to have it, too), to make it 
available on macOS as well.

Regards,

Marcel