🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.internat
Article #1042

Re: Unicode -> JIS,GB,CNS tables

#1042
From: John H. Jenkins
Date: Mon, 28 Aug 1995 00:00
89 lines
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-mail
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>

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