Michael Everson has posted:
> A draft of the Terminal Emulation collection with fonts and slightly
> modified names is available at
I must say that I find most of this proposal highly objectionable.
The last two charts consist of a completely superfluous set of 256
characters encoded to be pictures of byte values 0x00..0xFF. As I
have stated before, these are completely unneeded. Their intent is
to serve for a debugging display of byte values--but having a set
of *characters" encoded for this is of no help whatsoever. These are
suggested *glyphs* for representing byte values visibly. Having a
set of character codes for these--unrelated to the byte values
themselves--does not assist in any way I can tell in getting visible
display of byte values for debugging, whether for terminal emulations
The first chart full of more "pix for control codes" is arguable.
To the extent that some of these already exist among terminal
implementations (parallel to the control pix for C0 controls) there
might be a case for them. Though I am inclined to agree with Joni
Rosenne that the main issue for the terminal emulation should be sufficient
sets to emulate the terminal in its normal use, and not to cover setup
and debugging modes. To the extent that "show control codes" is a
part of normal terminal operation and to the extent that the control
codes thus manifested have more or less standard, conventional representations
on the terminal emulations which have widespread implementation bases,
then adding these makes some sense.
However, I am opposed to using this opportunity to go down the
path of inventing a bunch of "control pix" character encodings for
every other character in Unicode that has no visible representation.
There is no need to create a control pix character for SYMBOL FOR
ACTIVATE ARABIC FORM SHAPING. Unicode implementations that wish to
reveal hidden characters can use existing mechanisms (show hex codes,
use arbitrary but appropriate graphic forms, use name abbreviations, ...)
and do not need a useless collection of control pix for these.
Text that wishes to *write* about such characters has been doing
so quite adequately for years already making use of either the
Unicode value (U+206D, U206D, 206D, \u206D) of the Unicode name
(ACTIVATE ARABIC FORM SHAPING), without requiring either a conventional
display form or *another* character to represent as a character the
conventional display form for the character in question. For
commonly used characters, short, well-known abbreviations such as
"ZWJ", "LRE", and "ZWSP" are perfectly adequate.
The reductio ad absurdum of the approach taken in this proposal has
got to be XX1F SYMBOL FOR NOT A CHARACTER (!!), whose glyphic representation
is a dotted box with four "F"'s in it. Does anyone else feel that we've
just stepped through the looking glass here?
What we should be focussing on in particular is the set of visible
graphic characters in the second chart of the proposal. These constitute
the collection which are most reasonable for encoding.
P.S. I went hunting for the link that Frank stated had the current
text of his proposal:
but only found a dead link. Does anybody know where the current full
text of the terminal emulation proposal exists?
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT