Frank da Cruz wrote on 1998-10-08 21:27 UTC:
> In any case, the control-picture symbols must be encoded because we're
> concerned not only about the terminal emulator but also the applications it
> must interact with, as in:
> User: "Help, my screen is messed up!"
> Help desk: "OK, click on Debug in the Terminal window menu bar
> and repeat what you did before."
> User: "Now my screen is REALLY messed up!"
> Help desk: "Let's have a look. Please use your mouse to copy it
> and paste it into your email window and send it to us."
> This is, of course, looking forward to the day when All Is Unicode...
The helpdesk can already get the same effect today by much simpler
asking for a bitmap of the screen or window to be mailed:
Help desk: "What GUI are you using?"
Help desk: "Excellent choice. Just enter the shell command
'xwd | uuencode - | mail helpdesk' and then click on the
Help desk: "Ah, now I see your problem. That is easy to fix ..."
Let's not create unnecessary complicated user requirements.
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.
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). 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. I have been used to see ^M in a different color as a
common replacement symbol for Carriage Return (Ctrl-M) for over 15 years,
and I never missed a much less readable CR glyph for debugging purposes.
Debugging is done by experts and experts are used to cope with any replacement
notation anyway. We can do hexdumps quite nicely with 0-9A-F without having
to resort to hex-byte-glyphs and control abbreviation glyphs.
I think the criterion for inclusion of terminal emulator characters
should be whether the character can ever be seen by a normal user
in normal (non-debugging, non-configure) operation on the screen of
-- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT