8859 vs. 646

Moderator, John S. Quarterman std-unix at longway.TIC.COM
Tue Mar 20 11:00:19 AEST 1990


From: Donn Terry <uunet!hpfcrn.fc.hp.com!donn>

>From: randall at uvaarpa.virginia.edu (Randall Atkinson)

>As one who is fairly active in the multilingual computing
>side of things, I'm fairly certain that it just isn't worth
>it to try to make ISO 646 the basis of *anything* for the
>practical reason that it wasn't well thought out to begin with
>and has already been superceded by the ISO 8859/* family of
>8-bit character sets.

Agreed.  I believe that the Danes and other Europeans will agree, too.

...

>I thought that trigraphs got excessive attention back when ANSI C
>was being developed and I fear that excessive attention will be
>devoted to ISO 646 when there are other areas of internationalisation
>that really deserve being thought about and solved cleanly.

Yup.... but it's also a real problem.

>Most of the vendors of hardware in Europe are supporting ISO 8859/1
>now, so it is the real long term solution to European needs anyway.
>Worrying about support for ISO 646 is a mistake, worrying about
>supporting ISO 8859/* and the Asian need for larger character sets 
>being fully supported and ways of handling date formats and such
>aren't a mistake at all.

The problem is that reality impinges on the ideal world.  In particular
there are LOTS of 646 terminals out there.  And, as the European
participants note, they aren't going to get replaced with 8859 ones
for on the order of 10 years.  (646 also is still a lowest common
denominator: as I understand it, sendmail can't handle 8-bit (if
I'm wrong, I apologize, but you get my point)).

Thus, there is a real problem to be solved here.  I personally lean toward
some sort of many-to-one and one-to-many translation at the terminal
interface, but that doesn't always appear successful.  Add to it the
problem of not knowing whether the user is an expert or not.  (The
expert can handle | being slashed-o, but the ordinary terminal operator
probably can't.)

Donn Terry
(No position is official, but as U.S. Rapporteur for SC22/WG15/IRG I'm
at least plugged in.)

Volume-Number: Volume 19, Number 10



More information about the Comp.std.unix mailing list