At 18:59 1997-1-16 -0800, unicode@Unicode.ORG wrote:
>>
>> Werner LEMBERG wrote:
>>
>> > ISO 2022 has a mechanism to change to other encoding schemes. It would be
>> > nice to have a certain control character in Unicode which do a similar
>> > thing.
>> > Comments?
>>
[Rick] :
>> Actually, I think this is not such a good idea for Unicode, which was
>> designed precisely to AVOID such things. If you need to support ISO-2022,
>> perhaps you could just support it; and then invoke Unicode within it if
>> you need to? It think there is an ISO-2022 invocation sequence for
>> Unicode...some standards guru may know.
>>
>> And the CNS issue is something that the CJK IRG is working on, certainly,
>> and eventually there will (likely) be a solution that satisfies the
>> community which needs the said CNS characters. I wouldn't look upon
>> this as a permanent disability of Unicode. If you have specific character
>> requirements, you could forward those. I'm under the impression that
>> Unicode's CNS coverage is already adequate for all but the most obscure
>> situations.
>>
>> Rick
>>
[John] :
>Be serious, Rick, there will ALWAYS be characters that are not encoded
>in Unicode, for various reasons. The fact that Unicode does not provide
>for other means for encoding other character sets ensures that people
>who are forced to deal with such characters will have to come up with
>ad hoc means for setting up character set changes.
>
I tend to agree a lot with Rick. At the time where the first version of
ISO/IEC 10646 was to go into a direction and UNICODE in another one, I made
a strong campaign of lobbying directed toward 27 national voting member
bodies of ISO/IEC (twice, there were two votes, and from SHARE Europe point
of view that was a big success) on behalf of SHARE Europe (now GUIDE SHARE
Europe, an IBM user group) to make sure that UNICODE would replace the first
verison which was based on this complicated code extension technique that is
ISO/IEC 2022. This was one of the strong reasons for rejecting the previous
scheme.
Of course nobody can forbid the combined use of ISO/IEC 2022 and ISO/IEC
10646 (UNICODE) but that is at the own risks of those who choose that path
and as a customer I would not buy such a system, given the choice.
There is always the possibility to define user characters in UNICODE in
waiting for their inclusion in UCS-4 (accessible with UTF-16 in UNICODE).
Btw if a character is worth coding (for searching it, my main criteria to
use a character rather than generating and using a picture) it is worth,
imho, to be standardized in the longer term in UCS-4.
Another possibility, more straightforward: identify from the outside of a
file (or of a record), with appropriate tags, areas that are fully UNICODE,
then other areas which use other coding systems, but please do not imbed
commands that change the meaning of octets on the fly. This is very bug-prone.
Not forbidden, but there are better alternatives and given the choice I
would choose other alternatives first. If we had followed the ISO/IEC 2022
logic, we would not even have had to invent UNICODE or the UCS... But how
complicated, more than complex, it would have been!
Alain LaBonti
Quibec
(in Singapore for the ISO/IEC SC2 [UCS coding] meeting)
... with big modem problems...
It might takes some time before this message is sent...
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:33 EDT