This is what Markus had to say (he implemented most of the collation for ICU):
"http://www.unicode.org/reports/tr10/#Avoiding_Normalization Step 1 of the algorithm: http://www.unicode.org/reports/tr10/#Step_1 which has a note: - Conformant implementations may skip this step *in certain circumstances: *see *Section 6.5, Avoiding Normalization<http://www.unicode.org/reports/tr10/#Avoiding_Normalization> * for more information. See also http://www.unicode.org/reports/tr10/#Parametic_Tailoring -> attribute "normalization", see the description there (this whole table 14 will soon move to the LDML spec, leaving only a link in this place)" So the question is: 1. Do we change i18n API default for normalization to always be true, with some performance penalty? 2. Update ES 262 spec with info Markus passed (if possible)? 2012/8/30 Mark Davis ☕ <m...@macchiato.com> > ICU *is* always able to compare them as being equal, just by setting the > parameter. > > Even if the parameter isn't set, it uses an FCD sort (see > http://unicode.org/notes/tn5/) and canonical closure, which handles most > cases of canonical equivalence. The default is turned on for languages > where the normal+auxiliary exemplar sets contains characters that would > show a difference even with an FCD+closure sort, and can be turned on > always if desired (at some cost in performance; 30% sounds high though). > > Mark <https://plus.google.com/114199149796022210033> > * > * > *— Il meglio è l’inimico del bene —* > ** > > > > On Thu, Aug 30, 2012 at 6:30 PM, Norbert Lindenberg < > ecmascr...@norbertlindenberg.com> wrote: > >> In particular, a conformant implementation must be able to compare any >> two canonical-equivalent strings as being equal, for all Unicode characters >> supported by that implementation." > > > -- Nebojša Ćirić
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
