Re: German Umlauts still dont work

[Wolfgang Hukriede <whukriede@xxxxxxxxxxxxxxx>]

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.