Thanks Michael.

Re: Variant set 34, I was looking at the HTML version on PDF, so that explains the visual differences. I take my observation back.

Re: two/four allocatable labels reference. Yes, it was confusing because the sentence was part of the Dotless I paragraph. And technically, there would be up to three allocatable variants, not four. The original one is not a variant label per se. I would just delete the whole sentence and avoid the confusing statement.

Best,

Dennis

PS. Apologies for today’s meeting, but I have a conflict that I cannot reschedule.

On 4/8/21, 3:22 AM, "Latingp on behalf of Michael Bauland via Latingp" <latingp-bounces@icann.org on behalf of latingp@icann.org> wrote:

    Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

    Hi Dennis, hi all,

    please see my comments inline.

    On 07.04.2021 20:46, Tan Tanaka, Dennis via Latingp wrote:

    > Pitinan,

    >

    > 

    >

    > Thank you for putting this together. I have a few observations:

    >

    >  1. Assuming the HTML version is consistent with the XML version of the

    >     proposal, there are a number of variant relationships that (IMO) do

    >     not belong in the Latin GP proposal. These would be appropriate for

    >     the merged version of the RZ-LGR, however. There are various

    >     examples, but I can list a few: Variant Set 1 (0061-03AC)

    I agree, this seems to have come from the greek proposal. It should not

    be included in our version.

    > , Variant

    >     Set 8 (00EF-03AF),

    I agree again. We only have a relationship between 00ED and 03AD and

    since we also don't have 00EF to 00ED, I don't see a reason having this

    in there.

    > Variant Set 48 (025B-03AD).

    03AD does not occur anyway in our document. Strange that it's in there.

    So, yes, I also agree to remove that.

    > My gut feeling is

    >     that we are picking up those pairs from the Greek proposal. If so,

    >     they should be removed from the Latin-specific proposal.

    >  2. Variant Set 18: I think we are missing 01DF 01DF – 00DF, and 0455

    >     0455 – 00DF. And others to round up a well behaved variant set, but

    >     once the former pairs are input into the tool, those should be

    >     populated automagically.

    You are right. Those relations do exist in our document, though (page

    83). I assume they have been added after our recent discussions, but

    have not made their way to the LGR XML/HTML file, yet.

    >  3. Variant Set 34: instead of “glyphs nearly identical…” it should read

    >     “homoglyph”.

    Here I disagree. Why do you think they should be homoglyphs? Looking at

    our document, I see that they are similar, but not the same. There is a

    clear distinction between 00FF and 04F1. See also attached screenshot.

    >  4. The Variant Type labels are not being used consistently. There are

    >     parts where “r-eszett” is used, and in others it is referred to

    >     “r-german”.

    Yes, we should be consistent. It used to be r-german, but we discussed

    quite a while about this and decided our labels should not refer to any

    language and therefore change it to r-eszett. Similarly, all occurrences

    of "swiss" (at least in the context of rules/actions) should be replaced

    by "eszett-to-ss".

    >  5. Typo in Dotless I paragraph. Last sentence reads “total of up to

    >     four allocatable labels”. I think this meant to say “two allocatable

    >     labels”.

    No, I don't think it's a typo. It relates to the first part of the

    sentence ("Note that this restriction is independent of the restriction

    on variants of sharp s"). The four allocatable labels are thus

    1. original label

    2. label with Dotless i => i

    3. label with ß => ss

    4. label with Dotless i => i AND ß => ss

    However, if even you are confused by this, maybe we should rephrase it a

    bit.

    Suggestion:

    Note that this restriction is independent of the restriction on variants

    of sharp s, see above, so that together with the sharp s rules, a total

    of up to four allocatable labels may exist for any Latin variant.

    Cheers,

    Michael

    --

    ____________________________________________________________________

         |       |

         | knipp |            Knipp  Medien und Kommunikation GmbH

          -------                    Technologiepark

                                     Martin-Schmeisser-Weg 9

                                     44227 Dortmund

                                     Germany

         Dipl.-Informatiker          Fon:    +49 231 9703-0

                                     Fax:    +49 231 9703-200

         Dr. Michael Bauland         SIP:    Michael.Bauland@knipp.de

         Software Development        E-mail: Michael.Bauland@knipp.de

                                     Register Court:

                                     Amtsgericht Dortmund, HRB 13728

                                     Chief Executive Officers:

                                     Dietmar Knipp, Elmar Knipp