Article View: comp.std.internat
Article #1042Re: Unicode -> JIS,GB,CNS tables
From: John H. Jenkins
Date: Mon, 28 Aug 1995 00:00
Date: Mon, 28 Aug 1995 00:00
89 lines
4896 bytes
4896 bytes
In article <41edvt$a0a@kudpc.kudpc.kyoto-u.ac.jp>, yasuoka@kudpc.kyoto-u.ac.jp (Koichi Yasuoka) wrote: > In article <John_Jenkins-1408951759010001@tseng.taligent.com> > John_Jenkins@taligent.com (John H. Jenkins) writes: > >Please be aware that the Han ideographic portion of ISO/IEC 10646 (and > >hence Unicode) is formally defined via mapping tables, and *NOT* by visual > >appearance. > > Oh, really? Unicode Standard Book says that "Only characters that > have the same abstract shape (occupy a single point on the Y-axis) > are potential candidates for unification." So I pointed out them > as bugs. > [specific example left out] There are actually two issues here: 1) Is the unification incorrect? So far, all the points where people have claimed an error occurred in the course of Han unification have boiled down to the same basic cause -- the mainland Chinese have not always printed characters consistently with the same glyphs. In particular, the copies of their own standards they prepared for use by the CJK-JRG in developing the URO often differ from the regular printed copies of their standards. And to be frank, I have the feeling that some people have copies of GB 12345 which were printed with "simplified" fonts and not "traditional" ones. (This isn't to say that there aren't errors in the unification lurking about that nobody's pointed out yet -- just that nobody's pointed them out. Given, however, the massive international work that went into the unification in the first place, it's pretty darn unlikely IMHO that any significant errors are to be found.) In this particular case, our printed copy of GB 12345 uses a different shape for 53-89 than yours. The shape in our copy matches that of 0x4E68 of the 1st plane of CNS11643-1986, 60-27 of JIS X 0208-1990, and 78-19 of KS C 5601-1987. Our copy is the one specifically prepared by the mainland Chinese for the use in the Han unification work done by the CJK-JRG. That is, it was mainland China who decided that GB2312 53-89 and GB12345 53-89 are distinct. Moreover, the intended semantics of code points in GB 12345 is to represent the "traditional" forms for the characters in GB 2312. That is definitely the case in the example you cited, and the version in your printed copy of GB 12345 could be interpreted as a typographical error. Clearly the mainland Chinese themselves in their work with the CJK-JRG interpret it so. There are other instances which have been pointed out to us where mainland China used a traditional form in the material submitted to the CJK-JRG but a simplified form in their own published version of the standard. In these cases, we take the mainland Chinese at their word when they tell us that their intent was to represent the traditional form. 2) Is the mapping incorrect? No. So far as ISO is concerned, these characters are defined by their mappings. The mappings cannot therefore be wrong. They may conceivably represent errors in unification (although I have yet to have an example of that convincingly pointed out), but they cannot be mapping errors. To change the mapping is to create non-compliance with 10646. From ISO's perspective, it doesn't matter if the unification were correct or incorrect. The current version of 10646 uses a particular mapping to define its characters. U+722D is defined to be the target mapping for GB 12345 53-89. Even if GB 12345 53-89 were incorrectly unified (which isn't the case), the mapping would have to stand. (Unicode probably wouldn't be so hard-nosed about it, but the same basic principle applies: the contents of the unified Han set are defined primarily by their mappings, not their appearance.) > Here I find that 53-89 of GB2312-80 and 53-89 of GB/T12345-90 have the > similar shape. Why are they distinguished? Isn't it really a bug? > Again, the short answer -- they're distinguished because the mainland Chinese asserted they were distinct. It isn't a bug. -- John H. Jenkins John_Jenkins@taligent.com
Technical Details
Message-ID:
<John_Jenkins-2808951215260001@tseng.taligent.com>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<John_Jenkins-0708951003580001@tseng.taligent.com> <406qth$mf5@kudpc.kudpc.kyoto-u.ac.jp> <John_Jenkins-1408951759010001@tseng.taligent.com> <41edvt$a0a@kudpc.kudpc.kyoto-u.ac.jp>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f9a59,9ee27d04b2a72428 X-Google-Attributes: gidf9a59,public X-Google-Thread: 10d93a,9ee27d04b2a72428 X-Google-Attributes: gid10d93a,public X-Google-Thread: f56e0,9ee27d04b2a72428 X-Google-Attributes: gidf56e0,public From: John_Jenkins@taligent.com (John H. Jenkins) Subject: Re: Unicode -> JIS,GB,CNS tables Date: 1995/08/28 Message-ID: <John_Jenkins-2808951215260001@tseng.taligent.com> X-Deja-AN: 109013343 references: <John_Jenkins-0708951003580001@tseng.taligent.com> <406qth$mf5@kudpc.kudpc.kyoto-u.ac.jp> <John_Jenkins-1408951759010001@tseng.taligent.com> <41edvt$a0a@kudpc.kudpc.kyoto-u.ac.jp> organization: Taligent, Inc. newsgroups: comp.std.internat,alt.chinese.computing,chinese.comp.software