Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU
Newsgroups: comp.windows.x
Subject: Re: Eight Bit Character Output to an Xterm window?
Message-ID: <9102131400.AA12167@lightning.McRCIM.McGill.EDU>
Date: 13 Feb 91 14:00:42 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 50

>>> Xterm is written with ONE particular character set encoding in mind.
>> Not character set encoding so much as control sequence encoding.
>> It's called ANSI X3.64, I believe.  [X3.64/X3.41 specifies that
>> 0x80-0x9f are C1 controls, not printable.]

(Further investigation makes me doubt this.  See my last paragraph.)

>> If you want to use xterm in an environment where 0x80-0x9f are
>> supposed to be considered printable, you should rework the whole
>> control sequence interpreter to conform to whatever standard is
>> appropriate for the environment in question, because it definitely
>> isn't X3.64.

> This doesn't seem very reasonable from an internationalization
> standpoint.

mumble I don't see why not mumble.  If you want xterm to be able to
switch from X3.64 to something else based on some sort of
configuration, I'll agree it might be nice.  But as long as you're
basing the control sequence interpreter on X3.64, well, X3.64 specifies
that 0x80-0x9f are controls, not printables.  But see my last paragraph.

> The set of printable characters should depend on some specification
> in the app-defaults file, no?

My point is that in a terminal emulator written on X3.64, making codes
in the 0x80-0x9f range printable is like making 0x07 (BEL) or 0x1b
(ESC) printable: it just doesn't make sense.

> (BTW, I am not using an ISO 8859-1 character set.)

Obviously :-)

Of course, one has to decide what xterm is supposed to be.  If it is
supposed to be a VT-102 emulator, as the manpage indicates, then we
will have to take out the 8-bitness (VT-102s are strictly seven-bit, or
at least so I'm told).  If it is supposed to be X3.64, we should make
it handle C1 properly (my tests indicate it doesn't).  If not, we
should decide just what it *is* supposed to be, define it if necessary,
and make sure it conforms.

So I suppose you could make 0x80-0x9f printable and the only complaint
that can properly be leveled at you is that the result is so close to a
standard in so many ways and fails so spectacularly in this one
particular way.  But it strikes me as a very unaesthetic thing to do.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu