From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12375 invoked from network); 4 Jul 1997 03:53:46 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 4 Jul 1997 03:53:46 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id XAA03839; Thu, 3 Jul 1997 23:36:15 -0400 (EDT) Resent-Date: Thu, 3 Jul 1997 23:35:24 -0400 (EDT) Date: Fri, 4 Jul 1997 05:39:35 +0200 (MET DST) From: Wolfgang Hukriede Message-Id: <199707040339.FAA12150@sally.ifm.uni-kiel.de> To: zsh-users@math.gatech.edu Subject: Re: German Umlauts still dont work Resent-Message-ID: <"eZZJ82.0.Wx.yz6lp"@euclid> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/932 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Uli Zappe wrote: > From a NEXTSTEP point of view, it is certainly preferable to make > use of the correct NXIsPrint (or NXIsCntrl) function instead of > permitting *all* 8 bit characters via a printeightbit option. > Maybe it's possible to make this configurable so that for every > operating system one can choose whatever way is best for it to > decide what is printable? Still nope. Yet one more scenario to consider: What if you're engaging the other well known terminal emulator application on the Next, then switch on Latin1-encoding for that app, (which I believe is quite common among nextians with a heterogenous networking environment), would you then be willing to compile a second version of the zsh? Don't think so. Now, just in case, someone cares, from the Next-docs: > The NEXTSTEP encoding vector is a superset of the PostScript language > standard encoding vector. (Adobe's, that is; cf the red book. WH) > The characters that have code assignments in the standard encoding vector > have the same assignments in the NEXTSTEP encoding vector. The NEXTSTEP > encoding vector makes use of the code points that are unassigned in the > standard vector to add characters from the ISOLatin1 character set. Accordingly: NXIsPrint(c) == c>=040 && c<=0176 || c>=0201 && c<=0375 (which even is a bit wrong, since 0200 is figsp, which should be printable. the last two codes, 0376 and 0377, are unassigned.) whereas: isprint(c) == c>=040 && c<=0176 on any of the systems I checked. Fwiw, on neither of them (OSF3.2, SunOs 4.1.3, Linux 2.0.27, for Nextstep we knew this) the behaviour of isprint() or iscntrl() obeyes to the locale settings, someone might say, these machines all lack proper setup? Wolfgang.