Re: [I18ndir] [art] Modern Network Unicode

[John C Klensin <[e-mail]>]

(top post and adding the ART list back in)

Carsten, 
I think Asmus and I are in complete agreement, but you might
find an attempt to summarize the state of work for relevant
characteristics and behaviors on the web, some of which interact
with this discussion, illuminating.  It is a chart with
explanation, not a long document.  See
https://w3c.github.io/typography/gap-analysis/language-matrix.html 

best,
   john


--On Thursday, July 11, 2019 08:51 -0700 "Asmus Freytag (c)"
<[e-mail]> wrote:

> On 7/11/2019 12:03 AM, Carsten Bormann wrote:
>> On Jul 11, 2019, at 01:00, Asmus Freytag
>> <[e-mail]> wrote:
>>> There are a few scripts where un-normalized text is
>>> "preferred" by the user community over NFC. In some cases,
>>> the most natural ordering of combining marks does not match
>>> NFC's canonical ordering. I other cases, NFC does not
>>> compose some sequences while local user communities strongly
>>> prefer the precomposed code points (e.g. Bengali).
>> Interesting.  There are also a few writing systems where NFC
>> is what is strongly preferred by the user community.
>> 
>> Is there any effort to capture these preferences in a formal
>> way so they become more accessible to international developer
>> communities?
> 
> No. Note least because these preferences may not be stable
> over (longish) periods of time as they depend a bit on what
> keyboards / rendering platforms and apps handle best today.
> 
> A./
> 
>> 
>>> Those scripts would be an exception to John's statement: "
>>> NFC is also a close approximation to what any sensible
>>> terminal driver or IME is going to produce natively from a
>>> plausible keyboard layout for the relevant script", a
>>> statement that otherwise holds well.
>> Right.  It is interesting to see how Apple recently moved
>> from a normalizing file system (HFS+ was normalizing [to NFD
>> unfortunately, and using UTF-16 on disk]) to a
>> normalization-preserving, normalize-before-comparison
>> ("normalization-insensitive") file system (APFS).  It is
>> also interesting how the problem is "solved" in
>> applications such as git (core.precomposeunicode needs to be
>> set to true on platforms that tend to generate non-NFC names
>> so other platforms can pretend to stay blissfully unaware).
>> 
>> Grüße, Carsten
>> 
>