collation tailoring using before

[Philippe Verdy via CLDR-Users]

What's the problem? [0000.8000.0500] is primary ignorable (0000) and then
gets a synthetic secondary key (8000) whose value will not matter relative
to "a" given that "a" has a non-zero primary key and will sort properly.

Note that we know that:
    &[before 2][first primary ignorable] << "a"
and your tailoring says nothing about the relative secondary ordering
between "a" and \u0300 (like in mathematics, with the condition x < u and x
< a you say that u < a or  a < u, this is not specified)

I suppose you want to add this constraint:
    &[before 2][first primary ignorable] >> \u0300
(similar to saying x > u and x < a, which would be equivalent to u<x<a,
from which you can conclude u<a)
but this kind of reset is not possible.


Clearly you are forgetting to add rules, the one you specify is not enough
to tailor the secondary ordering as you want.

But the following could do the trick for "a", but not all primary non-ignorable
characters):
    &[before 2][first primary ignorable] << \u0300 << "a"

So you would get CEs like:
    a       [2900.8001.0500],
    \u0300  [0000.8000.0500],
but actually not:
    a       [2900.0500.0500],
    \u0300  [0000.0400.0500],
even if for this pair of characters they sort equivalently at all 3 levels
(the binary ordering at 4th level is unaltered)


2017-08-09 11:23 GMT+02:00 Martin Hosken via CLDR-Users <
cldr-users at unicode.org>:

> Dear All,
>
> I am trying to tailor (for the sake of argument) \u0300 to be primary
> ignorable and have a secondary collation key less than that of a primary
> character (a).
>
> I tried:
>
> &[before 2][first primary ignorable] << \u0300
>
> But then I get CEs of this form:
>
> a       [2900.0500.0500]
> \u0300  [0000.8000.0500]
>
> I'm wondering how I can get \u0300 [0000.0400.0500].
>
> TIA,
> Yours,
> Martin
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20170809/e5970807/attachment.html>