From: Asmus Freytag (firstname.lastname@example.org)
Date: Mon Nov 15 2010 - 17:02:53 CST
On 11/15/2010 2:24 PM, Kenneth Whistler wrote:
>> FA47 is a "compatibility character", and would have a compatibility mapping.
> Faulty syllogism.
Formally correct answer but only because of something of a design flaw
in Unicode. When the type of mapping was decided on, people didn't fully
expect that NFC might become widely used/enforced, making these
distinctions appear wherever text is normalized in a distributed
> FA47 is a CJK Compatibility character, which means it was encoded
> for compatibility purposes -- in this case to cover the round-trip
> mapping needed for JIS X 0213.
> However, it has a *canonical* decomposition mapping to U+6F22.
And that, of course, destroys the desired "round-trip" behavior if it is
inadvertently applied while the data are encoded in Unicode. Hence the
need to recreate a solution to the issue of variant forms with a
different mechanism, the ideographic variation sequence (and
> The behavior in BabelPad is correct: U+6F22 is the NFC form of U+FA47.
> Easily verified, for example, by checking the FA47 entry in
> NormalizationTest.txt in the UCD.
While correct, it's something that remains a bit of a gotcha. Especially
now that Unicode has charts that go to great length showing the
different glyphs for these characters, I would suggest adding a note to
the charts that make clear that these distinctions are *removed* anytime
the text is normalized, which, in a distributed architecture may happen
>>> When I type ... (U+FA47) into BabelPad, highlight it, and then
>>> click the button labeled "Normalize to NFC", the character
>>> becomes ... (U+6F22). Does BabelPad not conform to the Unicode Standard
>>> in this case? ...
This archive was generated by hypermail 2.1.5 : Mon Nov 15 2010 - 17:05:20 CST