Somebody@someplace responded...
> We do terminal emulation as well and some of those issues are of concern,
> but since our primary user base is non-technical, most of the missing
> glyphs aren't used by them. I have set-up my mapping tables to assign
> them unique places in the private use region on initialization so they can
> be returned to the host intact, but display them as replacement
> characters. If someone complains, I'll have to implement them however the
> standard of the day allows.
>
Thanks for responding. I've also had some private responses. This indicates
to me that multiple companies are making Unicode products that assign the
same glyphs to different code points, and so there would seem to be a need
for standardization if products are to interoperate (pasting screen shots
into documents, printing the screen, etc).
There is a huge installed base of DEC terminal users -- or, more properly,
users of applications that write to DEC terminals. So I would say the most
pressing need would be add code points for the glyphs from DEC Technical and
Special that are not represented in Unicode.
I also don't think anybody would object to "hex bytes" (16, or at most 32,
code points) -- these are useful for any application that needs to enter a
per-character-cell debug mode.
Standardization of code points for 3270 padlocks, etc, is less important to
me right now, but who knows what will happen next week.
I know the procedure for submitting new material to Unicode, but if I did it
on my own, I'd most likely handle only those things I care (or know) about,
so it might be a better idea to form a short-term ad-hoc mini-consortium of
terminal emulation aficionados to work out a more widely useful set.
- Frank
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:32 EDT