root@jester.UUCP (Michael Haeuptle) (01/12/91)
Hello,
Last week i downloaded the NCSA 2.3 telnet package from our university
"softserver". After the installation i discovered that no umlauts ("a, "o, etc)
from my keyboard passes through a SCO unix host.
I then added the following entry in the telnet.key: "set key \94 barf"
This worked fine. But a "set key \94 \146" for a umlaut doesnt worked!
So, is there a possibility to add the umlauts on my keyboard?
Another one: Can i setup telnet to pass the output to dos. I want to
have some ansi-capabilities (e.g. color)?
Any help is appreciated....
regards,
Michael.
--
Michael Haeuptle ..uunet!unido!nadia!jester!rootcwilson@sunc2.cs.uiuc.edu (Chris Wilson) (01/15/91)
I'm one of the NCSA PC-Telnet programmers at the University of Illinois. Currently, PC Telnet strips off the high bit of characters- I changed this yesterday to allow full 8-bit character range. I _think_ this will fix your problem. If the next beta release doesn't fix your problem, e-mail me. Chris Wilson cwilson@yoyodyne.ncsa.uiuc.edu
CALIFFM@BAYLOR.CCIS.BAYLOR.EDU (Michael Califf) (01/16/91)
>I'm one of the NCSA PC-Telnet programmers at the University of Illinois. >Currently, PC Telnet strips off the high bit of characters- I changed this >yesterday to allow full 8-bit character range. I _think_ this will fix your >problem. If the next beta release doesn't fix your problem, e-mail me. > >Chris Wilson >cwilson@yoyodyne.ncsa.uiuc.edu Chris - PLEASE make this a configurable option if you change the current behavior. We have problems with other Telnet packages when we connect to our modem pool and connect to DSIN and other dial-up services. Right now NCSA telnet works best in our situation, and I am afraid that in "fixing" the international characters problem you might "break" other situations like ours. Thanks, Mike Califf Sr. Communications Prog/Analyst Internet: califfm@baylor.edu Baylor University C.C.I.S. Bitnet: CALIFFM@BAYLOR
jbvb@FTP.COM ("James B. Van Bokkelen") (01/16/91)
Passing 8 bits directly to the PC's display sounded like a bad idea to us, and we didn't do it. There are two problems: First, there are a number of old Unix implementations out there that cheerfully pass parity to Telnet during part of the login process. Second, one must face the issue of just what do particular values >127 *mean*. Present usage of Telnet for full-screen applications is founded on the concept of terminal type, originally developed to allow use of different kinds of terminal on different direct-connected lines on a single system. Modern Telnet clients pass terminal types to the host automatically, and applications can the use host services like termcap, terminfo and SMG to achieve independence of particular terminal models. However, these services don't address the problem of "how do I translate from a hardware-independent value indicating 'a-umlaut' to a display code for terminal X" (partly because there is as yet no universal code table that has separate values for all the glyphs a multi-lingual document might use - two are under development, but neither is finished). Thus, all existing extended-ascii applications are written for specific display devices. The standard US PC display's code table is somewhat of a bastard, not conforming to any of the existing standards, and we felt that offering an incentive to develop applications to a non-standard was wrong. Instead, we chose to follow DEC's lead in the VT220, whose most widely-sold model uses the standard encoding for the ISO 8859-1 Latin alphabet. We also allow users requiring other 8859 variants, and equipped with appropriate display controllers, to configure other mappings, but that's icing on the cake. Instead of just passing 8 bits, I suggest that NCSA implement a mapping (it only takes one char[128] array) following 8859-1. This will contribute to the overall interoperability of a significant fraction of current extended-ascii applications. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
jbvb@FTP.COM ("James B. Van Bokkelen") (01/17/91)
Anything that tries to do anything with ISO 8859 (other than including
a user installable mapping to it using 3. above, of course) is asking for
big trouble and big hate mail. Microsoft got this problem when they
didn't use the standard IBM-PC character set for Windows.
My European customers have been quite appreciative of our 8859-1 support.
Presumably DEC's customers have been, as well. My point is that the IBM
PC display code points *will not* win out over the victor of the battle
between Unicode and the replacement for ISO 646. However much better it
is, 8-bit characters are not enough for multi-lingual applications, and
the "big char" replacement (16 or 32 bits) will be 8859-compatible. Thus,
the IBM coding is a dead end.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901koziol@yoyodyne.ncsa.uiuc.edu (Quincey Koziol) (01/17/91)
Currently we do allow output mapping (what we have termed it). But this was apparently insufficient for some people's character sets they were using. So we added the feature that if you are using the output mapping for a session we use all eight bits to display with. This may be a bad idea, but we'll have to see if it solves their problems. If you don't want the eighth bit used to display characters with, don't use the output-mapping feature. In the future, we may have to divide this further: one flag for output mapping, and one flag for enabling the eighth bit for the output mapping. Quincey Koziol NCSA