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
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
