Bug#179407: xterm: not only bold fonts do not work with widechars
On Fri, 23 Apr 2004, Thomas Dickey wrote: > > *utf8: 2 > > > > differs from -u8 command line option. If I understand the manual right > > this should not be the case. > > I'll take another look this afternoon. It occurs to me that your environment > was perhaps the UTF-8 flavor rather than the euro one, and that some part of > the gdm/xrdb/X11 code may treat the resource setting differently. Thanks. Feel free to ask me for further information / tests. Kind regards and thanks for caring for xterm Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Fri, Apr 23, 2004 at 07:29:04AM +0200, Andreas Tille wrote: > On Thu, 22 Apr 2004, Thomas Dickey wrote: > > > It really sounds as if you are running into more/less expected problems > > with applications (not particularly xterm) that do not work with UTF-8. > Sure - as I said my belover MC is one of them. BUt I wanted to give > the transition a start, once Debian changelogs start loocking fancy on > my side because of UTF-8 codings. > > > For instance, I see that the Debian package for mc is built using the > > internal version of slang (and to satisfy some issue with gpm, also > > ncurses - which can be confusing). > Yes. Also manpages loocked strange but I suspected that it is connected > to the xterm problems, but I'm not sure. Such as the soft-hyphens at the ends of lines (that's partly a font problem, partly how the pager is setup). For the font, since it was an 8859 (8-bit) font, codes past 255 would show up as missing glyphs. > > While there is an unofficial patch for slang to handle UTF-8, I'm told > > that it is incomplete and not very robust. Without that patch, slang > > can handle only 8-bit encodings (such as the ISO-8859-1 to ISO-8859-15). > > In UTF-8, the characters in the range 160-255 are not sent as a single > > byte but as two or more. If the application does not know how to do > > this, the terminal running in UTF-8 mode is likely to treat those as > > incomplete sequences and doesn't show the characters that were intended. > Well I just regard my first attempt to switch to UTF-8 as failed and > went back to my normal work, waiting for further enhancements. On the > other hand I think we should clarify why the resource setting of > > *utf8: 2 > > differs from -u8 command line option. If I understand the manual right > this should not be the case. I'll take another look this afternoon. It occurs to me that your environment was perhaps the UTF-8 flavor rather than the euro one, and that some part of the gdm/xrdb/X11 code may treat the resource setting differently. > Kind regards > > Andreas. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpo3r8GFzElP.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Thu, 22 Apr 2004, Thomas Dickey wrote: > It really sounds as if you are running into more/less expected problems > with applications (not particularly xterm) that do not work with UTF-8. Sure - as I said my belover MC is one of them. BUt I wanted to give the transition a start, once Debian changelogs start loocking fancy on my side because of UTF-8 codings. > For instance, I see that the Debian package for mc is built using the > internal version of slang (and to satisfy some issue with gpm, also > ncurses - which can be confusing). Yes. Also manpages loocked strange but I suspected that it is connected to the xterm problems, but I'm not sure. > While there is an unofficial patch for slang to handle UTF-8, I'm told > that it is incomplete and not very robust. Without that patch, slang > can handle only 8-bit encodings (such as the ISO-8859-1 to ISO-8859-15). > In UTF-8, the characters in the range 160-255 are not sent as a single > byte but as two or more. If the application does not know how to do > this, the terminal running in UTF-8 mode is likely to treat those as > incomplete sequences and doesn't show the characters that were intended. Well I just regard my first attempt to switch to UTF-8 as failed and went back to my normal work, waiting for further enhancements. On the other hand I think we should clarify why the resource setting of *utf8: 2 differs from -u8 command line option. If I understand the manual right this should not be the case. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Thu, Apr 22, 2004 at 05:01:06PM +0200, Andreas Tille wrote: > ~> cat /etc/environment > ### BEGIN DEBCONF SECTION FOR localeconf > # Do not edit within this region if you want your changes to be preserved > # by debconf. Instead, make changes before the "### BEGIN DEBCONF SECTION > # FOR localeconf" line, and/or after the "### END DEBCONF SECTION FOR > # localeconf" line. > [EMAIL PROTECTED] > ### END DEBCONF SECTION FOR localeconf > > is fine. But if > >[EMAIL PROTECTED] > > is set I run into exactly the trouble I observed. I have to admit that It really sounds as if you are running into more/less expected problems with applications (not particularly xterm) that do not work with UTF-8. For instance, I see that the Debian package for mc is built using the internal version of slang (and to satisfy some issue with gpm, also ncurses - which can be confusing). I test-built mc about a year ago with ncursesw (the configuration that can handle UTF-8), but noticed a few unrelated bugs in mc's code for keyboard entry (the display was acceptable though). From my perspective, it would probably be less work to fix those bugs (and use ncursesw) than to make slang properly handle UTF-8. While there is an unofficial patch for slang to handle UTF-8, I'm told that it is incomplete and not very robust. Without that patch, slang can handle only 8-bit encodings (such as the ISO-8859-1 to ISO-8859-15). In UTF-8, the characters in the range 160-255 are not sent as a single byte but as two or more. If the application does not know how to do this, the terminal running in UTF-8 mode is likely to treat those as incomplete sequences and doesn't show the characters that were intended. > I lost my nerve to test UTF-8 issues more deeply and switched back to > the working settings. But I'm willing to do anything for debugging > if you ask me so. > > Kind regards > > Andreas. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpX3RXRjHB4v.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Thu, 22 Apr 2004, Thomas Dickey wrote: > > I have to verify this at home this evening. After comparison of the different configurations of a machine that works and the problematic machine I found out the following: ~> cat /etc/environment ### BEGIN DEBCONF SECTION FOR localeconf # Do not edit within this region if you want your changes to be preserved # by debconf. Instead, make changes before the "### BEGIN DEBCONF SECTION # FOR localeconf" line, and/or after the "### END DEBCONF SECTION FOR # localeconf" line. [EMAIL PROTECTED] ### END DEBCONF SECTION FOR localeconf is fine. But if [EMAIL PROTECTED] is set I run into exactly the trouble I observed. I have to admit that I lost my nerve to test UTF-8 issues more deeply and switched back to the working settings. But I'm willing to do anything for debugging if you ask me so. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Thu, 22 Apr 2004, Thomas Dickey wrote: > MidnightCommander often is using slang, which has some odd locale behavior. Well - I guess it is just #242194 and has nothing to do with our problem. It would just be the reason to switch back to [EMAIL PROTECTED] and leave the UTF-8 issue for the time when mc is fixed. (I'm adictive since my first DOS days ... ;-) ). > But ssh's locale issues I'm not sure of - haven't seen any comments. This happened after ssh-ing from my home box after setting [EMAIL PROTECTED] to a box which hat the setting [EMAIL PROTECTED] May be I should try master or people to reduce the unknown part for you to my box at home which has the problem. At work I leave my X session normally open but I tried to verify the problem here. As I said, I observed the trouble after upgrading gdm at home. Here at work gmd was upgraded as well but not restarted (because of the open X session). Now I tried it and all works fine. I now copied /etc/X11/Xresources/xterm (which does not set any utf8 stuff) /etc/gdm/ /etc/language /etc/environment and will compare it with the files at home. If you know other relevant files please tell me. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Thu, Apr 22, 2004 at 08:00:59AM +0200, Andreas Tille wrote: > On Wed, 21 Apr 2004, Thomas Dickey wrote: > > > Perhaps that is relevant. I setup gdm/sawfish with the [EMAIL PROTECTED] > > locale, > > using the /etc/X11/Xresources/xterm file (except for the fix for geometry), > > and do not see any problem entering or displaying 8-bit characters. For > > displaying, I'm using ncurses' test program, for entering I simply use my > > alt-key. > I try to switch back locale settings to [EMAIL PROTECTED] (which was my > setting > once I run into this trouble - tried to change afterwards to [EMAIL > PROTECTED]). > I can't remember exactly what happened and try to describe it as detailed > as possible. > > After I was setting locale to [EMAIL PROTECTED] the situation became even > worse. > MidnightCommander is a real mess and ssh to other hosts shows several trouble. > > I have to verify this at home this evening. thanks. MidnightCommander often is using slang, which has some odd locale behavior. But ssh's locale issues I'm not sure of - haven't seen any comments. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpTchmyO1brw.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Wed, 21 Apr 2004, Thomas Dickey wrote: > Perhaps that is relevant. I setup gdm/sawfish with the [EMAIL PROTECTED] > locale, > using the /etc/X11/Xresources/xterm file (except for the fix for geometry), > and do not see any problem entering or displaying 8-bit characters. For > displaying, I'm using ncurses' test program, for entering I simply use my > alt-key. I try to switch back locale settings to [EMAIL PROTECTED] (which was my setting once I run into this trouble - tried to change afterwards to [EMAIL PROTECTED]). I can't remember exactly what happened and try to describe it as detailed as possible. After I was setting locale to [EMAIL PROTECTED] the situation became even worse. MidnightCommander is a real mess and ssh to other hosts shows several trouble. I have to verify this at home this evening. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Wed, Apr 21, 2004 at 12:31:21PM +0200, Andreas Tille wrote: > Interestingly enough this UTF-8 issue broke only on one of three boxes, but > I guess I have different /etc/environment and /etc/language settings on > each (not intentionally but historically). Perhaps that is relevant. I setup gdm/sawfish with the [EMAIL PROTECTED] locale, using the /etc/X11/Xresources/xterm file (except for the fix for geometry), and do not see any problem entering or displaying 8-bit characters. For displaying, I'm using ncurses' test program, for entering I simply use my alt-key. > Feel free to ask me for any further information which might be helpful. > > Kind regards > > Andreas. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpmZff12yi4V.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Wed, Apr 21, 2004 at 08:27:37AM +0200, Andreas Tille wrote: > On Tue, 20 Apr 2004, Thomas Dickey wrote: > > The manpage isn't explicit (does not state the value is an integer). > > It quotes the default value, which shows its type: > > > > utf8 (class Utf8) > > This specifies whether xterm will run in UTF-8 mode. > > If you set this resource, xterm also sets the > > wideChars resource as a side-effect. When set via a > > resource, xterm cannot be switched via control > > sequences out of UTF-8 mode. The default is ``0'' > > (off). Any other value will turn on UTF-8 mode. > Because you seem to know it exactly: Could you please file a bug against > this man page? Andreas, Just FYI: Thomas Dickey is the upstream maintainer of XTerm, and has been for the past several years. -- G. Branden Robinson| Religion is excellent stuff for Debian GNU/Linux | keeping common people quiet. [EMAIL PROTECTED] | -- Napoleon Bonaparte http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Wed, Apr 21, 2004 at 12:31:21PM +0200, Andreas Tille wrote: > On Wed, 21 Apr 2004, Thomas Dickey wrote: > > > The effect on my box (for just that resource setting) doesn't seem to make > > a difference. But that's running from the command-line. As you suggest, > > I'll > > setup some tests using the xrdb files. (Now that my attention is there - is > > there a separate Debian package for the files in /etc/X11/Xresources, or are > > these your own files?) > A 'dpkg -S' gave no match and thus I guess I created them by my own ages ago. > Perhaps they were part of some older packages and remained on my box because > I added some stuff. for a start, I have the file as given in the original report. > > > Because you seem to know it exactly: Could you please file a bug against > > > this man page? > > > > I do use these emails to make my to-do list. > OK. Thanks for caring about that. no problem > > > Not really. At least I do not have a working xterm since the last GDM > > > upgrade and if we do not find a solution for this (which should be > > > documented, > > > sure) than it is more than a documentation issue. > > > > I'll do that (normally I'm running testing with startx/fvwm, but do have gdm > > installed - was still picking through the development things that got broken > > by the recent updates). > Interestingly enough this UTF-8 issue broke only on one of three boxes, but > I guess I have different /etc/environment and /etc/language settings on > each (not intentionally but historically). > > Feel free to ask me for any further information which might be helpful. ok (this evening). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpkaytAGPbTZ.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Wed, 21 Apr 2004, Thomas Dickey wrote: > The effect on my box (for just that resource setting) doesn't seem to make > a difference. But that's running from the command-line. As you suggest, I'll > setup some tests using the xrdb files. (Now that my attention is there - is > there a separate Debian package for the files in /etc/X11/Xresources, or are > these your own files?) A 'dpkg -S' gave no match and thus I guess I created them by my own ages ago. Perhaps they were part of some older packages and remained on my box because I added some stuff. > > Because you seem to know it exactly: Could you please file a bug against > > this man page? > > I do use these emails to make my to-do list. OK. Thanks for caring about that. > > Not really. At least I do not have a working xterm since the last GDM > > upgrade and if we do not find a solution for this (which should be > > documented, > > sure) than it is more than a documentation issue. > > I'll do that (normally I'm running testing with startx/fvwm, but do have gdm > installed - was still picking through the development things that got broken > by the recent updates). Interestingly enough this UTF-8 issue broke only on one of three boxes, but I guess I have different /etc/environment and /etc/language settings on each (not intentionally but historically). Feel free to ask me for any further information which might be helpful. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Wed, Apr 21, 2004 at 08:27:37AM +0200, Andreas Tille wrote: > On Tue, 20 Apr 2004, Thomas Dickey wrote: > > > > ~> grep -i utf /etc/X11/Xresources/* > > > /etc/X11/Xresources/uxterm:UXTerm*utf8: on > > > > that would be ignored. > It is not: uxterm works - at least on the local box if I ignore all other > stuff. The effect on my box (for just that resource setting) doesn't seem to make a difference. But that's running from the command-line. As you suggest, I'll setup some tests using the xrdb files. (Now that my attention is there - is there a separate Debian package for the files in /etc/X11/Xresources, or are these your own files?) > > > /etc/X11/Xresources/xterm:XTerm*utf8: 2 > > > > that might be used (depending on the script). I don't use xrdb. > > > > The manpage isn't explicit (does not state the value is an integer). > > It quotes the default value, which shows its type: > > > > utf8 (class Utf8) > > This specifies whether xterm will run in UTF-8 mode. > > If you set this resource, xterm also sets the > > wideChars resource as a side-effect. When set via a > > resource, xterm cannot be switched via control > > sequences out of UTF-8 mode. The default is ``0'' > > (off). Any other value will turn on UTF-8 mode. > Because you seem to know it exactly: Could you please file a bug against > this man page? I do use these emails to make my to-do list. > > > I did not changed this uxterm but I regard this uxterm as a really > > > bad missconception. For instance if you log in anywhere you have > > > to define a new TERM variable and whatever. Moreover, regarding to > > > your mail before it is set to 'on' instead to an integer. What's > > > wrong here. > > > > no - I stated > > > > "on" wouldn't work, since this resource happens to be an integer. > Sorry, for quoting you wrong: I ment uxterm is set wrong according to > your opinion, but it works. (Just try it.) > > > > When I had no characters at the places of Umlauts I was using > > > > > > [EMAIL PROTECTED] > > > [EMAIL PROTECTED] > > > > > > I now switched to > > > > > > [EMAIL PROTECTED] > > > [EMAIL PROTECTED] > > > > > > The result is different but not better: ä instead of ä (a-Umlaut), > > > etc - just two charcters. > > > > > > Note: All this happens with plain resource settings (see above). An > > >xterm -u8 > > > works fine. > > > > > > If you ask me I would like to change the severity of this bug to > > > important, > > > because ist really smells like a missinterpretation of resources settings. > > > > so far it sounds like a documentation issue. > Not really. At least I do not have a working xterm since the last GDM > upgrade and if we do not find a solution for this (which should be documented, > sure) than it is more than a documentation issue. I'll do that (normally I'm running testing with startx/fvwm, but do have gdm installed - was still picking through the development things that got broken by the recent updates). > Kind regards > > Andreas. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp16gVqP0OTy.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Tue, 20 Apr 2004, Thomas Dickey wrote: > > ~> grep -i utf /etc/X11/Xresources/* > > /etc/X11/Xresources/uxterm:UXTerm*utf8: on > > that would be ignored. It is not: uxterm works - at least on the local box if I ignore all other stuff. > > /etc/X11/Xresources/xterm:XTerm*utf8: 2 > > that might be used (depending on the script). I don't use xrdb. > > The manpage isn't explicit (does not state the value is an integer). > It quotes the default value, which shows its type: > > utf8 (class Utf8) > This specifies whether xterm will run in UTF-8 mode. > If you set this resource, xterm also sets the > wideChars resource as a side-effect. When set via a > resource, xterm cannot be switched via control > sequences out of UTF-8 mode. The default is ``0'' > (off). Any other value will turn on UTF-8 mode. Because you seem to know it exactly: Could you please file a bug against this man page? > > I did not changed this uxterm but I regard this uxterm as a really > > bad missconception. For instance if you log in anywhere you have > > to define a new TERM variable and whatever. Moreover, regarding to > > your mail before it is set to 'on' instead to an integer. What's > > wrong here. > > no - I stated > > "on" wouldn't work, since this resource happens to be an integer. Sorry, for quoting you wrong: I ment uxterm is set wrong according to your opinion, but it works. (Just try it.) > > When I had no characters at the places of Umlauts I was using > > > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > I now switched to > > > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > The result is different but not better: À instead of À (a-Umlaut), > > etc - just two charcters. > > > > Note: All this happens with plain resource settings (see above). An > >xterm -u8 > > works fine. > > > > If you ask me I would like to change the severity of this bug to important, > > because ist really smells like a missinterpretation of resources settings. > > so far it sounds like a documentation issue. Not really. At least I do not have a working xterm since the last GDM upgrade and if we do not find a solution for this (which should be documented, sure) than it is more than a documentation issue. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Tue, Apr 20, 2004 at 08:59:04PM +0200, Andreas Tille wrote: > > > However. The command-line options of xterm simply set specific resource > > patterns and can be overridden by other resource patterns that are more > > specific. The "XTerm*utf8" pattern would not be overridden in a case where > > the > > other would (if there were already a "*utf8" pattern lurking in your > > resources). > > ~> grep -i utf /etc/X11/Xresources/* > /etc/X11/Xresources/uxterm:UXTerm*utf8: on that would be ignored. > /etc/X11/Xresources/xterm:XTerm*utf8: 2 that might be used (depending on the script). I don't use xrdb. The manpage isn't explicit (does not state the value is an integer). It quotes the default value, which shows its type: utf8 (class Utf8) This specifies whether xterm will run in UTF-8 mode. If you set this resource, xterm also sets the wideChars resource as a side-effect. When set via a resource, xterm cannot be switched via control sequences out of UTF-8 mode. The default is ``0'' (off). Any other value will turn on UTF-8 mode. > I did not changed this uxterm but I regard this uxterm as a really > bad missconception. For instance if you log in anywhere you have > to define a new TERM variable and whatever. Moreover, regarding to > your mail before it is set to 'on' instead to an integer. What's > wrong here. no - I stated "on" wouldn't work, since this resource happens to be an integer. > > Perhaps that's what is happening: if your locale is not de_DE.UTF-8, then > > forcing UTF-8 output could cause the output of umlauts to be lost. (My > > impression is that the euro locales are 8-bit encodings, while UTF-8 is > > multibyte - and codes in the range 128-255 are interpreted differently). > When I had no characters at the places of Umlauts I was using > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > I now switched to > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > The result is different but not better: instead of ?? (a-Umlaut), > etc - just two charcters. > > Note: All this happens with plain resource settings (see above). An >xterm -u8 > works fine. > > If you ask me I would like to change the severity of this bug to important, > because ist really smells like a missinterpretation of resources settings. so far it sounds like a documentation issue. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgph1WezUWSu6.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Mon, 19 Apr 2004, Thomas Dickey wrote: > > But the real Problem remains: Even > > > > XTerm*utf8: 2 > > > > does not fix the missing Umlauts (just blanks) but xterm -ut8 works > > fine. > > "-u8" (but your earlier email did state that). Sure - this was a typo. > However. The command-line options of xterm simply set specific resource > patterns and can be overridden by other resource patterns that are more > specific. The "XTerm*utf8" pattern would not be overridden in a case where > the > other would (if there were already a "*utf8" pattern lurking in your > resources). ~> grep -i utf /etc/X11/Xresources/* /etc/X11/Xresources/uxterm:UXTerm*utf8: on /etc/X11/Xresources/xterm:XTerm*utf8: 2 I did not changed this uxterm but I regard this uxterm as a really bad missconception. For instance if you log in anywhere you have to define a new TERM variable and whatever. Moreover, regarding to your mail before it is set to 'on' instead to an integer. What's wrong here. > Perhaps that's what is happening: if your locale is not de_DE.UTF-8, then > forcing UTF-8 output could cause the output of umlauts to be lost. (My > impression is that the euro locales are 8-bit encodings, while UTF-8 is > multibyte - and codes in the range 128-255 are interpreted differently). When I had no characters at the places of Umlauts I was using [EMAIL PROTECTED] [EMAIL PROTECTED] I now switched to [EMAIL PROTECTED] [EMAIL PROTECTED] The result is different but not better: À instead of À (a-Umlaut), etc - just two charcters. Note: All this happens with plain resource settings (see above). An xterm -u8 works fine. If you ask me I would like to change the severity of this bug to important, because ist really smells like a missinterpretation of resources settings. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Mon, Apr 19, 2004 at 09:25:54PM +0200, Andreas Tille wrote: > On Mon, 19 Apr 2004, Thomas Dickey wrote: > > > To do this, you have to limit it to the vt100 window: > > > > http://invisible-island.net/xterm/xterm.faq.html#tiny_menus > OK, then this is not really important to me ... > > But the real Problem remains: Even > > XTerm*utf8: 2 > > does not fix the missing Umlauts (just blanks) but xterm -ut8 works > fine. "-u8" (but your earlier email did state that). However. The command-line options of xterm simply set specific resource patterns and can be overridden by other resource patterns that are more specific. The "XTerm*utf8" pattern would not be overridden in a case where the other would (if there were already a "*utf8" pattern lurking in your resources). Perhaps that's what is happening: if your locale is not de_DE.UTF-8, then forcing UTF-8 output could cause the output of umlauts to be lost. (My impression is that the euro locales are 8-bit encodings, while UTF-8 is multibyte - and codes in the range 128-255 are interpreted differently). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp5xkMSOXvrw.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Mon, 19 Apr 2004, Thomas Dickey wrote: > To do this, you have to limit it to the vt100 window: > > http://invisible-island.net/xterm/xterm.faq.html#tiny_menus OK, then this is not really important to me ... But the real Problem remains: Even XTerm*utf8: 2 does not fix the missing Umlauts (just blanks) but xterm -ut8 works fine. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
On Fri, Apr 16, 2004 at 10:30:15AM +0200, Andreas Tille wrote: > I might like to add that > > xterm -u8 That has the same effect as XTerm*utf8: 2 I added some traces to my current version, but don't see any differences between the traces from invoking this with the command-line versus using the resource directly. Perhaps there are additional resource settings that "appres XTerm" might show, which influence the result. > works like a charm and so I guess it's only a question of parsing the > resource file where > > XTerm*utf8: 1 > > (I also tried "XTerm*utf8: on") is simply ignored. "on" wouldn't work, since this resource happens to be an integer. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpQzg9JGlX0R.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
On Thu, Apr 15, 2004 at 06:00:50PM +0200, Andreas Tille wrote: > Hi, > > after latest upgrade of gdm I'm facing the problem which was > described in this bug report. I'm simulating a new bug report > to provide the necessary info: > > No other characters than 7-bit ASCII are displayed at all > with the following configuration: That sounds like the eightBitInput resource is off - but I don't see this when I try testing it. > ~> cat /etc/X11/Xresources/xterm ... > XTerm*geometry: 83x28 this line is incorrect (different problem). It makes the popup menus not work. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpqIEnpX2fxU.pgp Description: PGP signature
Bug#179407: xterm: not only bold fonts do not work with widechars
I might like to add that xterm -u8 works like a charm and so I guess it's only a question of parsing the resource file where XTerm*utf8: 1 (I also tried "XTerm*utf8: on") is simply ignored. Kind regards Andreas.
Bug#179407: xterm: not only bold fonts do not work with widechars
Hi, after latest upgrade of gdm I'm facing the problem which was described in this bug report. I'm simulating a new bug report to provide the necessary info: No other characters than 7-bit ASCII are displayed at all with the following configuration: ~> cat /etc/X11/Xresources/xterm xterm*font: -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso8859-15 Rxvt.keysym.Delete: \b Rxvt.termName: xterm XTerm*decTerminalID: 200 XTerm*color0: black XTerm*color1: red XTerm*color2: green XTerm*color3: yellow XTerm*color4: blue XTerm*color5: magenta XTerm*color6: cyan XTerm*color7: white XTerm*color8: black XTerm*color9: red XTerm*color10: green XTerm*color11: yellow XTerm*color12: blue XTerm*color13: magenta XTerm*color14: cyan XTerm*color15: white XTerm*termName: xterm XTerm*title: XTerm XTerm*colorMode: on XTerm*background: darkblue XTerm*foreground: white XTerm*loginShell: true XTerm*dynamicColors: on XTerm*geometry: 83x28 XTerm*visualBell: true XTerm*utf8: 1 -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (499, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.23 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages xterm depends on: ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig1 2.2.2-1 generic font configuration library ii libfreetype62.1.7-2 FreeType 2 font engine, shared lib ii libice6 4.3.0-7 Inter-Client Exchange library ii libncurses5 5.4-3Shared libraries for terminal hand ii libsm6 4.3.0-7 X Window System Session Management ii libxaw7 4.3.0-7 X Athena widget set library ii libxext64.3.0-7 X Window System miscellaneous exte ii libxft2 2.1.2-6 FreeType-based font drawing librar ii libxmu6 4.3.0-7 X Window System miscellaneous util ii libxpm4 4.3.0-7 X pixmap library ii libxrender1 0.8.3-7 X Rendering Extension client libra ii libxt6 4.3.0-7 X Toolkit Intrinsics ii xlibs 4.3.0-7 X Window System client libraries m ii xlibs-data 4.3.0-7 X Window System client data -- debconf information: xterm/clobber_xresource_file: true xterm/xterm_needs_devpts:
