Re: German Umlauts still dont work

Re: German Umlauts still dont work

[Wolfgang Hukriede]

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.

Re: German Umlauts still dont work

[Uli Zappe]

Wolfgang Hukriede <whukriede@ifm.uni-kiel.de> wrote:

> 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.

OK, so I'd say use the correct isprint (i.e. NXIsPrint in the case  
of NEXTSTEP) by default and still have a "printeightbit" option.


                Bye
                        Uli

_____________________________________________________________________

Uli Zappe               E-Mail: uli@tallowcross.uni-frankfurt.de
                                (NeXTMail,Mime,ASCII) PGP on request
Lorscher Strasse 5      WWW:    -
D-60489 Frankfurt       Fon:    +49 (69) 9784 0007
Germany                 Fax:    +49 (69) 9784 0042

staff member of NEXTTOYOU - the German NEXTSTEP/OPENSTEP magazine
_____________________________________________________________________

Re: German Umlauts still dont work

[Duncan Sinclair]

Wolfgang Hukriede writes:
>
>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?
>

On my SunOS 4.1.3's /usr/include/ctype.h:

#define isprint(c)      ((_ctype_+1)[c]&(_P|_U|_L|_N|_B))

Where "_ctype_[]" array is the contents of the locale/LC_CTYPE file
that's current, and the "_P", etc. flags are bit codes for the
different types a character that the ctype routines need to know
about.

I have "LC_CTYPE=iso_8859_1" in my environment, and it works as advertised.


I think the problem needs to be defined better.  Are your umlauts
dissappearing entirely (a zsh problem) or are they being meta-ized
(\M-? - an OS problem), or perhaps they are coming through, but your
terminal emulator can't display them correctly (a S.O.L. problem)?

A good operating system would have locale settings such as "C",
"iso_*", and any non-standard charset it used, such as, "next", "mac",
"ebcidic" or whatever.  Then you would set your LC_CTYPE variable
according to what character set you are using today.

Now if NextStep can only do "C" (isprint()) or "next" (NXisprint),
then that's fine if that's all your using.  But if your terminal
emulator can only do iso_8859_1, like xterm, then your screwed when
it comes to displaying any non-ascii nextstep characters.  (Unless
there's a specially hacked Next xterm that understands its charset?)

I would guess this isn't the problem, or else you wouldn't be
complaining just about zsh, but about everything.

If you think it's a zsh problem, can zsh glob filenames with
these characters properly: "echo *"?

Can you type these characters, is the problem only in completion?

Do other programs, such as "ls" or "less" have problems?

I hope this helps the discussion.



Duncan.

Re: German Umlauts still dont work

[Uli Zappe]

Duncan Sinclair <sinclair@dis.strath.ac.uk> wrote:

> I think the problem needs to be defined better.  Are your umlauts
> dissappearing entirely (a zsh problem) or are they being meta-ized
> (\M-? - an OS problem), or perhaps they are coming through, but
> your terminal emulator can't display them correctly (a S.O.L.
> problem)?

The umlauts disappear entirely > a zsh problem.

> Now if NextStep can only do "C" (isprint()) or "next" (NXisprint),
> then that's fine if that's all your using.  But if your terminal
> emulator can only do iso_8859_1, like xterm, then your screwed
> when it comes to displaying any non-ascii nextstep characters.
> (Unless there's a specially hacked Next xterm that understands
> its charset?)

With NEXTSTEP you generally use other  (GUI standalone) terminal  
emulators than xterm which work correctly with NEXTSTEP'S character  
set. AFAIK there's no alternative to xterm if you want to use it  
with zsh.

Therefore, see my suggestion in my other mail to use NXIsPRint by  
default and still have a "printeightbit" option.

> I would guess this isn't the problem, or else you wouldn't be
> complaining just about zsh, but about everything.

Let it put this way: zsh at least is able to deal with lower case  
umlauts. sh can't handle umlauts at all. Still, it's a problem of  
the specific shell program.

> If you think it's a zsh problem, can zsh glob filenames with
> these characters properly: "echo *"?
>
> Can you type these characters, is the problem only in completion?
>
> Do other programs, such as "ls" or "less" have problems?

No matter what I do, capital umlauts always are ignored in zsh output.


                Bye
                        Uli

_____________________________________________________________________

Uli Zappe               E-Mail: uli@tallowcross.uni-frankfurt.de
                                (NeXTMail,Mime,ASCII) PGP on request
Lorscher Strasse 5      WWW:    -
D-60489 Frankfurt       Fon:    +49 (69) 9784 0007
Germany                 Fax:    +49 (69) 9784 0042

staff member of NEXTTOYOU - the German NEXTSTEP/OPENSTEP magazine
_____________________________________________________________________