Variants -- Grave and Dot Above
Dear Colleagues, I would like to circle back to something we discussed in our meeting Thursday. When looking at Section 6.3.1.3 we talked about this entry: | Latin Small Letter I with Grave | 0069 | ì | ↔ | ỉ | 1EC9 | Latin Small Letter I with Hook Above | Blocked | As Dennis quite correctly noted in the Comments, we had determined that code points 0069 and 1EC9 were not variants. But as we later determined, we had found Latin Small Letter I with Grave and Latin Small Letter I with Hook Above to be variants. That's what this entry was for -- the code point names and glyphs were correct, just the Unicode number was wrong. Here's what I find fascinating. Clearly Dennis was looking closely at the entry. But closely as he was looking, even Dennis didn't notice that the glyph was Small Letter I with Grave rather than just Small Letter I. And yet, we have ruled generally that Grave and Dot Above do not create variant pairs. Something is very wrong here. Bill
Bill, The data we were looking at is for the Grave and Hook Above group (Section 6.3.1.3). (Yes, the code point is wrong in one instance, but that is secondary and needs to be fixed). What I was referring to is the following: the analysis states Not a Variant (last column is the final decision by the panel and there is additional comments to overrule or change its status). 00EC LATIN SMALL LETTER I WITH GRAVE ì ỉ 1EC9 LATIN SMALL LETTER I WITH HOOK ABOVE 2 3 2 2 3 3 2 2 Variant No Not a variant Not a variant ì ỉ 3 3 3 2 3 2 2 3 No ì ỉ 2 3 2 2 3 3 2 2 No Unlike the cases for “tilde and macron” or “acute and dot above” where the panel decided to overrule the individual scores and opt for a generalization of the variant relationship (i.e. based on diacritic families, instead of independent pairs), the case of I with Grave and I with Hook Above remains unchanged. At least, there is no formal overruling recorded in the worksheet as we did with the other cases. And we did the same for other pairs (i.e. not changing the variant status). I believe Pitinan was going to review her notes to cross-check. Dennis From: Latingp <latingp-bounces@icann.org> on behalf of Bill Jouris via Latingp <latingp@icann.org> Reply-To: Bill Jouris <b_jouris@yahoo.com> Date: Friday, September 18, 2020 at 2:50 PM To: Latin GP <latingp@icann.org> Subject: [EXTERNAL] [Latingp] Variants -- Grave and Dot Above Dear Colleagues, I would like to circle back to something we discussed in our meeting Thursday. When looking at Section 6.3.1.3 we talked about this entry: Latin Small Letter I with Grave 0069 ì ↔ ỉ 1EC9 Latin Small Letter I with Hook Above Blocked As Dennis quite correctly noted in the Comments, we had determined that code points 0069 and 1EC9 were not variants. But as we later determined, we had found Latin Small Letter I with Grave and Latin Small Letter I with Hook Above to be variants. That's what this entry was for -- the code point names and glyphs were correct, just the Unicode number was wrong. Here's what I find fascinating. Clearly Dennis was looking closely at the entry. But closely as he was looking, even Dennis didn't notice that the glyph was Small Letter I with Grave rather than just Small Letter I. And yet, we have ruled generally that Grave and Dot Above do not create variant pairs. Something is very wrong here. Bill
Hi Dennis, My recollection is that, in the duscussionThursday, you referred to the code point as "0069", rather than by name. Until someone (Mats, I think) pointed out the the Unicode number in the table was wrong. But I would have to listen to the recording to be certain. If we have a consistency issue with this pair, then you are correct that we should address it explicitly. Bill Sent from Yahoo Mail on Android On Fri, Sep 18, 2020 at 12:20 PM, Tan Tanaka, Dennis via Latingp<latingp@icann.org> wrote: _______________________________________________ Latingp mailing list Latingp@icann.org https://mm.icann.org/mailman/listinfo/latingp _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (3)
-
Bill Jouris -
Bill Jouris -
Tan Tanaka, Dennis