I sent this earlier and it bounced because of "too many Received headers" at
mailgate.apple.com so after waiting several hours I'm sending it again in
hopes that the storm has subsided. Apologies to anyone who gets this twice!
- Frank
---------------
Date: Mon, 5 Oct 98 12:32:43 EDT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
To: unicode@unicode.org
Subject: Re: Terminal Graphics Proposal
In-Reply-To: Your message of Sat, 3 Oct 1998 02:32:57 -0700 (PDT)
Message-ID: <CMM.0.90.4.907605163.fdc@watsun.cc.columbia.edu>
> Ar 14:24 -0700 1998-10-02, scrmobh Frank da Cruz:
> >> I for my part do NOT!!!! want to see these terminal graphic things in the
> >> BMP. They belong in Plane 1.
> >>
> >Perhaps, but as the lawyers say, the door was opened by the characters
> >already included in blocks at U+2400, U+2500, U+2600, and U+2700.
>
> I will not support their inclusion in the BMP unless there is a really good
> reason. (I'd still make TTFs if necessary though, because I am a loon.) The
> list of characters I saw was rather long.
>
Hurray for Loons!
> >Terminal emulation is a fact of life, and important
> >to a significant number of serious and productive computer users; why should
> >its special glyphs be excluded from the same status enjoyed by dingbats and
> >astrological signs?
>
> Because the dingbats are used in typography, and astrological signs have a
> definite semantic.
>
But what about the block at U+2500? It was included to allow for
character-cell graphics that are possible on the PC -- and the so-called ANSI
emulations that based on it -- but they exclude other types of terminals that
are just as important ("existing standards"). The blocks at U+2580 and
U+25A0 are also clearly intended for character-cell graphic applications, but
they are incomplete. This proposal aims to fill some holes in existing
categories.
The argument for including the missing characters (not necessarily all of
them), stated as clearly as I can, is:
1. There are numerous terminal emulation products on the market, with a user
base numbering in the millions.
2. Increasingly, these products are used on systems -- like Windows NT --
that have Unicode fonts.
3. Many terminal based applications take full advantage of the features and
glyph repertoires of the terminals they are designed for.
4. The glyph repertoire of many common terminals -- VT100/VT220, Wyse,
Siemens Nixdorf, Data General, etc, include glyphs that are not presently
in Unicode.
5. Customers of terminal emulation products demand complete and accurate
emulation.
6. In order to succeed, makers of terminal emulation software must create
private fonts containing the missing glyphs (which, as an aside,
unnecessarily drives up the cost of the product for the end user) in
the Private Use area.
7. Because of the closed an proprietary nature of this process, each terminal
emulation product potentially (and in fact) encodes the same characters
at different places.
8. Other applications use the Private Use Area for other purposes (and other
glyphs).
9. The result is that terminal emulation products do not interoperate with
each other (who cares), or (the real point) with other applications on the
same platform.
For example, a VT100 or HP forms-based screen can not be pasted into a word
processing document without changing the forms borders (etc, depending on
exactly how they are encoded) into whatever other glyphs happen to be defined
at the same code points in the font used by the other application. Ditto for
mathematical formulae displayed on DEC or Siemens Nixdorf screens. Ditto for
character-cell illustrations or tables in numerous online texts intended for
display on any of the widespread terminals.
> >In any
> >case, the intention here is to help Unicode become somewhat more
> >"technology-neutral".
>
> The UCS is going to be used for centuries. Do we really think VT100
> emulation will be needed via BMP support?
>
How does one answer a question like this? Should it be based purely on
numbers? For example, if there are currently millions of users of terminal
emulators (there are), is it right to turn our backs on them while at the
same time we encode writing systems that are used by only a handful of
scholars?
Or, to turn the question on its head, what is wrong with VT100 emulation?
The fact that the popular trade press would like us all to live in a GUI
world that we all know is unreliable, mysterious, proprietary, and constantly
in flux, rather than in a proven, productive, stable, dependable, and
cost-effective open environment should not be a factor in this discussion,
any more than it should be in deciding whether to encode Linear B.
Here in New York City we have thousands of people whose jobs are to sit in
front of a 3270 (or other) terminal all day and respond to telephone calls.
These include 911 (police/fire emergency) operators, EMS dispatchers,
heat-complaint bureau and poison control agents, and car rental and airline
reservation clerks (to name a few). These are what we like to call "mission
critical" applications, and they must be (what we like to call) "rock solid".
These people use a particular application all day, every day. They are
trained on it, they must be able to use it effectively. At some point, the
aging terminals will be replaced by PCs, because the terminals wear out and
almost nobody makes them any more, but the applications themselves will not
go away, nor should they.
The new PCs will need to do exactly what the terminals did. We don't want
our 911 operators to become needlessly confused when some strange symbol
shows up on their screen in place of the one they expect. Taking this a step
further, the people who write the training, operations, and procedures
manuals for these systems need to be able to show the terminal screens and
quote individual glyphs in the text. This is legitimate, real-world,
nuts-and-bolts stuff that might not grab headlines in PC Week (but then I
think that's an excellent indicator its importance :-)
The original proposal included:
Math symbols: 34
Line/Box/Block symbols: 31
Misc symbols: 7
Control pictures: 115
Hex bytes: 256
TOTAL: 443
The single biggest category is hex bytes, which so far seems to have received
a warm reception. Thus the greatest controversy seems to swirl around the
smallest number of characters.
We begin by unifying the proposed diagonal C0 control pictures with the ones
already at U+2400:
Math symbols: 34
Line/Box/Block symbols: 31
Misc symbols: 7
Control pictures: 81
Hex bytes: 256
TOTAL: 409
If we eliminate the hex bytes, this brings the total down to 153.
- Frank
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT