Bug#418324: marked as done (xterm: baffling weirdness with 9x15 font and some Unicode glyphs)
Your message dated Wed, 26 Sep 2012 06:43:40 -0400 with message-id <20120926104340.ga7...@aerie.jexium-island.net> and subject line Re: #418324 xterm: baffling weirdness with 9x15 font and some Unicode glyphs has caused the Debian Bug report #418324, regarding xterm: baffling weirdness with 9x15 font and some Unicode glyphs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 418324: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418324 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: xterm Version: 222-3 Severity: normal Tags: upstream This is an upstream issue, I'll wager. The root of my complaint is that the Unicode glyphs LEFT-POINTING ANGLE BRACKET (U+2329) and RIGHT-POINTING ANGLE BRACKET (U+232A) don't render when I size my xterms up to the "Large" font. This was brought to my attention because GNU roff renders URLs between these glyphs in UTF-8 environments. (On a Debian system, an example of a manpage that uses the .URL macro is "update-fonts-alias", but there are many others.) At first I thought this was just an oversight in the 9x15 font, as those glyphs render fine. So fired up gbdfed to have a look, intending to draw my own glyphs and submit a patch. Imagine my surprise when I found that the font does define glyphs there. Next I thought, well, maybe the bounding box is wrong, or it's declared as a normal-width character but is really double-width. Those guesses appear to be wrong, too: STARTCHAR angleleft ENCODING 9001 SWIDTH 576 0 DWIDTH 9 0 BBX 9 15 0 -3 BITMAP 0400 0400 0800 0800 1000 1000 0800 0800 0400 0400 ENDCHAR STARTCHAR angleright ENCODING 9002 SWIDTH 576 0 DWIDTH 9 0 BBX 9 15 0 -3 BITMAP 1000 1000 0800 0800 0400 0400 0800 0800 1000 1000 ENDCHAR I'm not really clear on what SWIDTH and DWIDTH are, but they (and the bounding box "BBOX") are the same as glyph 9000 (U+2328 "KEYBOARD"), which renders fine. So then I thought maybe it's a bug in xterm. After floundering a bit, because konsole doesn't want to play with bitmap fonts and fails to "install" them when its convoluted dialogs offer to, and gnome-terminal wanted to install a few dozen megs of dependencies, including Epiphrany and dvd+rw-tools (?!), I settled on rxvt-unicode-ml. I was in for another surprise. urxvt displays the glyphs correctly -- but then so does xterm, when I launch it manually! (Usually I just let the session manager start all the xterms I use.) What's more, both urxvt and xterm suddenly forget how to render U+2328 and U+232B ("ERASE TO THE LEFT"), which my usual xterms that can't render angle brackets handle just fine! There is one difference between urxvt and xterm -- the angle bracket glyphs I *do* get look right on urxvt, but xterm is showing me some ugly stuff that reminds me of the semigraphics characters on the TRS-80 Model I. I've worked with X for a long time but this has me stumped. What on earth is going on? Here's my $HOME/.Xresources; as you can see, I don't change XTerm's fonts: ! Personal Xresources file XClipboard*Form*Text*font: fixed XConsole.verbose: true XConsole*iconic:false XConsole*geometry: 1272x89+0-58 XConsole*saveLines: 1000 XConsole*font: 6x10 XTerm*autoWrap: true XTerm*curses: true XTerm*loginShell: true XTerm*reverseWrap: true XTerm*scrollBar:true XTerm*saveLines:5000 XTerm*scrollTtyOutput: false XTerm*trimSelection:true XTerm*visualBell: true XTerm*activeIcon: true XTerm.VT100.background: gray30 XTerm.VT100.foreground: gray90 XTerm.VT100.geometry: 200x67-0+0 XTerm.VT100.color4: DodgerBlue1 XTerm.VT100.color8: gray50 XTerm.VT100.color12:SteelBlue1 XTerm.VT100.scrollbar.background: white XTerm.VT100.scrollbar.foreground: blue UXTerm*autoWrap:true UXTerm*curses: true UXTerm*loginShell: true UXTerm*reverseWrap: true UXTerm*scrollBar: true UXTerm*saveLines: 5000 UXTerm*scrollTtyOutput: false UXTerm*trimSelection: true UXTerm*visualBell: true UXTerm*activeIcon: true UXTerm.VT100.background:gray30 UXTerm.VT100.foreground:gray90 UXTerm.VT100.geometry: 200x67-0+0 UXTerm.VT100.color4:DodgerBlue1 UXTerm.VT100.color8:gray50 UXTerm.VT100.color12: SteelBlue1 UXTerm.VT100.scrollbar.background: white UXTerm.VT100.scrollbar.foreground: blue XCalc*IconName: xcalc XLock.st
Bug#418324: marked as done (xterm: baffling weirdness with 9x15 font and some Unicode glyphs)
Your message dated Mon, 18 Jun 2007 13:47:09 + with message-id <[EMAIL PROTECTED]> and subject line Bug#418324: fixed in xterm 226-1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: xterm Version: 222-3 Severity: normal Tags: upstream This is an upstream issue, I'll wager. The root of my complaint is that the Unicode glyphs LEFT-POINTING ANGLE BRACKET (U+2329) and RIGHT-POINTING ANGLE BRACKET (U+232A) don't render when I size my xterms up to the "Large" font. This was brought to my attention because GNU roff renders URLs between these glyphs in UTF-8 environments. (On a Debian system, an example of a manpage that uses the .URL macro is "update-fonts-alias", but there are many others.) At first I thought this was just an oversight in the 9x15 font, as those glyphs render fine. So fired up gbdfed to have a look, intending to draw my own glyphs and submit a patch. Imagine my surprise when I found that the font does define glyphs there. Next I thought, well, maybe the bounding box is wrong, or it's declared as a normal-width character but is really double-width. Those guesses appear to be wrong, too: STARTCHAR angleleft ENCODING 9001 SWIDTH 576 0 DWIDTH 9 0 BBX 9 15 0 -3 BITMAP 0400 0400 0800 0800 1000 1000 0800 0800 0400 0400 ENDCHAR STARTCHAR angleright ENCODING 9002 SWIDTH 576 0 DWIDTH 9 0 BBX 9 15 0 -3 BITMAP 1000 1000 0800 0800 0400 0400 0800 0800 1000 1000 ENDCHAR I'm not really clear on what SWIDTH and DWIDTH are, but they (and the bounding box "BBOX") are the same as glyph 9000 (U+2328 "KEYBOARD"), which renders fine. So then I thought maybe it's a bug in xterm. After floundering a bit, because konsole doesn't want to play with bitmap fonts and fails to "install" them when its convoluted dialogs offer to, and gnome-terminal wanted to install a few dozen megs of dependencies, including Epiphrany and dvd+rw-tools (?!), I settled on rxvt-unicode-ml. I was in for another surprise. urxvt displays the glyphs correctly -- but then so does xterm, when I launch it manually! (Usually I just let the session manager start all the xterms I use.) What's more, both urxvt and xterm suddenly forget how to render U+2328 and U+232B ("ERASE TO THE LEFT"), which my usual xterms that can't render angle brackets handle just fine! There is one difference between urxvt and xterm -- the angle bracket glyphs I *do* get look right on urxvt, but xterm is showing me some ugly stuff that reminds me of the semigraphics characters on the TRS-80 Model I. I've worked with X for a long time but this has me stumped. What on earth is going on? Here's my $HOME/.Xresources; as you can see, I don't change XTerm's fonts: ! Personal Xresources file XClipboard*Form*Text*font: fixed XConsole.verbose: true XConsole*iconic:false XConsole*geometry: 1272x89+0-58 XConsole*saveLines: 1000 XConsole*font: 6x10 XTerm*autoWrap: true XTerm*curses: true XTerm*loginShell: true XTerm*reverseWrap: true XTerm*scrollBar:true XTerm*saveLines:5000 XTerm*scrollTtyOutput: false XTerm*trimSelection:true XTerm*visualBell: true XTerm*activeIcon: true XTerm.VT100.background: gray30 XTerm.VT100.foreground: gray90 XTerm.VT100.geometry: 200x67-0+0 XTerm.VT100.color4: DodgerBlue1 XTerm.VT100.color8: gray50 XTerm.VT100.color12:SteelBlue1 XTerm.VT100.scrollbar.background: white XTerm.VT100.scrollbar.foreground: blue UXTerm*autoWrap:true UXTerm*curses: true UXTerm*loginShell: true UXTerm*reverseWrap: true UXTerm*scrollBar: true UXTerm*saveLines: 5000 UXTerm*scrollTtyOutput: false UXTerm*trimSelection: true UXTerm*visualBell: true UXTerm*activeIcon: true UXTerm.VT100.background:gray30 UXTerm.VT100.foreground:gray90 UXTerm.VT100.geometry: 200x67-0+0 UXTerm.VT100.color4:DodgerBlue1 UXTerm.VT100.color8:gray50 UXTerm.VT100.color12: SteelBlue1 UXTerm.VT100.scrollbar.background: white UXTerm.VT100.scrollbar.foreground: blue XCalc*IconName: xcalc XLock.star.delay: 2 XLock.star.batchcount: 100 XLock.star.saturation: 1.0 XLock.star.rock: on XLock.star.trek: 0 ! vim:ai:noet:sts=8:sw=8:tw=0: -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable'), (500,