> Michael Everson has posted:
>
> > A draft of the Terminal Emulation collection with fonts and slightly
> > modified names is available at
> > http://www.indigo.ie/egt/standards/iso10646/pdf/terminal-emulation.pdf
>
> I must say that I find most of this proposal highly objectionable.
>
Micheal kindly volunteered to put the glyphs where people could see them.
This does not mean he endorses the proposal -- all objectionableness is mine.
> The last two charts consist of a completely superfluous set of 256
> characters encoded to be pictures of byte values 0x00..0xFF.
>
Now that the charts are done, I will try to finalize the proposal today.
Please bear in mind that it is really a series of independent, but related,
proposals gathered together in a single document. Thus if you don't like
this part, vote against it, but vote for the parts that you do like.
> As I have stated before, these are completely unneeded.
>
Again, the rationale is not simply that they would be nice to have (and
they would be, for many reasons not related to terminal emulation). It
is that certain terminals already include a selection of single-cell hex
byte pictures; some terminals have as many as 32 of them.
If we are to include the graphic characters of such terminals in Unicode,
then we would have to include these hex byte pictures. But then it seems a
shame to include some byte values but not others. Why not include them all?
On the other hand, if we conclude that hex byte pictures are not needed at
all, then we can not fully emulate the terminals that have them.
> The first chart full of more "pix for control codes" is arguable.
>
Indeed it is. It was included at the suggestion of a reader of the first
draft of the proposal. The rationale is: if we are going to have control
character pictures for C0, C1, EBCDIC, etc, then why not include the Unicode
ones? I, personally, know of no current need for these, but have included
them for symmetry and completeness, and for consideration in case somebody
else sees a need for them. For example, if there were a Unicode terminal.
(Yes, there will be a Unicode terminal.)
I would not be heartbroken, however, if the Unicode "control" pictures
were not approved.
> 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?
>
When putting together this table, it occurred to me that when debugging
Unicode data streams (e.g. in a Unicode-based line monitor or protocol
analyzer), it would be good to be able to show the presence of a character
that is "guaranteed not be a Unicode character at all". There will be a
strong temptation to use it as an escape, and debuggers will want to show
this.
> 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.
>
I agree. I, personally, can live without the rest and life will go on. But
before we decide to dismiss the ideas in this proposal, recall the original
motivation: to stop the proliferation of incompatible encodings for the same
glyphs. More and more Windows-based terminal emulators are coming on the
market all the time. Each has has to include its own custom font, encoding
the same glyphs at different code points. I think we now can agree that
terminal emulation is not dead and will not die any time soon. Therefore my
hope is that there can be a standard encoding to follow, and regular
off-the-shelf fonts can be used -- both for the emulators themselves, and
for applications that will interoperate with the emulators via copy-paste or
any other means.
> --Ken
>
> P.S. I went hunting for the link that Frank stated had the current
> text of his proposal:
>
> > http://www.columbia.edu/kermit/charsets/ucsterminal.txt
>
> but only found a dead link. Does anybody know where the current full
> text of the terminal emulation proposal exists?
>
Oops, silly me. It should be:
ftp://kermit.columbia.edu/kermit/charsets/ucsterminal.txt
I'll post again when the final version is ready.
- Frank
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT