What is the time frame for USE shapers to provide support for CV+C ?
Andrew Glass via Unicode
unicode at unicode.org
Wed Aug 7 15:39:15 CDT 2019
That's correct, the Microsoft implementation of USE spec does not normalize as part of the shaping process.
Why? Because the ccc system for non-Latin scripts is not a good mechanism for handling complex requirements for these writing systems and the effects of ccc-based normalization can disrupt authors intent. Unfortunately, because we cannot fix ccc values, shaping engines at Microsoft have ignored them. Therefore, recommendation for passing text to USE is to not normalize.
By the way, at the current time, I do not have a final consensus from Tai Tham experts and community on the changes required to support Tai Tham in USE. Therefore, I've not been able to make the changes proposed in this thread.
From: Richard Wordingham <richard.wordingham at ntlworld.com>
Sent: 07 August 2019 13:29
To: Richard Wordingham via Unicode <unicode at unicode.org>
Cc: Andrew Glass <Andrew.Glass at microsoft.com>
Subject: 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 <unicode at unicode.org> wrote:
> On Tue, 14 May 2019 00:58:07 +0000
> Andrew Glass via Unicode <unicode at unicode.org> wrote:
> > Here is the essence of the initial changes needed to support CV+C.
> > Open to feedback.
> > * Create new SAKOT class
> > SAKOT (Sk) based on UISC = Invisible_Stacker
> > * Reduced HALANT class
> > Now only HALANT (H) based on UISC = Virama
> > * Updated Standard cluster mode
> > [< R | CS >] < B | GB > [VS] (CMAbv)* (CMBlw)* (< < H | Sk > B | SUB
> > > [VS] (CMAbv)* (CMBlw)*)* [MPre] [MAbv] [MBlw] [MPst] (VPre)*
> > > (VAbv)* (VBlw)* (VPst)* (VMPre)* (VMAbv)* (VMBlw)* (VMPst)* (Sk
> > > B)* (FAbv)* (FBlw)* (FPst)* [FM]
> This next question does not, I believe, affect HarfBuzz. Will NFC
> code render as well as unnormalised code? In the first example above,
> <TONE-2, SAKOT, LOW YA> normalises to <SAKOT, TONE-2, LOW YA>, which
> does not match any portion of the regular expression.
Could someone answer this question, please? The USE documentation ("CGJ handling will need to be updated if USE is modified to support
normalization") still implies that the USE does not respect canonical equivalence.
More information about the Unicode