From vsil at gaultney.org Thu Sep 1 02:50:16 2022 From: vsil at gaultney.org (Victor Gaultney) Date: Thu, 1 Sep 2022 08:50:16 +0100 Subject: Burmese Rendering (dots and circles) In-Reply-To: References: <5195eb09-6d80-ed86-f574-74feb908e0a9@shoulson.com> <20220830091539.21e445c8@JRWUBU2> <351a03f4-9bf7-e19d-e42f-67072f2f4810@code2001.com> <20220901035300.2f4af875@JRWUBU2> Message-ID: <57bd14c4-c532-5201-98b9-6b6796ebaea6@gaultney.org> Everyone - Thanks for the specific info related to our Padauk fonts. If you have suggestions for improvements to Padauk the most productive route would be to make an issue on the project Github project for each request. That would enable easier discussion of the specific sequence/form/language, and help destinguish between standard-related and font-related issues. https://github.com/silnrsi/font-padauk/issues Victor Gaultney SIL International -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameskass at code2001.com Thu Sep 1 07:01:00 2022 From: jameskass at code2001.com (James Kass) Date: Thu, 1 Sep 2022 12:01:00 +0000 Subject: Burmese Rendering (dots and circles) In-Reply-To: References: <5195eb09-6d80-ed86-f574-74feb908e0a9@shoulson.com> <20220830091539.21e445c8@JRWUBU2> <351a03f4-9bf7-e19d-e42f-67072f2f4810@code2001.com> <20220901035300.2f4af875@JRWUBU2> Message-ID: <9fecfbb0-bd0f-4eca-4a6c-54abbb8ee409@code2001.com> Pyidaungsu is a popular Myanmar font which covers the extensions. Interestingly, all of the glyphs which could have a center dot or a center circle are drawn with a center circle in that font.? This suggests that Richard's earlier observation about the users not necessarily making a distinction between U+1051 and U+A9FD is valid. FWIW, Pyidaungsu shows the Medial Wa character as a circle and does not support the VIRAMA+WA sequence. N3043.PDF, however, seems quite clear that the Medial Wa character should render differently than the VIRAMA+WA sequence. "The current sequences (VIRAMA + YA/RA/WA/HA) remain valid sequences but for different renderings.? Those renderings do not occur in modern Burmese, but they do occur in older orthography, in Pali and Sanskrit.? Encoding the explicit medials allows for simple representation of both kinds of orthography." There's even a handy chart showing the distinctions.? Unfortunately it's quite difficult to tell the difference between VIRAMA+WA and MEDIAL WA in that chart without magnification.? With magnification the MEDIAL WA is vaguely teardrop shaped. From richard.wordingham at ntlworld.com Thu Sep 1 15:08:46 2022 From: richard.wordingham at ntlworld.com (Richard Wordingham) Date: Thu, 1 Sep 2022 21:08:46 +0100 Subject: Burmese Rendering (dots and circles) In-Reply-To: References: <5195eb09-6d80-ed86-f574-74feb908e0a9@shoulson.com> <20220830091539.21e445c8@JRWUBU2> <351a03f4-9bf7-e19d-e42f-67072f2f4810@code2001.com> <20220901035300.2f4af875@JRWUBU2> Message-ID: <20220901210846.52e8db55@JRWUBU2> On Thu, 1 Sep 2022 04:51:05 +0000 James Kass via Unicode wrote: > In a subsequent Myanmar proposal, N3143, the glyph for U+103D (Medial > Wa) is shown as a circle, picture attached.? In the current code > charts, Medial Wa is teardrop shaped. > > So : ? + ? ?? ? > > Since the new character was a disunification rather than a > replacement, a Myanmar font should support both the sequence and the > Medial Wa character.? And the Medial Wa character should display as a > teardrop shape rather than a circle.? And the virama sequence glyph > should display as a circle, which is simply a reduced letter Wa.? Is > this correct? No. According to the descriptions, is *optionally* somewhat triangular, but is mandatorily round. There is no obligation to distinguish them glyphically. (I have done no research to verify this - I am dependent on the information reported to the Unicode Consortium.) How triangular the MEDIAL WA glyph is varies - the Sixth Council text at https://www.pali-text-images.net/cst/02-suttantapitaka/06-dighanikaya-1-cst.pdf has a very triangular subscript WA. > As Richard has pointed out, the Padauk font does not support the > Virama+Wa sequence. This is consistent with technical note UTN-11 Version 4, which gives the encoding for Sanskrit as . Richard. From richard.wordingham at ntlworld.com Fri Sep 2 13:49:49 2022 From: richard.wordingham at ntlworld.com (Richard Wordingham) Date: Fri, 2 Sep 2022 19:49:49 +0100 Subject: Burmese Rendering (dots and circles) In-Reply-To: <18bd36f3-6e8f-30ba-ff98-5cc06050aa02@code2001.com> References: <9cf0dc27-79f6-5872-02d6-c8686873b89c@code2001.com> <18bd36f3-6e8f-30ba-ff98-5cc06050aa02@code2001.com> Message-ID: <20220902194949.4e54546e@JRWUBU2> On Fri, 2 Sep 2022 04:38:53 +0000 James Kass wrote: > (Hi Richard, this was sent to the Unicode list, but was rejected as > spam.? Feel free to reply on the public list, privately, or not at > all.?? -JK) > On 2022-09-01 8:08 PM, Richard Wordingham via Unicode wrote: > >> As Richard has pointed out, the font does not support > >> the Virama+Wa sequence. > > This is consistent with technical note UTN-11 Version 4, which gives > > the encoding for Sanskrit as > MYANMAR SIGN VIRAMA, U+1010 MYANMAR LETTER TA, U+103D MEDIAL WA>. > > https://www.unicode.org/notes/tn11/UTN11_4.pdf > > That sequence is shown on page 28 of the document. > > I apologize for my inability to understand this.? Since U+103D is > supposedly for modern Burmese, and the "virama plus" sequences are > reserved for historic purposes, I expected the sequence for Burmese > (Sanskrit) to be 1000 1039 1010 1039 101D [ka + virama + ta + > virama + wa]. > > It's also not clear to me how any given font's lack of support for > rendering a "virama plus" sequence is consistent with UTN11. > Should a Myanmar Unicode font support "virama plus" sequences, or not? If a sequence doesn't occur naturally, does a font need to support it? After all some, Indic (sensu lato) rendering engines deliberately restrict the number of codepoints of a cluster. The evidence for some subscript forms is hard to come by. Some rare examples of Shan Pali subscript consonants can be found at https://github.com/notofonts/myanmar/issues/19 . UTN-11 contains the self-contradictory statement, "Not every consonant can be stacked, and while theoretically any consonant can take a subjoined form, not all implementations will necessarily need to support all subjoined forms". Acting on this, the Shan Pali consonants are not included in the element 'stacked', and Padauk does not support them. > If not, why was a certain font's lack of support for a "virama plus" > sequence mentioned in a derogatory fashion? The UTS calls out for support of , and a one-time programmer of the font, Martin Hosken, supported assertions of its existence. Richard. From jameskass at code2001.com Sat Sep 3 02:56:04 2022 From: jameskass at code2001.com (James Kass) Date: Sat, 3 Sep 2022 07:56:04 +0000 Subject: Burmese Rendering (dots and circles) In-Reply-To: <20220902194949.4e54546e@JRWUBU2> References: <9cf0dc27-79f6-5872-02d6-c8686873b89c@code2001.com> <18bd36f3-6e8f-30ba-ff98-5cc06050aa02@code2001.com> <20220902194949.4e54546e@JRWUBU2> Message-ID: On 2022-09-02 6:49 PM, Richard Wordingham via Unicode wrote: > The evidence for some subscript forms is hard to come by. Some rare > examples of Shan Pali subscript consonants can be found at > https://github.com/notofonts/myanmar/issues/19 . UTN-11 contains the > self-contradictory statement, "Not every consonant can > be stacked, and while theoretically any consonant can take a subjoined > form, not all implementations will necessarily need to support all > subjoined forms". Acting on this, the Shan Pali consonants are not > included in the element 'stacked', and Padauk does not support them. "... theoretically any consonant can take a subjoined form..." Since that is a convention of the writing system. "...not all implementations will necessarily need to support all subjoined forms." IMO, that's a presumption akin to thinking that native users would never want to use their own script to phonetically spell out a foreign word.? Such as names of Aztec gods, for example. >> If not, why was a certain font's lack of support for a "virama plus" >> sequence mentioned in a derogatory fashion? > The UTS calls out for support of , and a one-time > programmer of the font, Martin Hosken, supported assertions of its > existence. So when the aforementioned fonts treat VIRAMA+WA as a defective sequence, they are doing so in accordance with UTN11 and in spite of precedent (viz. N3043 etc.). Thank you for the explanations and the helpful pointers. From jameskass at code2001.com Sat Sep 3 04:40:46 2022 From: jameskass at code2001.com (James Kass) Date: Sat, 3 Sep 2022 09:40:46 +0000 Subject: Burmese Rendering (dots and circles) In-Reply-To: References: <9cf0dc27-79f6-5872-02d6-c8686873b89c@code2001.com> <18bd36f3-6e8f-30ba-ff98-5cc06050aa02@code2001.com> <20220902194949.4e54546e@JRWUBU2> Message-ID: <890ab66f-752f-cdbe-b0cd-63f5185e1a7e@code2001.com> On 2022-09-03 7:56 AM, James Kass via Unicode wrote: > IMO, that's a presumption akin to thinking that native users would > never want to use their own script to phonetically spell out a foreign > word.? Such as names of Aztec gods, for example. They could use the ASAT character, of course.? Indeed, they'd have to under the current set up. From corentin.jabot at gmail.com Thu Sep 15 06:41:16 2022 From: corentin.jabot at gmail.com (Corentin) Date: Thu, 15 Sep 2022 13:41:16 +0200 Subject: East_Asian_Width of Yijing Hexagram Symbols Message-ID: Hello, I was wondering why 4DC0..4DFF (Yijing Hexagram Symbols) are not considered Wide for the purpose of East_Asian_Width If I understand correctly, they are CJK characters and they certainly look like other CJK characters. Thanks a lot, Corentin Jabot -------------- next part -------------- An HTML attachment was scrubbed... URL: From 747.neutron at gmail.com Thu Sep 15 09:12:58 2022 From: 747.neutron at gmail.com (=?UTF-8?B?V8OhbmcgWWlmw6Fu?=) Date: Thu, 15 Sep 2022 23:12:58 +0900 Subject: East_Asian_Width of Yijing Hexagram Symbols In-Reply-To: References: Message-ID: > I was wondering why 4DC0..4DFF (Yijing Hexagram Symbols) are not considered Wide for the purpose of East_Asian_Width Those symbols are certainly of historical CJK origin, but not from traditional CJK character sets. In fact they are proposed by Western experts (L2/01-283). AFAIK, EAW is a data set to improve interoperability with environments using some double-byte encoding schemes where display widths are tied with byte sizes, so no meaningful value is defined for characters which are not found in those legacy character encodings. 2022?9?15?(?) 20:46 Corentin via Unicode : > > Hello, > > I was wondering why 4DC0..4DFF (Yijing Hexagram Symbols) are not considered Wide for the purpose of East_Asian_Width > > If I understand correctly, they are CJK characters and they certainly look like other CJK characters. > > Thanks a lot, > > Corentin Jabot > > From abrahamgross at disroot.org Thu Sep 15 09:59:18 2022 From: abrahamgross at disroot.org (ag disroot) Date: Thu, 15 Sep 2022 14:59:18 +0000 (UTC) Subject: East_Asian_Width of Yijing Hexagram Symbols In-Reply-To: References: Message-ID: <3a108a0c-7351-48d9-9098-e4e566ede6a0@disroot.org> Korea has 4 of these symbols (only trigrams) on their flag Since it was created in east asia where everything was monospaced, it would stand to reason that it should be the same size too From abehjat at apple.com Fri Sep 23 13:41:50 2022 From: abehjat at apple.com (Adib Behjat) Date: Fri, 23 Sep 2022 11:41:50 -0700 Subject: Process of transforming existing glyphs to emojis via variants Message-ID: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> Hello and Happy Friday! I have a question with regards to transformation of existing glyphs into emojis. At the moment, there's no documentation present with regards to this process, and the only available example is Michel Suignard proposal for including Webdings and Wingdings into emoji set: https://www.unicode.org/L2/L2011/11344-wingdings.pdf. I was reviewing the Sikh Khanda proposal and its implementation, and I noticed that a new code point was given for it in the emoji list on the https://unicode.org/emoji/charts/emoji-list.html (U+1FAAF). This code point was created despite the fact the glyph already existed in Unicode 1.1 with code point U+262C. Wouldn't it have been more efficient to utilize a variant instead of a new code point for the Sikh Khanda? I reviewed the "The Unicode Standard" Variation Selectors Chapter, and I believe it satisfies the conditions for the original glyph U+262C to have been appended with a variant given the proposal (it?s a glyph that won?t be used along side other base glyphs or texts to impact the representation of the character along with other characters). To circle back, for existing scripts/glyphs that are in Unicode blocks but not in Emoji format, is there a documentation on utilizing variants to transform a said glyph to emoji depending on platform? From doug at ewellic.org Fri Sep 23 15:03:12 2022 From: doug at ewellic.org (Doug Ewell) Date: Fri, 23 Sep 2022 20:03:12 +0000 Subject: Process of transforming existing glyphs to emojis via variants In-Reply-To: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> References: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> Message-ID: Adib Behjat wrote: > I have a question with regards to transformation of existing glyphs > into emojis. At the moment, there's no documentation present with > regards to this process, and the only available example is Michel > Suignard proposal for including Webdings and Wingdings into emoji > set: https://www.unicode.org/L2/L2011/11344-wingdings.pdf. That proposal was about adding the Wingdings and Webdings characters into Unicode, as characters, and had nothing to do with giving them emoji properties. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org From doug at ewellic.org Fri Sep 23 15:21:01 2022 From: doug at ewellic.org (Doug Ewell) Date: Fri, 23 Sep 2022 20:21:01 +0000 Subject: Process of transforming existing glyphs to emojis via variants In-Reply-To: <12E6AA1B-4D6D-4B0D-A732-FECAC60EF2F9@apple.com> References: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> <12E6AA1B-4D6D-4B0D-A732-FECAC60EF2F9@apple.com> Message-ID: Adib Behjat wrote: >>> I have a question with regards to transformation of existing glyphs >>> into emojis. At the moment, there's no documentation present with >>> regards to this process, and the only available example is Michel >>> Suignard proposal for including Webdings and Wingdings into emoji >>> set: https://www.unicode.org/L2/L2011/11344-wingdings.pdf. >> >> That proposal was about adding the Wingdings and Webdings characters >> into Unicode, as characters, and had nothing to do with giving them >> emoji properties. > > Michael?s proposal was listed as part of Emoji Proposals based on the > following page: https://www.unicode.org/reports/tr51/, found in this > link https://unicode.org/L2/L2011/11052r-wingding.pdf. > > I think the link I shared is the updated proposal (2011-02-15 vs. > 2011-09-23, respectively). I might be mistaken. Can you point me to the section of the proposal you linked, or any of Michel Suignard's proposals on Wingdings and Webdings, that talks about "transformation of existing [Unicode] glyphs into emojis"? -- Doug Ewell, CC, ALB | Lakewood, CO, US | http://ewellic.org From abehjat at apple.com Fri Sep 23 15:14:46 2022 From: abehjat at apple.com (Adib Behjat) Date: Fri, 23 Sep 2022 13:14:46 -0700 Subject: Process of transforming existing glyphs to emojis via variants In-Reply-To: References: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> Message-ID: <12E6AA1B-4D6D-4B0D-A732-FECAC60EF2F9@apple.com> Michael?s proposal was listed as part of Emoji Proposals based on the following page: https://www.unicode.org/reports/tr51/, found in this link https://unicode.org/L2/L2011/11052r-wingding.pdf . I think the link I shared is the updated proposal (2011-02-15 vs. 2011-09-23, respectively). > On Sep 23, 2022, at 1:03 PM, Doug Ewell wrote: > > Adib Behjat wrote: > >> I have a question with regards to transformation of existing glyphs >> into emojis. At the moment, there's no documentation present with >> regards to this process, and the only available example is Michel >> Suignard proposal for including Webdings and Wingdings into emoji >> set: https://www.unicode.org/L2/L2011/11344-wingdings.pdf. > > That proposal was about adding the Wingdings and Webdings characters into Unicode, as characters, and had nothing to do with giving them emoji properties. > > -- > Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abehjat at apple.com Fri Sep 23 15:54:17 2022 From: abehjat at apple.com (Adib Behjat) Date: Fri, 23 Sep 2022 13:54:17 -0700 Subject: Process of transforming existing glyphs to emojis via variants In-Reply-To: References: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> <12E6AA1B-4D6D-4B0D-A732-FECAC60EF2F9@apple.com> Message-ID: <227E89EE-D76E-41EF-A205-6703CDFCCBF0@apple.com> You?re correct that It wasn?t explicitly stated in the document shared. I used that document as an example from the list of emoji proposals, and the document held symbols within Webding/Wingding that are represented in both text and emoji that share the same code point (e.g. zodiac symbols). Though it seems I misunderstood the purpose of the document, and realized it?s mapping Webding/Wingding elements to existing Unicode code points, and in turn some of those elements have variants. I should?ve used the ?Emoji Presentation Sequences? (https://www.unicode.org/emoji/charts/emoji-variants.html ) to present my question. Going back to the original question, I?m still curious why a new code point was created instead of using variants for an existing code point, and if there?s a process for adding variants to existing code points so they can be represented as emojis. > On Sep 23, 2022, at 1:21 PM, Doug Ewell wrote: > > Adib Behjat wrote: > >>>> I have a question with regards to transformation of existing glyphs >>>> into emojis. At the moment, there's no documentation present with >>>> regards to this process, and the only available example is Michel >>>> Suignard proposal for including Webdings and Wingdings into emoji >>>> set: https://www.unicode.org/L2/L2011/11344-wingdings.pdf. >>> >>> That proposal was about adding the Wingdings and Webdings characters >>> into Unicode, as characters, and had nothing to do with giving them >>> emoji properties. >> >> Michael?s proposal was listed as part of Emoji Proposals based on the >> following page: https://www.unicode.org/reports/tr51/, found in this >> link https://unicode.org/L2/L2011/11052r-wingding.pdf. >> >> I think the link I shared is the updated proposal (2011-02-15 vs. >> 2011-09-23, respectively). > > I might be mistaken. Can you point me to the section of the proposal you linked, or any of Michel Suignard's proposals on Wingdings and Webdings, that talks about "transformation of existing [Unicode] glyphs into emojis"? > > -- > Doug Ewell, CC, ALB | Lakewood, CO, US | http://ewellic.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameskass at code2001.com Sat Sep 24 02:54:18 2022 From: jameskass at code2001.com (James Kass) Date: Sat, 24 Sep 2022 07:54:18 +0000 Subject: Process of transforming existing glyphs to emojis via variants In-Reply-To: <227E89EE-D76E-41EF-A205-6703CDFCCBF0@apple.com> References: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> <12E6AA1B-4D6D-4B0D-A732-FECAC60EF2F9@apple.com> <227E89EE-D76E-41EF-A205-6703CDFCCBF0@apple.com> Message-ID: <373b795a-74da-f48a-382e-f89e5e46e802@code2001.com> On 2022-09-23 8:54 PM, Adib Behjat via Unicode wrote: > Going back to the original question, I?m still curious why a new code point was created instead of using variants for an existing code point, and if there?s a process for adding variants to existing code points so they can be represented as emojis. It's a good question.? Perhaps there was some misunderstanding involved.? The emoji-khanda proposal ( https://www.unicode.org/L2/L2021/21223-khanda-emoji.pdf ) mentions the symbol being encoded at U+262C (?) under the name "adi shakti" with no emoji version and suggests that the symbol be updated to become "khanda".? (Note that U+626C has "khanda" as an alias for the symbol.)? It may be the responsibility of the Emoji Subcommittee to determine if existing code points should have emoji variants rather than being left up to the proposer. From gtbot2007 at gmail.com Sun Sep 25 21:29:40 2022 From: gtbot2007 at gmail.com (Gabriel Tellez) Date: Sun, 25 Sep 2022 22:29:40 -0400 Subject: Process of transforming existing glyphs to emojis via variants In-Reply-To: <373b795a-74da-f48a-382e-f89e5e46e802@code2001.com> References: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> <12E6AA1B-4D6D-4B0D-A732-FECAC60EF2F9@apple.com> <227E89EE-D76E-41EF-A205-6703CDFCCBF0@apple.com> <373b795a-74da-f48a-382e-f89e5e46e802@code2001.com> Message-ID: Wait, so is the non-emoji version of U+1FAAF the same as U+262C? On Sat, Sep 24, 2022 at 3:57 AM James Kass via Unicode < unicode at corp.unicode.org> wrote: > > > On 2022-09-23 8:54 PM, Adib Behjat via Unicode wrote: > > Going back to the original question, I?m still curious why a new code > point was created instead of using variants for an existing code point, and > if there?s a process for adding variants to existing code points so they > can be represented as emojis. > It's a good question. Perhaps there was some misunderstanding > involved. The emoji-khanda proposal ( > https://www.unicode.org/L2/L2021/21223-khanda-emoji.pdf ) mentions the > symbol being encoded at U+262C (?) under the name "adi shakti" with no > emoji version and suggests that the symbol be updated to become > "khanda". (Note that U+626C has "khanda" as an alias for the symbol.) > It may be the responsibility of the Emoji Subcommittee to determine if > existing code points should have emoji variants rather than being left > up to the proposer. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at ewellic.org Mon Sep 26 11:36:38 2022 From: doug at ewellic.org (Doug Ewell) Date: Mon, 26 Sep 2022 16:36:38 +0000 Subject: Process of transforming existing glyphs to emojis via variants In-Reply-To: References: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> <12E6AA1B-4D6D-4B0D-A732-FECAC60EF2F9@apple.com> <227E89EE-D76E-41EF-A205-6703CDFCCBF0@apple.com> <373b795a-74da-f48a-382e-f89e5e46e802@code2001.com> Message-ID: Gabriel Tellez wrote: > Wait, so is the non-emoji version?of U+1FAAF the same as U+262C? Yes. The current thinking seems to be that this sort of duplicate encoding is preferably to "emojifying" existing characters, which has certainly caused some headaches on its own. For instance, I can no longer use the ordinary text symbols ? and ? and ? in some environments without them being converting to huge, comical emoji versions, even though these characters are supposed to default to text, and even when they are not followed by VS16. It probably remains to be seen which approach causes fewer problems and less confusion. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org From abrahamgross at disroot.org Mon Sep 26 12:24:58 2022 From: abrahamgross at disroot.org (ag disroot) Date: Mon, 26 Sep 2022 13:24:58 -0400 (EDT) Subject: Process of transforming existing glyphs to emojis via variants In-Reply-To: References: <97C21EFE-D609-4546-BA24-A2657597B1BC@apple.com> <12E6AA1B-4D6D-4B0D-A732-FECAC60EF2F9@apple.com> <227E89EE-D76E-41EF-A205-6703CDFCCBF0@apple.com> <373b795a-74da-f48a-382e-f89e5e46e802@code2001.com> Message-ID: <0447cd7a-8f45-43db-a1e0-3afdec8fc409@disroot.org> The comically large ?s are very annoying for me