Subject: Re: [precis] U+1E9B

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Aug 2014 13:41:22 -0600

On 7/30/14, 12:56 PM, Joe Hildebrand (jhildebr) wrote:
> I get FREE_PVAL instead of PVALID as is in the table in precis-framework.
> I think this is because I was following the letter of section 7.17
> HasCompat (Q), which says:
>
> Q: toNFKC(cp) != cp
>
>
> If you just look at the decomposition for U+1E9B, you see that it has a
> canonical decomposition.  However, one of *those* codepoints  has a
> compatible decomposition,

Right, U+017F has a compatibility decomposition to U+0073.

> so NFKC(U+1E98) is U+1E61, which doesn't match
> U+1E98 (note: NFC(U+1E98) = U+1E98 for the pre-input transform).

s/8/B in the foregoing paragraph.

My Python code didn't account for these chains of decomposition, but 
Nemo's Ruby code did. I haven't had time to update my code, but I did 
attempt to correct the tables based on Nemo's code. I might have missed 
a few code points along the way.

> This brings up another point with rule Q; I hope it gets the same results
> if the input was NFD'd instead of NFC'd.  I think it should but I haven't
> run the numbers to prove it.

I haven't, either.

This brings up another point: it probably makes sense to delete the 
codepoint table from the precis-framework specification and to create 
the initial registration in a better way (see discussion in other 
threads). It was helpful scaffolding, but probably has outlived its 
usefulness.

Peter