Paul Keinanen <keinanen@sci.fi> wrote [About DEL and RUB]:
> ...
> Due to this duality, should Rubout and Delete be concidered to be two
> separate characters, although they seem to have the same code point in all
> ASCII based character sets ? Probably not...
>
I don't think they should be separated. The name Rubout was rubbed out
decades (literally) ago. ANSI X3.4-1977 does not contain the word Rubout.
Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
>
> I highly welcome attempts to complete Unicode with the various technical
> character set symbols that various terminal types have, after proper
> unification according to the well-proven character/glyph model.
>
Good...
> Also symbols that are not part of the user accessible character set of
> a terminal but that appear as part of the normal look-and-feel of this
> terminal in status lines, etc. should be added to Unicode, in order to allow
> to emulate one terminal inside another terminal emulator (e.g., an IBM 3270
> emulator that runs inside an UTF-8 enhanced xterm).
>
Good...
> I am sceptical
> however, whether all the many control symbols really need to have a place
> in the BMP. I think that debugging tools can quite easily provide them
> using some other replacement notation, that might or might not bypass the
> usual font mechanisms.
>
Indeed they can, but then will such debugging tools be interoperable
with other applications? I think it is a worthy goal to be able to paste
terminal screens -- even when they contain debugging information -- into
other applications. For example, for publication purposes, e.g. by people
who write networking and data communications textbooks, manuals, and
"for dummies" books. I think there is a nontrivial market there :-)
I don't think we should go out of our way to anticipate how people will use
these characters, or what kind of people will use them.
> Another question is which terminals should actually be supported. Many
> of the ones you mentioned have died away already.
>
Like the Perkin Elmers. But they are not the basis for any proposed
characters, only illustrations of features like "display controls". The
VT100 family, Wyse, Televideo, IBM, and SNI are all very current. The
Heath/Zenith 19 hasn't been manufactured in quite a while, but it remains
one of the most popular terminals to emulate due to its powerful but simple
command set and several unique features. People who were not even born
until after the last H19s vanished are using emulators for them today, with
matching termcaps (or 3270 protocol converter terminal types) on the other
end. In the IBM world, the H19 is especially popular since it lets the host
change the cursor shape, and Series/1-based protocol converters use this
feature to tell the user whether the 3270 is in insert or overwrite mode.
For this reason alone, countless people stick with this emulation rather
than "modernize" to VT100 (or beyond).
> Do you have any form of data on the terminal emulator market regarding
> more exotic terminal types? Are there really more than a few hundred
> people out there who use applications that depend on a terminal type
> radically different from a DEC VT340 or a IBM 3278?
>
I can tell you as a maker of terminal emulation software that there is
indeed a significant and and insistent demand for all sorts of terminals you
never heard of. The original list for Kermit 95 was simply VT100, VT220,
and ANSI. In the three years since we released it -- that is, here in the
late 1990s -- quite contrary to our expectations, customer demands have
compelled us to expand the list as follows:
[C:\k95\] K-95> set terminal type ? One of the following:
aixterm beterm hft qansi tvi910+ vt100 wy30
ansi-bbs dg200 hp2621a qnx tvi925 vt102 wy370
at386 dg210 hpterm scoansi tvi950 vt220 wy50
avatar/0+ dg217 hz1500 sni-97801 vc404 vt320 wy60
ba80 heath19 linux tty vip7809 vt52
[C:\k95\] K-95>
You'll see that some of them are true antiques: the Volker Craig 404, the
Hazeltine 1500, ... Customers require these emulations because they have
applications that are hardwired to use them. And yes, some of these
applications are "dinosaurs", but they do not die so easily, and who is
to say they should?
kenw@sybase.com (Kenneth Whistler) wrote [of ancient programs]:
>
> Somewhat orthogonally, many of these old dinosaurs are about to be
> cleared away by the asteroid known as Y2K on its way to impact.
>
And many won't -- there is a huge industry that installs patches in ancient
binaries for which source code is lost, or the source language is long
forgotten (or no longer compilable or assemblable). And then, whenever the
"window" rolls around, they'll have to do it again :-)
> Incidentally, there is another pile of graphic symbols for keyboard
> functions coming down the pike in Amendment 22 to 10646 (based on
> ISO 9995-7). These should be checked to verify that there are no
> duplicates against the collection of symbols being proposed for
> terminal emulation. (Examples: symbols for compose, enter, alternate,
> shift lock, undo, print screen, clear screen, delete, etc.)
>
For sure. I assume someone who is party to both proposals will take
responsbility? If not, is Amendment 22 in a public place so I can check
it myself?
> And since your collection of display controls lists both the
> three-letter and two-letter mnemonics for these things [NEL and NL],
> I cannot see any argument for disunification. This is the thing meant
> for what in your chart is:
>
> E025 85 NEL NL Symbol for Next Line
>
> U+2424 is the correct character for the graphic symbol
> display of "NEL" or "NL Symbol or Next Line (or Symbol for Newline).
>
Well, we've beaten this one to death, but I would say we should be
consistent. Our choices are these:
1. Encode the full form and no "2X" forms, i.e. no abbreviations of
abbreviations should be encoded.
2. Encode both forms (I'm not advocating that).
3. List 2X forms as glyph alternatives and allow font designers to use
*all* full forms or *all* 2X forms.
4. Encode only 2X forms.
Only in the last case, I think, does it make sense to unify NEL and NL.
Otherwise NEL is a full C1 form and NL is an EBCDIC form, which
unfortunately happens to coincide with the "2X" representation of NEL.
Any other argument for unification would lead us to unify the symbols
for all controls -- C0, C1, EBCDIC, Unicode, and otherwise -- that have
similar functions but different names, which would defeat the purpose of
having these glyphs to begin with.
- Frank
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT