[EMAIL PROTECTED] (Frank da Cruz) wrote on 14.03.01 in
<CMM.0.90.4.984616152.fdc@watsol>:
> [EMAIL PROTECTED] (Kai Henningsen) wrote:
> > So I propose an interface that has approximately the following features:
> >
> Very much like ANSI X3.64, the basis of VT220 and above and many others.
> This standard is very well thought out already, particularly as to
> structural issues. Even though the standard was revoked, copies can still
> be had from ANSI.
Isn't that the same as ECMA-48, which is available for free from ECMA?
Because that one has (IMO) serious historical baggage.
> Anybody who wants to design a new terminal standard
> should first read it. And also be thoroughly familiar with ISO standards
> including 4873, 2022, and 6429.
Which one's 4873? The other two ISTR reading in ECMA versions.
> > * Similarly, there is a way to ask the terminal for enough internal state
> > as to be able to restore the state (this is important, for example, when
> > calling out to a different program that needs different option states but
> > wishes to restore the display before returning). One of the things one can
> > query should be the current display contents.
> >
> Careful. Those who don't remember history are doomed to repeat it.
> There is no bigger security risk than being able to command a terminal to
> send its screen contents, or portions of it. 30 years ago it was called
> the "Berkeley bug".
Well, then one would have to analyze what made it problematic, because I
certainly think of that as an essential feature. General unavailability of
that makes for a *very* noticably less friendly environment, IMO.
> We should also be mindful of a certain inherent drawback of UTF-8, which I
> mentioned on the Unicode list, but nobody there is much concerned with
> terminals. We have added UTF-8 capability to some of our Kermit terminal
> emulators, and it works nicely as long as we follow the rule: "decode the
> incoming UTF-8 data stream BEFORE feeding it to the terminal emulator".
> Sending UTF-8, however, is another matter entirely when the host is (a)
> standards compliant but (b) unaware of UTF-8. In this case, if we type
> characters in certain Unicode blocks (such as Cyrillic uppercase letters A
> through PE), the UTF-8 includes C1 control characters, which a
> standards-compliant terminal driver will treat as such or (more likely)
> treat as their C0 companions.
What OS has output drivers for output that goes to a terminal that do
stuff with C1 controls? That's a new one for me. Usually, these things
tend to be rather transparent (assuming they're 8 bit clean in the first
place, otherwise no UTF-8 anyway). Or do you mean input?
And of course this won't be an issue over telnet or similar stuff. (But
over telnet, remember to care for the telnet escape!)
There should probably be an (unspecified, transport specific) layer below
to make the channel as transparent as necessary.
> But for this, you could use a UTF-8 terminal emulator to read and write
> text in many languages across a Telnet connection to a host that was totally
> unaware of UTF-8, just as you can today with (say) Latin-1.
Yep.
MfG Kai
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
