dgreen@arnor.uucp (02/02/91)
I want an xterm window to display the pound-sterling when
I press KP_Subtract. So I use
XTerm*VT100.Translations: #override: \
<Key>KP_Subtract: string(0x9c) \n
It sends the 9c to the process reading from the terminal, OK. But nothing gets
displayed on the screen.
How can I make xterm display this (or any other 8-bit character)?
____
\ /Dan Greening IBM T.J.Watson Research Center NY (914) 784-7861
\/ dgreen@cs.ucla.edu Yorktown Heights, NY 10598-0704 CA (213) 825-2266gildea@expo.lcs.mit.EDU (Stephen Gildea) (02/05/91)
Can this be fixed for R5 and
who (if anyone) deals with further mangling of poor, old xterm.
xterm, like all programs in the "mit" directory tree of the X distribution,
is maintained by the MIT X Consortium staff. The best way to get it fixed
is to submit a bug report to xbugs@expo.lcs.mit.edu.
To make your report most useful, please use the bug report template in
mit/doc/bugs/bug-report, give your message a helpful subject line, tell
exactly how to reproduce the problem, and include diffs to fix it.
< Stephen
MIT X Consortiumscott@graft.Berkeley.EDU (Scott Silvey) (02/05/91)
(Dan R. Greening) writes: |>I want an xterm window to display the pound-sterling when |>I press KP_Subtract. So I use I think you have to put the terminal into 8bit graphic character mode ... Try <escape>(0 to start graphics mode and <escape>(B to end graphics mode. I believe the pound sign is '}'. PS: I have a few sample text files that draw boxes and stuff if anyone wants examples. PPS: Some fonts have glyphs for the 8bit characters and some don't. The standard fixed width fonts ("6x13" for example) do have 8 bit characters. /-----------------------------------------------------------------------------\ | Scott Silvey | DOD Spokesman Pete Williams on Cruise Missiles: | | scott@xcf.berkeley.edu | "We just don't discuss that capability. I can't | | | tell you why we don't discuss it because then I'd | | Flames to /dev/null | be discussing it." | \-----------------------------------------------------------------------------/
mouse@lightning.mcrcim.mcgill.EDU (02/06/91)
>> 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
sinkwitz@ifi.unizh.ch (Rainer Sinkwitz) (02/07/91)
I had to issue "stty cs8 pass8"
for OpenWindows on my Sun and get 8-Bit characters since then.
The full entry was:
#----------------------- OpenWindows
setenv OPENWINHOME /usr/local/openwin
setenv LC_TYPE iso_8859_1
stty cs8 pass8
Perhaps it also depends on the LC_TYPE setting.
--
Rainer Sinkwitz | E-mail: sinkwitz@ifi.unizh.ch
Dept. of Computer Science | {backbone}!mcsun!unizh!sinkwitz
University of Zuerich | K114970@CZHRZU1A.bitnetdgreen@arnor.uucp (02/11/91)
mouse@lightning.mcrcim.mcgill.EDU writes: |> > 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 ... control character spec ... |> 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. The set of printable characters should depend on some specification in the app-defaults file, no? (BTW, I am not using an ISO 8859-1 character set.) In any event, not being an internationalization expert, but trying to produce an xterm for some british clients, I'm not exactly sure what the control character set is there. Time for a hack, I guess. (Ugh.) I hope R5 has a configurable display character set for xterm. ____ \ /Dan Greening IBM T.J.Watson Research Center NY (914) 784-7861 \/ dgreen@ibm.com Yorktown Heights, NY 10598-0704 CA (213) 825-2266
mouse@lightning.mcrcim.mcgill.EDU (02/13/91)
>>> 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