"Adam M. Costello" <[EMAIL PROTECTED]> writes: > An approach that would really avoid this pitfall would be to deprecate > these characters not only in Unicode, but also in CNS 11643 and any > other character sets that contain them, and create new characters > in all these character sets, and leave all the mappings of the old > deprecated characters unchanged in both the Unicode database and the > WhateverToUnicode tables.
That, of course, defeats the purpose of compatibility characters in the first place. It is my understanding that CNS 11643 contains characters that are really duplicates of each other, in different planes (of CNS 11643). The duplicates originate from creating the standard from different sources, and not applying a unification procedure. When integrating them to Unicode, the unification procedure found out that they are duplicates, and added the compatibility characters for round-tripping. [Somebody please correct me if this report on the history is incorrect] Now, if changing CNS 11643 was an option, you could have just deprecated the duplicate characters in that standard. Regards, Martin
