On Mon, Aug 13, 2001 at 08:47:01PM -0700, Prymmer/Kahn wrote:
> characters that are not in the original set. Hence invoking Unicode or
> specifying Unicode as the required coding does not solve the problem of
> trying to view things through legacy char set colored glasses.
No, but it does give us instant cross-platform documentation on what we
mean when we write E<1234>, which is nice independent of the question
whether a particular platform can display it.
I just thought of a strong argument why E<nnn> should not refer to a
platform encoding:
When I get given a text file, I can figure out what encoding it was in
most of the time (by asking or analyzing). What I then do is use
"recode" or "iconv" to convert it into the encoding I'd like to work in
(that'd be UTF-8 most of the time). If that file was in EBCDIC and E<nn>
referred to EBCDIC as well, I'd now have an unusable file.
I guess most people having to deal with text files in different
encodings will have their own preferred ways of converting between them,
none of which will know to translate E<nnn> as well.
--
The idea is that the first face shown to people is one they can readily
accept - a more traditional logo. The lunacy element is only revealed
subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
