On 7/30/14, 1:13 PM, Joe Hildebrand (jhildebr) wrote:
This is the last of these messages. I split them up because they were
different issues.
With my code, I get different answers than the table for the following
code points:
U+1f18: PVALID != FREE_PVAL
U+1f19: PVALID != FREE_PVAL
U+1f1a: PVALID != FREE_PVAL
U+1f1b: PVALID != FREE_PVAL
U+1f1c: PVALID != FREE_PVAL
U+1f1d: PVALID != FREE_PVAL
U+1f48: PVALID != FREE_PVAL
U+1f49: PVALID != FREE_PVAL
U+1f4a: PVALID != FREE_PVAL
U+1f4b: PVALID != FREE_PVAL
U+1f4c: PVALID != FREE_PVAL
U+1f4d: PVALID != FREE_PVAL
U+1ff2: PVALID != FREE_PVAL
U+1ff3: PVALID != FREE_PVAL
U+1ff4: PVALID != FREE_PVAL
U+2126: PVALID != FREE_PVAL
They all look genuinely PVALID to me because they're all in LetterDigit.
Most of them are category Lu, and a few are Ll. To get FREE_PVAL, I think
they would have had to show up as having a compatibility mapping, since
that's the only context-specific rule before the LetterDigit check. I'm
not sure how that would have happened.
I'm not sure, either. Your analysis looks correct.
Peter
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
