Frank da Cruz wrote:
> > > So Unicode is not supported in a real time environment ?
> > I did it several years ago. It is much easier when you accept that most
> > of the complexity in Unicode is there for good technical reasons and to
> > work with it rather than twist it to fit old ASCII programming practices.
> Again, the problem we were discussing concerns using a Unicode-compliant
> script ("dialog automation", not writing system) engine against an existing
> host or device. Of course we can design new protocols, but we can't force
> existing hosts or devices to use them. It's not a question of old
> programming practices; the question is how or whether we can use modern
> techniques on one machine to communicate (or, more precisely, automate
> interactions) with other machines that we can't change.
If it is an old, unmodifiable system sending a stream of bytes, it isn't
sending us Unicode is it? Even if you are going from 7 bit ASCII to UTF-8
you might still need to have a transformation process to map it from a
byte stream to text. Of course given all the other possible code pages
those old boxes might be feeding you, this isn't any extra burden.
> But by this point we're going around in circles; I can't imagine what else
> can be said on this topic, other than exchange of practical experience in
> implementation of telecommunications applications in which Unicode is
> involved at one end but not the other, or at both ends.
I'll try to refrain from further comment.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT