> > > It might be nice to have equivalents for those in Unicode as well
> > > (probably in the U+259X range). Have they just been forgotten or was
> > > there a deliberate decision not to include them?
> >
> > Well... I think User Space sounds like a fine place to put the VT100
> > "horizontal line scan" glyphs. The only use these will ever have is in
> > DEC VT emulation, where they will be program-generated for display
> > purposes.
> >
> > I would suspect they were not left out of the original standard with any
> > prejudice; probably just overlooked or never came up as desirable or
> > necessary. They could have been "conveniently overlooked", but I doubt
> > there was any such deliberation.
>
> I suppose you could say there was a deliberate decision not to include
> them, because I was the DEC representative to the UTC at the time Unicode
> 1.0 was being formulated, and we went out of our way NOT to request their
> inclusion :-) .
>
This question comes up often enough that perhaps it deserves greater
attention. While most Unicoders like to think that terminal emulation is
is a relic of the past, there are numerous terminal emulators on the market
and in active development, and millions of people who use them for
applications ranging from software development, to email, to transaction
processing, to system administration. The branding of these applications
as "legacy" in mass-market trade publications is a ruse that I hope does not
cloud the vision of readers of this mailing list.
Those of us still in this business who would also like to advance the cause
of international computing and communication would, given the choice,
convert our products to Unicode. But Unicode lacks many of the graphic
characters (line/box drawing, math/technical, etc) needed not only for
VT100/220/320/etc emulation, but also Wyse, Data General, Heath, Televideo,
Siemens Nixdorf, IBM, Honeywell, and other models (luckily the so-called
ANSI-based emulations are not a problem, since the glyphs of CP437 are
included in Unicode). Thus each maker of terminal emulation software must:
1. Find a Unicode fixed-pitch font that contains an acceptable repertoire
of international characters -- and this in itself is not easy, at least
not in the Microsoft arena, in which Lucida Console (the only such font
we can expect to find preinstalled on most systems) lacks Arabic,
Hebrew, and other widespread alphabetic languages, not to mention CJK.
2. Somehow create glyphs for the missing terminal graphics characters, and
arbitrarily assign code points to them. This usually means contracting
with a font company to create a private, custom font.
Each maker of terminal emulation products does the same thing, but does it
differently, and this is a rather shameful and unnecessary waste of time and
labor, and one that inhibits interoperability of applications.
Terminal emulation will be with us for years -- probably decades -- to come.
Unicode has effectively addressed the problems of international text for the
GUI-based world. However, the steadfast refusal of Unicoders to consider a
standardized encoding of terminal glyphs (even while including all sorts of
silly dingbats, which certainly have less relation to plain text than
do terminal graphics) leaves terminal emulation out in the cold.
This is truly unfortunate when you consider that host-to-terminal
connections are truly open, whereas most of the newer forms (the Web,
"Windows terminals", etc) are not.
- Frank
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:41 EDT