Re: On the lack of a SQUARE TB glyph

I wrote: > As others have stated, it was easily demonstrated that applications > existed in Japan which required a single code point for the era name. > That is what necessitated the acceptance, let alone fast-tracking, of > U+32FF SQUARE ERA NAME REIWA. Well, this is what I've heard, anyway.

Re: On the lack of a SQUARE TB glyph

On Mon, 30 Sep 2019 01:32:02 -0700 Asmus Freytag via Unicode wrote: > On 9/30/2019 1:01 AM, Andre Schappo via Unicode wrote: > > On Sep 27, 1 Reiwa, at 08:17, Julian Bradfield via Unicode > wrote: > > Or one could allow IDS to have leaf components that are any >

Aw: Re: On the lack of a SQUARE TB glyph

SMALL CAL TRIGRAPH and millimol as HALFWIDTH LATIN SMALL LETTER M +  HALF WIDTH LATIN SMALL MOL TRIGRAPH.   Marius Spix   Gesendet: Montag, 30. September 2019 um 10:32 Uhr Von: "Asmus Freytag via Unicode" An: unicode@unicode.org Betreff: Re: On the lack of a SQUARE TB glyph On 9

Re: On the lack of a SQUARE TB glyph

On 9/30/2019 1:01 AM, Andre Schappo via Unicode wrote: On Sep 27, 1 Reiwa, at 08:17, Julian Bradfield via Unicode wrote: Or one could allow IDS to have leaf components that are any characters, not just ideographic characters, and then one could

Re: On the lack of a SQUARE TB glyph

> On Sep 27, 1 Reiwa, at 08:17, Julian Bradfield via Unicode > wrote: > > Or one could allow IDS to have leaf components that are any > characters, not just ideographic characters, and then one could have > all sorts of fun. I do like this idea. Note: This is a mo

Re: On the lack of a SQUARE TB glyph

On 9/29/2019 7:42 AM, Andre Schappo via Unicode wrote: Or one could allow IDS to have leaf components that are any characters, not just ideographic characters, and then one could have all sorts of fun. I do like that idea André

Re: On the lack of a SQUARE TB glyph

Fred Brennan wrote: > The purpose of Unicode is plaintext encoding, is it not? The square TB > form is fundamentally no different than the square form of Reiwa, > U+32FF ㋿, which was added in a hurry. The difference is that SQUARE > TB's necessity and use is a slow thing which happened over years,

Re: On the lack of a SQUARE TB glyph

> Or one could allow IDS to have leaf components that are any > characters, not just ideographic characters, and then one could have > all sorts of fun. I do like that idea André Schappo

Re: On the lack of a SQUARE TB glyph

mmediately agreed to it. So there isn't an immediately urgent deadline for new proposals. --Ken On 9/26/2019 10:15 PM, Fred Brennan via Unicode wrote: When does the Script Ad Hoc meet next?

Re: On the lack of a SQUARE TB glyph

use I don't know a case that KB, MB... are used outside representational purpose, but I may be wrong. 2019年9月27日(金) 14:17 Fred Brennan via Unicode : > > I'm sorry to write twice to the list but after some discussion on Twitter it > is certain I'm going to write a request. &g

Re: On the lack of a SQUARE TB glyph

On 2019-09-27, David Starner via Unicode wrote: > On Thu, Sep 26, 2019 at 8:57 PM Fred Brennan via Unicode > wrote: [snip] >> There is no sequence of glyphs that could be logically mapped, unless you're >> telling me to request that the sequence T B be recommended for ge

Re: On the lack of a SQUARE TB glyph

On Thu, Sep 26, 2019 at 8:57 PM Fred Brennan via Unicode wrote: > The purpose of Unicode is plaintext encoding, is it not? The square TB form is > fundamentally no different than the square form of Reiwa, U+32FF ㋿, which was > added in a hurry. The difference is that SQUARE TB's nec

Re: On the lack of a SQUARE TB glyph

On 2019-09-27 5:15 AM, Fred Brennan via Unicode wrote: I only have two lingering questions. * Does the existence of the legacy Adobe encoding Adobe-Japan1-6 shift the balance? It has a SQUARE TB at CID+8306. https://www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5078.Adobe-Japan1-6.pdf

Re: On the lack of a SQUARE TB glyph

I'm sorry to write twice to the list but after some discussion on Twitter it is certain I'm going to write a request. I only have two lingering questions. * Does the existence of the legacy Adobe encoding Adobe-Japan1-6 shift the balance? It has a SQUARE TB at CID+8306. https://www.adobe.com/

Re: On the lack of a SQUARE TB glyph

On Friday, September 27, 2019 3:56:39 AM PST Ken Whistler wrote: > On 9/26/2019 4:21 AM, Fred Brennan via Unicode wrote: > > There is a clear demand for a SQUARE TB. In the font SMotoya Sinkai W55 > > W3, > > which is ©2008 株式会社 モトヤ, the glyph is unencoded and accessed via

Re: On the lack of a SQUARE TB glyph

On 9/26/2019 4:21 AM, Fred Brennan via Unicode wrote: There is a clear demand for a SQUARE TB. In the font SMotoya Sinkai W55 W3, which is ©2008 株式会社 モトヤ, the glyph is unencoded and accessed via the Discretionary Ligatures (`dlig`) OpenType feature. It has name `T_B.dlig`. Aye, there'

Re: On the lack of a SQUARE TB glyph

Fred Brennan wrote: > I can't help but notice that there is no "SQUARE TB" glyph. Marius Spix replied: > Unfortunately, the CJK Compatibility block is full, but U+321F in the > Enclosed CJK Letters and Months seems to be free. I definitely see a usage > for the proposed character. IIRC th

Aw: On the lack of a SQUARE TB glyph

Unfortunately, the CJK Compatibility block is full, but U+321F in the Enclosed CJK Letters and Months seems to be free. I definitely see a usage for the proposed character.   Gesendet: Donnerstag, 26. September 2019 um 13:21 Uhr Von: "Fred Brennan via Unicode" An: unicode@unicode.o

On the lack of a SQUARE TB glyph

Greetings, I can't help but notice that there is no "SQUARE TB" glyph. We have SQUARE KB, GB and MB, starting at U+3385. But no SQUARE TB? SQUARE GB is at U+3387, and U+3388 is...SQUARE CAL, ㎈, so no space was even left for it—not very future-proof! The purposes of these glyphs is, as you know

QID emoji and screen readers

There is currently a Public Review, number 405. http://www.unicode.org/review/pri405/ It is about the following document. http://www.unicode.org/reports/tr51/tr51-17.html The issue of screen readers is mentioned in the document. I have thought of a possible solution. However I am not expert

Re: Proposing mostly invisible characters

On 9/13/2019 10:50 AM, Richard Wordingham via Unicode wrote: On Fri, 13 Sep 2019 08:56:02 +0300 Henri Sivonen via Unicode wrote: On Thu, Sep 12, 2019, 15:53 Christoph Päper via Unicode wrote: ISHY/SIHY is especially useful

Re: Proposing mostly invisible characters

On Fri, 13 Sep 2019 08:56:02 +0300 Henri Sivonen via Unicode wrote: > On Thu, Sep 12, 2019, 15:53 Christoph Päper via Unicode > wrote: > > > ISHY/SIHY is especially useful for encoding (German) noun compounds > > in wrapped titles, e.g. on product labeling, wh

Re: Proposing mostly invisible characters

On 9/12/2019 5:53 AM, Christoph Päper via Unicode wrote: ISHY/SIHY is especially useful for encoding (German) noun compounds in wrapped titles, e.g. on product labeling, where hyphens are often suppressed for stylistic reasons, e.g. orthographically correct

Re: Proposing mostly invisible characters

, that there are instances where this is not desired. Am 13. Sep. 2019, 07:59, um 07:59, Henri Sivonen via Unicode schrieb: >On Thu, Sep 12, 2019, 15:53 Christoph Päper via Unicode > >wrote: > >> ISHY/SIHY is especially useful for encoding (German) noun compounds >in >&g

Re: The native name of Tai Viet script and language(s)

> Cc: unicode@unicode.org > From: r12a > Date: Thu, 12 Sep 2019 14:34:11 +0100 > > On 27/08/2019 07:33, Eli Zaretskii via Unicode wrote: > > Yes, it's an old and outdated text (Emacs is around since 1985, and > > supports multilingual text editing since 1997). Ea

Re: Proposing mostly invisible characters

On Thu, Sep 12, 2019, 15:53 Christoph Päper via Unicode wrote: > ISHY/SIHY is especially useful for encoding (German) noun compounds in > wrapped titles, e.g. on product labeling, where hyphens are often > suppressed for stylistic reasons, e.g. orthographically correct > _Spargelsupp

Re: Proposing mostly invisible characters

On Thu, 12 Sep 2019 14:53:45 +0200 (CEST) Christoph Päper via Unicode wrote: > Dear Unicoders > > There are some characters that have no precedent in existing > encodings and are also hard to attest directly from printed sources. > Can one still make a solid case for encoding t

Re: The native name of Tai Viet script and language(s)

On 27/08/2019 07:33, Eli Zaretskii via Unicode wrote: Yes, it's an old and outdated text (Emacs is around since 1985, and supports multilingual text editing since 1997). Easy to fix, and I will fix it, but my main difficulty is with the text that uses the script itself, which is why I

Proposing mostly invisible characters

Dear Unicoders There are some characters that have no precedent in existing encodings and are also hard to attest directly from printed sources. Can one still make a solid case for encoding those in Unicode? I am thinking of characters that are either invisible (most of the time) or can becom

Re: LDML Keyboard Descriptions and Normalisation

On Sat, 7 Sep 2019 20:41:34 +0100 Richard Wordingham via Unicode wrote: > I don't think the model will run with Python Version 2.7. I was wrong. It does run under Version 2.7. Richard.

Re: LDML Keyboard Descriptions and Normalisation

On Sat, 7 Sep 2019 20:02:09 +0100 Cibu via Unicode wrote: > Slightly off topic: Is there a CLDR tool to try out transformations > specified in a keyboard spec? No CLDR tool, or so far as I am aware, CLDR-endorsed tool. Martin Hoksen has put together a reference model in Python at

Re: LDML Keyboard Descriptions and Normalisation

Slightly off topic: Is there a CLDR tool to try out transformations specified in a keyboard spec? On Sat, Sep 7, 2019 at 7:54 PM Richard Wordingham via Unicode < unicode@unicode.org> wrote: > On Tue, 3 Sep 2019 18:03:18 + > Andrew Glass via Unicode wrote: > > > Hi Richa

Re: LDML Keyboard Descriptions and Normalisation

On Tue, 3 Sep 2019 18:03:18 + Andrew Glass via Unicode wrote: > Hi Richard, > > This is a good point. A keyboard that is doing transforms should > specify which type of normalization it has been designed to do. I've > filed a ticket to track this. The ticke

RE: LDML Keyboard Descriptions and Normalisation

Hi Richard, This is a good point. A keyboard that is doing transforms should specify which type of normalization it has been designed to do. I've filed a ticket to track this. Cheers, Andrew -Original Message- From: Unicode On Behalf Of Richard Wordingham via Unicode Sen

LDML Keyboard Descriptions and Normalisation

I'm getting conflicting indications about how the LDML keyboard description handles issues of canonical equivalence. I have one simple question which some people may be able to answer. Is the keyboard specification intended to distinguish between keyboards that generally output: (a) NFC text; (b

Re: The native name of Tai Viet script and language(s)

> Date: Tue, 27 Aug 2019 08:33:21 +0100 > From: Richard Wordingham via Unicode > > @Eli: Ideally, you need to check that default font and language are > consistent. There are some regional differences which make it > necessary to calibrate the writing system, and one wo

Re: The native name of Tai Viet script and language(s)

On Tue, 27 Aug 2019 04:56:35 + Peter Constable via Unicode wrote: > The script _is_ related to Thai script, but I’m not sure I would say > it has “the same origin as that of Thai language/script used in > Thailand”, as that is too simplistic a view of the historic > connections:

Re: The native name of Tai Viet script and language(s)

> From: Peter Constable > Date: Tue, 27 Aug 2019 04:56:35 + > > " As the proposal for TaiViet script to the Unicode is still on > the progress, we use the Private Use Area for TaiViet > characters (U+F000..U+F07E). " > > Er... The script has been in Unicode for about 10 years, since Unicode

RE: The native name of Tai Viet script and language(s)

ish, Italian, etc. are closely-related to one another). For more on the Southwestern Tai languages, see https://www.ethnologue.com/subgroups/southwestern. Hope that’s of some help. Peter -Original Message- From: Unicode On Behalf Of Eli Zaretskii via Unicode Sent: Thursd

Tai Laing JHA and SA

Hi, I was looking at UTN 11 and it seems both JHA and SA in Tai Laing is supposed to be represented by U+A9EC. Am I reading it correctly? Or is it a mistake in the consonant table? L2/11-130R (page 7) also seems to show the same character for JHA and SA. I find it a bit strange that an alphabet

Re: Want to be individual member

You may join by following instructions on this page: https://www.unicode.org/consortium/joinform.html Please let me know if you have any other questions. Ellen Mastros Office Manager Unicode Inc. PO Box 391476 Mountain View, CA 94039 (408)401-8915 You can support us whenever you shop at Amazon.c

The native name of Tai Viet script and language(s)

Could someone "in the know" please help me make the Tai Viet script documentation in Emacs accurate? The current short description we have is in the file lisp/language/tai-viet.el in the Emacs source tree. You can see it here: http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/language/tai-v

Re: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

On Tue, 20 Aug 2019 22:43:43 + Andrew Glass via Unicode wrote: > The order of medials in Myanmar clusters is constrained by UTN > #11<http://www.unicode.org/notes/tn11/>. So yes, you do need to > follow the preferred order for Myanmar even if the sequence does not > match p

RE: PUA (BMP) planned characters HTML tables

