Can we resolve the issue of whether to display Unicode 3.0 code tables for
planes 01 to 10 by organizing the tables according to UCS-4 (including the
annotation for the rows and columns of the code tables) and perhaps
including the UTF-16 coding under the glyph for the character? If
sufficient room does not exist for the full UTF-16 notation, then perhaps
placing the 4 hex digits for the surrogate for the high-order 16-bits (Wyde
:-)) at the top of the table and the 4 hex digits for the surrogate for
low-order 16-bits under the character would work.
I have had the very distinct impression that Unicode had a preference for
"16-bit" encoding to the exclusion of the 4-octet UCS-4 form of ISO/IEC
10646-1:1993. I verified that UCS-4 appears to be excluded from the
conformance clause of Unicode 2.0. However, what if I chose to implement
the UCS-4 form of 10646 and implemented everything else but this in
conformance to the Unicode conformance statements (character properties,
bi-di, etc.), and my implementation was able to exchange data in the UCS-4
and UCS-2/UTF-16 forms? Is this implementation conformant to Unicode 2.0?
I interpret that this implementation is not conformant to Unicode 2.0. My
question is why should not the UCS-4 form be included as a conformant form
in Unicode? As we move to encoding characters into planes 1 and beyond, I
think that it makes good sense to add the UCS-4 form as conformant to
Unicode (3.0).
Ed Hart
Edwin F. Hart
Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD 20723-6099
+1-240-228-6926 (from Washington, DC area)
+1-443-778-6926 (from Baltimore area)
+1-240-228-1093 (fax)
edwin.hart@jhuapl.edu <mailto:edwin.hart@jhuapl.edu>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT