Path: utzoo!attcan!uunet!shelby!snorkelwacker.mit.edu!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: <9102060936.AA05608@lightning.McRCIM.McGill.EDU>
Date: 6 Feb 91 09:36:46 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 62

>> I want an xterm window to display the pound-sterling when I press
>> KP_Subtract.  [...]  <Key>KP_Subtract: string(0x9c)
> I'm not sure how you get 0x9c for pound sterling, in ISO 8859-1 this
> symbol is at 0xa3.  But no matter, this brings up a more interesting
> question...

>> How can I make xterm display this (or any other 8-bit character)?

> This seems to be a problem in the character tables used inside of
> xterm.  Someone decided that certain characters, including 0x9c, are
> to be ignored!

Everything from 0x80 to 0x9f should be ignored, or rather should never
reach the rendering code.  That is the C1 set; they should be treated
as control sequences (in the loose sense of the term).

> 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.  If you read X3.64 and/or X3.41 (upon
which X3.64 is built), you will find something like

    0/  1/  2/  3/  4/  5/  6/  7/  | 8/  9/ 10/ 11/ 12/ 13/ 14/ 15/
/0  nul dle                         |     dcs
/1  soh dc1                         |     pu1
/2  stx dc2                         |     pu2
/3  etx dc3                         |     sts
/4  eot dc4                         | ind cch
/5  enq nak                         | nel mw
/6  ack syn                         | ssa spa
/7  bel etb                         | esa epa
/8  bs  can                         | hts
/9  ht  em                          | htj
/10 lf  sub                         | vts
/11 vt  esc                         | pld csi
/12 np  fs                          | plu st
/13 cr  gs                          | ri  osc
/14 so  rs                          | ss2 pm
/15 si  us                          | ss3 apc

For example, if you send 0x8d to an xterm, it ought to interpret it the
same way it would interpret the two-character sequence ESC M: it should
perform a reverse-index operation.  (If 0x8d and 0x1b-plus-0x4d are not
the same, I would definitely call it a bug; if they are the same but it
doesn't cause a reverse-index operation, that I would maintain is a bug
as well, though a different bug.)

Of course, whether it's truly a bug or not is somewhat unclear.  What,
after all, is the spec for xterm?

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.

In any case, I would argue that not treating such bytes as printable
characters is not a bug.

					der Mouse

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