Re: Keyboard layouts and CLDR

On Tue, 30 Jan 2018 10:20:46 +0000, Alastair Houghton wrote:
>
> On 30 Jan 2018, at 05:31, Marcel Schneider via Unicode wrote:
> >
> > OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
> >>
[…]
> >>
> >> They are also all on the MacOS "US International PC", provided since 2009 by Apple
> >> for Windows users who like US International.
> >
> > I suppose that this layout ships with the Windows emulation that can be run on a Mac.
>
> No. It’s included as standard with the macOS itself. Go to System Preferences, choose “Keyboard”, then “Input Sources”.
> Click the “+” button at the bottom left, then enter “PC” in the search field and you’ll see there are a range of “PC” layouts.

Indeed. Itʼs sort of a mix made of Appleʼs common US and Windowsʼ US-International.
So it has the five Windows-style dead keys in Base and Shift, AND the five Mac-style
dead keys (for the same diacritics) in Option.

>
> >> œ Œ are on alt and alt-shift q
> >>
> >> ‹› are on alt-shift 3/4
>
> More of a nitpick than anything, but Apple keyboards have *Option*, not “alt”. Yes, some (but not all) keyboards’ Option keys have an “alt”
> annotation at the top, but that was added AFAIK for the benefit of people running PC emulation (or these days, Windows under e.g. VMWare
> Fusion). The “alt” annotation isn’t on the latest keyboards (go look in an Apple Store if you don’t believe me :-)).

Then, “alt” is obsoleted on Mac, and calling them “Option” is correct? Iʼm relieved if so, as I
used “Option” when referring to macOS, or better, “AltGr/Option” to be cross-platform…
“Option” is shorter, but “AltGr” is already printed on most keyboards, though it isnʼt a short
form of an easily localizable term, while “Option” is multi-locale (English, French, German, …).

>
> > Then this is ported from the Apple US layout, where these characters are in the same
> > places. However that does not include correct spacing, as required for French.
>
> Not sure what you mean about spacing. That, surely, is a matter mainly for the software you’re using, rather than for a keyboard layout?

It may be handled by an input editing functionality as embedded in Word, like many things
can be done by input editing, even “œ” (for which Word has also a shortcut: Ctrl+&, o)
because Microsoft and Bill Gates in person were eager to support the French locale and
did a lot to help French efforts in keyboarding. But properly, correct spacing must be
handled on keyboard level, otherwise weʼll always end up with a mass of wrong data
amidst which a subset of correct documents having U+202F NARROW NO-BREAK SPACE
before ‘?’ and ‘!’ and ‘;’, and even ‘»’ and after ‘«’, and currently also before ‘:’ as
Philippe Verdy wrote to this List on Fri, 26 Jun 2015 22:16:48 +0200:

http://www.unicode.org/mail-arch/unicode-ml/y2015-m06/0220.html

“Les éditeurs de presse et de livres en France utilisent tous des fines de
chasse fixe dans leurs moteurs de composition”
(“Print media and book publishers in France all use fixed-width narrows in
their typesetting engines”)

Unicode did not support interoperable French typesetting until it encoded
U+202F for Mongolian, in 1999, six years after v1.1 of the Standard.
Making U+2008 PUNCTUATION SPACE a no-break space would have been
well done. This was seemingly encoded for hot-metal typesetting of tables,
like U+2012 FIGURE DASH and U+2007 FIGURE SPACE that is non-breakable.
While U+2007 can be considered a fixed-width counterpart of U+00A0, and
U+2012 could have been a longer variant of U+2212 to denote intervals
*if only* it had been specified as such, U+2008 could have been the proper
representation of French punctuation spacing, instead of ending up as a
completely useless character, depriving the French locale of Unicode support.
See the feedback items about these topics that have been posted so far:

http://www.unicode.org/L2/L2018/18009-pubrev.html#Error_Reports

>
> >> (US Extended has also been renamed ABC Extended back in 2015)
> >
> > Presumably because it is interesting for many locales worldwide accustomed to the
> > US QWERTY layout. That tends to prove that Mac users accept changes, while
> > Windows users refuse changes. However I fail to understand such a discrepancy.
>
> I don’t think it’s the users.
>
> I think, rather, that Apple is (or has been) prepared to make radical changes, even at the expense of backwards compatibility and even where it
> knows there will be short term pain from users complaining about them, where Microsoft is more conservative. 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.
>
> This is exemplified, actually, by the length of time Microsoft keeps backwards compatibility layers, versus the length of time Apple does so.
> The WoW subsystem is (I think) still part of the 32-bit builds of Windows, so they can still run Windows 3.1 software, DOS software and so on
> (i.e. software back to the 1980s). Apple, on the other hand, dropped support for “Classic” Mac apps back in 10.4 and has never supported
> running PowerPC classic apps on any Intel machine. Indeed, six years ago now, in Mac OS X 10.7, Apple dropped support for running PowerPC
> apps built for Mac OS X, which basically means that software Mac users bought to run on their older PowerPC-based Macs is now not usable on
> new machines.

Ah, good to know. Appleʼs (and some other companies) strategy is currently nicknamed
“programmed obsolescence.” Bingʼs top search result for that keyword is this BBC article:

http://www.bbc.com/future/story/20160612-heres-the-truth-about-the-planned-obsolescence-of-tech

Based on your report, I think that Apple push wealthy people to use always the best of tech,
whereas Microsoft help poor people alike not to discard well-functioning software.

Regards,

Marcel
Received on Tue Jan 30 2018 - 13:09:59 CST