On August 11, I replied to Robert Wheelock: >> I remember that a website that has tables for certain PUA precomposed >> accented characters that aren’t yet in Unicode (thing like: >> Marshallese M/m-cedilla, H/h-acute, capital T-dieresis, capital H- >> underbar, acute accented Cyrillic vowels, Cy

Re: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

On Wed, 21 Aug 2019 02:47:28 + James Kass via Unicode wrote: > > Are we are allowed to write Llangollen as the definition of the > > Unicode Collation Algorithm implies we should, with an invisible CGJ > > between the 'n' and the 'g', so that it will col

Re: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

On Wed, 21 Aug 2019 02:40:09 + James Kass via Unicode wrote: > On 2019-08-21 2:08 AM, Richard Wordingham via Unicode wrote: > > Are we are allowed to write Llangollen as the definition of the > > Unicode Collation Algorithm implies we should, with an invisible CGJ > > be

Re: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

Well, it was intended to be off list.  It seems that this has been mentioned before, for example; http://www.unicode.org/mail-arch/unicode-ml/y2011-m07/0029.html Maybe it's time for a new thread/subject title?

Re: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

On 2019-08-21 2:40 AM, James Kass wrote: Are we are allowed to write Llangollen as the definition of the Unicode Collation Algorithm implies we should, with an invisible CGJ between the 'n' and the 'g', so that it will collate correctly in Welsh?  That CGJ is necessary so that it will collate*

Re: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

On 2019-08-21 2:08 AM, Richard Wordingham via Unicode wrote: Are we are allowed to write Llangollen as the definition of the Unicode Collation Algorithm implies we should, with an invisible CGJ between the 'n' and the 'g', so that it will collate correctly in Welsh? That

Re: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

On Tue, 20 Aug 2019 22:43:43 + Andrew Glass via Unicode wrote: > The order of medials in Myanmar clusters is constrained by UTN > #11<http://www.unicode.org/notes/tn11/>. So yes, you do need to > follow the preferred order for Myanmar even if the sequence does not > ma

Re: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

es, you do need to follow the > preferred order for Myanmar even if the sequence does not match phonetic > order. > > > > > > > Cheers, > > > > Andrew > > > > *From:* Unicode *On Behalf Of *Vinodh Rajan > via Unicode > *Sent:* 20 August 2019 15:29 &

RE: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

visual output you were expecting? Cheers, Andrew From: Unicode On Behalf Of Vinodh Rajan via Unicode Sent: 20 August 2019 15:29 To: Unicode Mailing List Subject: Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar Hi, I was wondering how to encode the Sanskrit medial sequences -vy

Rendering Sanskrit Medial Sequences -vy- and -ry- in Myanmar

Hi, I was wondering how to encode the Sanskrit medial sequences -vy - and -ry- in Myanmar as they occur in Sanskrit syllables such as dvya and trya regularly. I tried to encode the above as ဒွျ (Cons U+103D U+103B) and ဒြျ (Cons U+103C U+103B) but all rendering engines insert a dotted circle befo

Re: Acute/apostrophe diacritic in Võro for palatalized consonants

I must add that the current version of Wikipedia in Võro, seems to have completely renounced to encode this combining mark (no acute, no apostrophe), probably because of lack of proper encoding in Unicode and difficulty to harmonize its orthography. It may be a good argument for the addition of th

Re: PUA (BMP) planned characters HTML tables

On 8/14/2019 7:49 PM, James Kass via Unicode wrote: On 2019-08-15 12:25 AM, Asmus Freytag via Unicode wrote: Empirically, it has been observed that some distinctions that are claimed by users, standards developers or

Re: PUA (BMP) planned characters HTML tables

On Wed, 14 Aug 2019 23:32:37 + James Kass via Unicode wrote: > U+0149 has a compatibility decomposition.  It has been deprecated and > is not rendered identically on my system. > 'n ʼn > ( ’n ) Compatibility decompositions are quite a mix, but are generally expected to r

Re: PUA (BMP) planned characters HTML tables

On 2019-08-15 12:25 AM, Asmus Freytag via Unicode wrote: Empirically, it has been observed that some distinctions that are claimed by users, standards developers or implementers were de-facto not honored by type developers (and users selecting fonts) as long as the native text doesn't co

Re: PUA (BMP) planned characters HTML tables

On 8/14/2019 2:05 AM, James Kass via Unicode wrote: This presumes that the premise of user communities feeling strongly about the unacceptable aspect of the variants is valid.  Since it has been reported and nothing seems to be happening, perhaps the

Re: PUA (BMP) planned characters HTML tables

On 8/14/2019 4:32 PM, James Kass via Unicode wrote: If a character gets deprecated, can its decomposition type be changed from canonical to compatibility? Simple answer: No. --Ken

Re: PUA (BMP) planned characters HTML tables

On 2019-08-14 7:50 PM, Richard Wordingham via Unicode wrote: I think you'd also have to change the reference glyph of LATIN LOWER CASE I WITH HEART to show a heart. That's valid because the UCD trumps the code charts, and and no Unicode-compliant process may deliberately render d

Re: PUA (BMP) planned characters HTML tables

On Wed, 14 Aug 2019 09:05:02 + James Kass via Unicode wrote: > The solution is to deprecate "LATIN LOWER CASE I WITH HEART".  It's > only in there because of legacy.  It's presence guarantees > round-tripping with legacy data but it isn't needed for modern d

Re: PUA (BMP) planned characters HTML tables

On 2019-08-12 8:30 AM, Andrew West wrote: This issue was discussed at WG2 in 2013 (https://www.unicode.org/L2/L2013/13128-latvian-marshal-adhoc.pdf), when there was a recommendation to encode precomposed letters L and N with cedilla*with no decomposition*, but that solution does not seem to hav

Unihan kJapaneseKun Error Report [Follow-up: Fixed wrong URL]

Follow-up: [Fixed wrong URL] I have uploaded on the dedicated GitHub repository a draft version of a document called "Unihan kJapaneseKun Error Report" available both in Markdown and HTML format, which is a list of corrections o

Unihan kJapaneseKun Error Report

I have uploaded on the dedicated GitHub repository GitHub repository a draft version of a document called "Unihan kJapaneseKun Error Report" available both in Markdo

Re: PUA (BMP) planned characters HTML tables

On Mon, 12 Aug 2019 at 02:27, James Kass via Unicode wrote: > > On 2019-08-11 5:26 PM, [ Doug Ewell ] via Unicode wrote: > > If you are thinking of these as potential future additions to the standard, > > keep in mind that accented letters that can already be represented by a

Re: PUA (BMP) planned characters HTML tables

On Mon, 12 Aug 2019 01:21:42 + James Kass via Unicode wrote: > There was a time when populating the PUA with precomposed glyphs was > necessary for printing or display, but that time has passed. There is still the issue that in pure X one can't put sequences of characters on a

Re: PUA (BMP) planned characters HTML tables

On 2019-08-11 5:26 PM, [ Doug Ewell ] via Unicode wrote: If you are thinking of these as potential future additions to the standard, keep in mind that accented letters that can already be represented by a combination of letter + accent will not ever be encoded. This is one of the longest

RE: PUA (BMP) planned characters HTML tables

Robert Wheelock wrote: > I remember that a website that has tables for certain PUA precomposed > accented characters that aren’t yet in Unicode (thing like: > Marshallese M/m-cedilla, H/h-acute, capital T-dieresis, capital H- > underbar, acute accented Cyrillic vowels, Cyrillic ER/er-caron, ...).

Re: PUA (BMP) planned characters HTML tables

On 2019-08-11 4:07 AM, Robert Wheelock via Unicode wrote: Hello! I remember that a website that has tables for certain PUA precomposed accented characters that aren’t yet in Unicode (thing like: Marshallese M/m-cedilla, H/h-acute, capital T-dieresis, capital H-underbar, acute accented

Re: PUA (BMP) planned characters HTML tables

On Sun, 11 Aug 2019 00:07:05 -0400 Robert Wheelock via Unicode wrote: > I remember that a website that has tables for certain PUA precomposed > accented characters that aren’t yet in Unicode (thing like: > Marshallese M/m-cedilla, H/h-acute, capital T-dieresis, capital > H-und

RE: PUA (BMP) planned characters HTML tables

Hello! I remember that a website that has tables for certain PUA precomposed accented characters that aren’t yet in Unicode (thing like: Marshallese M/m-cedilla, H/h-acute, capital T-dieresis, capital H-underbar, acute accented Cyrillic vowels, Cyrillic ER/er-caron, ...). Where was it at?! I sti

Re: Fonts and Canonical Equivalence

On Sat, 10 Aug 2019 16:37:48 +0100 Andrew West via Unicode wrote: > On Sat, 10 Aug 2019 at 15:46, Richard Wordingham via Unicode > wrote: > > Does vowel above before vowel below yield a dotted circle? > > Yes. Attached are screenshots for two real world examples, one wh

Re: Fonts and Canonical Equivalence

On Sat, 10 Aug 2019 at 15:46, Richard Wordingham via Unicode wrote: > > > Just retested on Windows 10 with > > a Tibetan font that supports both sequences of vowels, and both > > sequences display correctly under Harfbuzz (as expected), but only > > vowel-below follo

Re: Fonts and Canonical Equivalence

On Sat, 10 Aug 2019 11:22:01 +0100 Andrew West via Unicode wrote: > On Sat, 10 Aug 2019 at 08:29, Richard Wordingham via Unicode > wrote: > > > > There are similar issues with Tibetan; some fonts do not work > > properly if a vowel below (ccc=132) is separated from the b

Re: Fonts and Canonical Equivalence

On Sat, 10 Aug 2019 at 08:29, Richard Wordingham via Unicode wrote: > > There are similar issues with Tibetan; some fonts do not work properly > if a vowel below (ccc=132) is separated from the base of the > consonant stack by a vowel above (ccc=130). It's not that the fonts

Fonts and Canonical Equivalence

I've spun this question off from the issue of what the USE is to do when confronted with the NFC canonical equivalent of a string it will accept when this equivalent does not match its regular expressions when they are applied to strings of characters rather than canonical equivalence classes of st

Re: What is the time frame for USE shapers to provide support for CV+C ?

On Thu, 8 Aug 2019 00:33:47 + Andrew Glass via Unicode wrote: > I agree and understand that accurate representation is important in > this case. It would be good to understand how widespread the issue is > in order to begin to justify the work to retrofit shaping with > normal

Re: What is the time frame for USE shapers to provide support for CV+C ?

On 8/8/2019 1:06 AM, Richard Wordingham via Unicode wrote: This is not compliant with Unicode, but neither is deliberately treating canonically equivalent forms differently. That. A./

Re: What is the time frame for USE shapers to provide support for CV+C ?

On Wed, 7 Aug 2019 14:19:26 -0700 Asmus Freytag via Unicode wrote: > What about text that must exist normalized for other purposes? > > Domain names must be normalized to NFC, for example. Will such > strings display correctly if passed to USE? One solution, of course, is to mini

Re: What is the time frame for USE shapers to provide support for CV+C ?

On 8/7/2019 5:33 PM, Andrew Glass via Unicode wrote: I agree and understand that accurate representation is important in this case. It would be good to understand how widespread the issue is in order to begin

RE: What is the time frame for USE shapers to provide support for CV+C ?

t the string can no longer be rendered correctly. In particular, as the strings in question would be identifiers, where accurate recognition is prime. A./ From: Unicode <mailto:unicode-boun...@unicode.org> On Behalf Of Asmus Freytag via Unicode Sent: 07 August 2019 14:19 To: unicode@

Re: What is the time frame for USE shapers to provide support for CV+C ?

ar un-normalized state would be lost; and therefore it would be bad if the result is that the string can no longer be rendered correctly. In particular, as the strings in question would be identifiers, where accurate recognition is prime. A./ *From:*Unicode *On Behalf Of *Asmus Freytag via Un

RE: What is the time frame for USE shapers to provide support for CV+C ?

Shaping domain names is a new requirement. It would be good to understand the specific cases that are falling in the gap here. From: Unicode On Behalf Of Asmus Freytag via Unicode Sent: 07 August 2019 14:19 To: unicode@unicode.org Subject: Re: What is the time frame for USE shapers to provide

Re: What is the time frame for USE shapers to provide support for CV+C ?

What about text that must exist normalized for other purposes? Domain names must be normalized to NFC, for example. Will such strings display correctly if passed to USE? A./ On 8/7/2019 1:39 PM, Andrew Glass via Unicode

RE: What is the time frame for USE shapers to provide support for CV+C ?

n the changes required to support Tai Tham in USE. Therefore, I've not been able to make the changes proposed in this thread. Cheers, Andrew -Original Message- From: Richard Wordingham Sent: 07 August 2019 13:29 To: Richard Wordingham via Unicode Cc: Andrew Glass Subject: Re: W

Re: What is the time frame for USE shapers to provide support for CV+C ?

On Tue, 14 May 2019 03:08:04 +0100 Richard Wordingham via Unicode wrote: > On Tue, 14 May 2019 00:58:07 + > Andrew Glass via Unicode wrote: > > > Here is the essence of the initial changes needed to support CV+C. > > Open to feedback. > > > > > >

Re: SHEQEL and L2/19-291

to be transcribed by K, but in the official rules for "precise transcription" Q is still used. See https://hebrew-academy.org.il/%D7%9B%D7%9C%D7%9C%D7%99-%D7%94%D7%AA%D7%A2%D7%AA%D7%99%D7%A7/ (Hebrew) On 25.7.2019 5:23, Mark E. Shoulson via Unicode wrote: Just looking at document L2/19-

Re: SHEQEL and L2/19-291

qalim (from שְׁקָלִים‎).[31]" BTW, Google flags "sheqel" in its search box as an incorrect spelling. On 2019-07-25 2:23 AM, Mark E. Shoulson via Unicode wrote: Just looking at document L2/19-291, https://www.unicode.org/L2/L2019/19291-missing-currency.pdf "Currency signs missi

SHEQEL and L2/19-291

Just looking at document L2/19-291, https://www.unicode.org/L2/L2019/19291-missing-currency.pdf "Currency signs missing in Unicode" by Eduardo Marín Silva.  And I'm wondering why he feels it necessary for the Unicode standard to say that a more correct spelling fo

Re: Akkha script (used by Eastern Magar language) in ISO 15924?

> On Jul 23, 2019, at 12:26 AM, Richard Wordingham via Unicode > wrote: > > On Mon, 22 Jul 2019 17:42:37 -0700 > Anshuman Pandey via Unicode wrote: > >> As I pointed out in L2/11-144, the “Magar Akkha” script is an >> appropriation of Brahmi, renamed t

Re: Akkha script (used by Eastern Magar language) in ISO 15924?

On Mon, 22 Jul 2019 17:42:37 -0700 Anshuman Pandey via Unicode wrote: > As I pointed out in L2/11-144, the “Magar Akkha” script is an > appropriation of Brahmi, renamed to link it to the primordialist > daydreams of an ethno-linguistic community in Nepal. I have never > seen actual

Re: Akkha script (used by Eastern Magar language) in ISO 15924?

nce 2011, I would very > much welcome such information. Otherwise, the so-called “Magar Akkha” is > not suitable for encoding. The Brahmi encoding that we have should suffice. > > All my best, > Anshu > > On Jul 22, 2019, at 10:06 AM, Lorna Evans via Unicode > wrote: > > Also

Re: Akkha script (used by Eastern Magar language) in ISO 15924?

welcome such information. Otherwise, the so-called “Magar Akkha” is not suitable for encoding. The Brahmi encoding that we have should suffice. All my best, Anshu > On Jul 22, 2019, at 10:06 AM, Lorna Evans via Unicode > wrote: > > Also: https://scriptsource.org/scr/Qabl > >

Re: New website

On 7/22/2019 10:00 AM, Ken Whistler via Unicode wrote: Your helpful suggestions will be passed along to the people working on the new site. In the meantime, please note that the link to the "Unicode Technical Site" has bee

Re: Akkha script (used by Eastern Magar language) in ISO 15924?

Also we can note that "mgp" (Eastern Magari) is severely endangered according to multiple sources include Ethnologue and the Linguist List. This is still not the case for Western Magari (mostly on Nepal, not in Sikkim India), where evidence is probably easier to find (where the encoding of a new sc

Re: Akkha script (used by Eastern Magar language) in ISO 15924?

Le lun. 22 juil. 2019 à 18:43, Ken Whistler a écrit : > See the entry for "Magar Akkha" on: > > http://linguistics.berkeley.edu/sei/scripts-not-encoded.html > > Anshuman Pandey did preliminary research on this in 2011. > That's what I said: 8 years ago already. > http://www.unicode.org/L2/L201

Re: Akkha script (used by Eastern Magar language) in ISO 15924?

Also: https://scriptsource.org/scr/Qabl On Mon, Jul 22, 2019, 12:47 PM Ken Whistler via Unicode wrote: > See the entry for "Magar Akkha" on: > > http://linguistics.berkeley.edu/sei/scripts-not-encoded.html > > Anshuman Pandey did preliminary research on this in 2011. &

Re: New website

Your helpful suggestions will be passed along to the people working on the new site. In the meantime, please note that the link to the "Unicode Technical Site" has been added to the left column of quick links in the page bottom banner, so it is easily available now from any page on the new sit

Re: Akkha script (used by Eastern Magar language) in ISO 15924?

esearch to determine whether this script should be separately encoded. --Ken On 7/22/2019 9:16 AM, Philippe Verdy via Unicode wrote: According to Ethnolog, the Eastern Magar language (mgp) is written in two scripts: Devanagari and "Akkha". But the "Akkha" script does not s

Re: Displaying Lines of Text as Line-Broken by a Human

On Sun, 21 Jul 2019 20:53:19 -0700 Asmus Freytag via Unicode wrote: > There's really no inherent need for many spacing combining marks to > have a base character. At least the ones that do not reorder and that > don't overhang the base character's glyph. We are in agreem

<    1   2   3   4   5   6   7   8   9   10   >