Re: Roadmap for the future allocation of UCS characters w/r

From: Doug Schiffer (
Date: Sat Jan 11 1997 - 15:13:33 EST

unicode@Unicode.ORG wrote:
> On Thu, 9 Jan 1997, Alain LaBont/e'/ wrote:
> > At 15:35 97-01-09 -0800, Kenneth Whistler wrote:
> > >If ISO/IEC 14651 is set up in such a way that establishment of a > > >standard
> > >default order for Han characters can be so disrupted by the > > >encoding of
> > >an additional Han character somewhere else "out of order" that > > >Alain
> > >speaks of "future nightmares" for that standard, would it not make > > >more
> > >sense to simply insist on publication of a defined > > >radical/strokecount
> > >for each Han character in 10646 (as an annex to 10646?) and then > > >have
> > >14651 simply designate the default sort order for Han to be by the
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Just to play the devil's advocate here. This could be a problem if we
> still remember the story of bones ...
> For one thing, we cannot assume that C, J, K agree with a single set > of
> radicals, let alone their ordering: sorting is a very cultural thing
> and an agreement is harder to get than assigning a character to a code
> point in 10646. This leads me to my next point: it might be useful to
> allow multiple-level of defaults (or graduated tailoring, depending on
> how you look at it). 14651's default is the first level, where CJK
> characters could be simply sorted by thier order in 10646 (or some
> compromise if someone's willing to try); the second level could be > tied
> with a National Profile. If it happens to agree with 14651's first > level
> default, great; if not, that's usu a problem within a single culture
> which would be easier to deal with. User-level tailoring would happen
> below the National Profile level.
> In the spirit of co-operation, maybe IRG could identify differences in
> radical/count sorting within cultures using CJK characaters and try to
> resolve "minor" differences (agreeing with an order).
> Xiao-he Zhang

I think the important issue is to have a character defined once and
only once. Lookup tables are cheap these days, and we can easily
have a Chinese stroke order table, Japanese stroke order table,
Mandarin pronunciation table, Cantonese, Korean,......

Having the same character existing on multiple planes, however, is
a nightmare in the making.

I care not how the characters are stored in the upper level planes.
They even could be in random order, where each new character is
added as they are added. Just give me an index table to them.

BTW: Wouldn't it be a great idea if there was some kind of web site
that had "out of Unicode han characters", where folks could see if
a particular character had been seen yet by the standards people
doing Plane 2? And if not, submit it, and information on it....

This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:33 EDT