Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!sics.se!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.std.c Subject: Re: ISO 646 alternate representation Message-ID: Date: 12 Apr 91 01:53:34 GMT References: <1991Apr4.171657.27791@murdoch.acc.Virginia.EDU> <15738@smoke.brl.mil> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 54 In-Reply-To: keld@login.dkuug.dk's message of 7 Apr 91 12: 31:31 GMT In article keld@login.dkuug.dk (Keld J|rn Simonsen) writes: I think these members are not that well informed then. I quote the #10 resolution from the WG14 Copenhagen meeting 90-11-27 "It is the opinion of WG14 that the problems caused by national variants of ISO 646 have to be solved" This resolution was unanimously approved. Keld, I'm completely at loss why this is a problem. I have TWO terminals: One Norwegian (using ISO 646 with ISO registration number 60, ISO 2022 announcer ESC 2/8 6/0), which I would use to type letters, memoranda, reports, etc, and one American (using ISO 646 with ISO Registration number 2, ISO 2022 announcer ESC 2/8 4/2) for source code in a number of languages. This is the hardware solution to the problem you state above. It's elegant, simple and a little less expensive to implement than your proposals. The other hardware-oriented solution is to get a terminal which can switch between ISO 646 Reg no 2 and ISO Reg no 60 via ISO 2022 announcer sequences. This is an even less expensive solution than the above (despite the fact a terminal which can do this is slightly more expensive than each of the two I have). With user-definable fonts (as in X11 applications), this is also a tremendous non-issue. If we're talking about printers which use ISO 646 and national variants, I can only say that I have yet to see a printer which doesn't accept a "language setting". Since a good programmer puts all the strings a user will ever see into a separate file, anyhow, there is no problem to this issue, either. If I get your proposal right, you wish to solve a problem which is experienced by programmers who have too poor or too sloppy employers to provide them with proper terminals. Is that really the proper stuff for International Standards? If there is ever going to be an International Standard on this, I hope it will say: A user of the programming language specified in this Inter- national Standard should use the proper hardware to view his code such that the ISO 646 IRV characters are displayed rather than a national variant. Conformance to this requirement is outside the scope of this International Standard. But I realize that this is definitely not the proper stuff for International Standards... -- [Erik Naggum] Naggum Software, Oslo, Norway