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. [cid:image001.png@01D72C5A.3FE1F250] 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
