When UNICODE="yes" is set in /etc/rc.conf, programs using line-drawing characters (like menuconfig, alsamixer, mc, and many ncurses-based) dont show lines. Ncurses and all packages are compiled with the unicode flag set. Im using a font with unicode support ".psfu.gz" in /usr/share/consolefonts Not that in urxvt, the problem doesnt happen. Reproducible: Always Steps to Reproduce: 1.Edit /etc/rc.conf and add UNICODE="yes" 2.Reboot system 3.cd /usr/src/linux and make menuconfig Actual Results: The box lines arent showed. The text can eventually move when selected. Some graphical bugs this problems happen both on my box and my laptop. Ill paste here my box info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4. 20041102-r1, 2.6.11-gentoo-r4 i686) ================================================================= System uname: 2.6.11-gentoo-r4 i686 AMD Athlon(tm) Gentoo Base System version 1.6.12 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 13 2005, 06:27:03)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.5, 1.7.9-r1, 1.5, 1.6.3, 1.4_p6, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=i686 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/ share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb / usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/ share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=i686 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LANG="C" LC_ALL="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X alsa apm avi berkdb bitmap-fonts cdr crypt cups curl dvd emboss encode fam flac foomaticdb fortran gdbm gif gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg kde ldap libg++ libwww mad matroska mikmod motif mp3 mpeg mplayer ncurses nls nvidia ogg oggvorbis opengl pam pdflib perl pic png python qt quicktime readline samba sdl sftplogging slang spell ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts unicode vorbis xml2 xmms xv xvid zlib video_cards_nvidia userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, LINGUAS
Did you try to uncomment #CONSOLETRANSLATION="8859-1_to_uni" in /etc/conf.d/consolefont?
ive tried with both CONSOLETRANSLATION set on and off it doesnt change anything :(
did you emerge ncurses with USE=unicode ?
get back to us
seems like i didnt post correctly last time, sorry All my packages are emerged with the unicode use flag, including ncurses: sys-libs/ncurses-5.4-r6 -bootstrap -build -debug -doc +gpm -minimal -nocxx +unicode
let the utf8 team figure it out
i didnt notice an utf8 team.... Anyway, thanks guys, i see a team is working hard & quickly, i wish i join you soon :)
IMHO it's upstream bug. it's can ncurses or fonts issue.
Since the obvious hasn't been asked yet: > Im using a font with unicode support ".psfu.gz" in /usr/share/consolefonts Which font is that? A font with unicode support means that it contains a mapping between the symbols and the Unicode characters, nothing more. In particular, there exist multiple .psfu fonts which contain no line drawing characters (example: viscii10-8x16), or contain incomplete and/or incorrect mappings for their line drawing characters (example: sun12x22).
Im using default8x16. Note that i set the variable CONSOLEFONT="default8x16" in /etc/conf.d/consolefont now. I didnt set the CONSOLETRANSLATION variable, btw.
default8x16 should work; it contains the right characters. Could you run showconsolefont to confirm that the line drawing characters do indeed exist, and assuming they do, could you also run echo $'\xE2\x94\x8C' (this is the UTF-8 representation of U+250C "BOX DRAWINGS LIGHT DOWN AND RIGHT") to confirm that the mapping between character and symbol is correct, and that the console is in UTF-8 mode? (I'm assuming, by the way, that LC_ALL as displayed in your emerge --info is set and exported in your usual environment; is that correct?)
showconsolefont shows all characters correctly echo $'\xE2\x94\x8C' shows an uperleft corner correctly. Note that line-drawing works now with mc (i havent checked it for some time), but still not with make menuconfig, alsamixer or mp3blaster.
That's good news. If the new problem is that you see a window frame composed of plus, minus, and vertical bar signs, instead of the line drawing characters, this is the result of a design limitation in non-unicode ncurses, which is installed as the default ncurses regardless of USE flags as of sys-libs/ncurses-5.4-r6 (see also bug #106820); the reason some packages do work is because they specifically check for the unicode version of ncurses and link against that. If you still get actual screen corruption though, here are three possible causes: - ncurses is not detecting the linux console: could you verify TERM is set to "linux"? - ncurses is not detecting the UTF-8 locale: although this normally shouldn't be a problem, could you try changing LC_ALL from en_US.utf8 to en_US.UTF-8? - ncurses is told to ignore either of the above: does the output of `env` show any variables starting with NCURSES_ ?
echo $TERM prints linux after changing LC_ALL to "en_US.UTF-8", lines are drawed with basics | - + characters both in menuconfig and alsamixer. env doesnt output any NCURSES related variables :(
>If the new problem is that you see a window frame composed of plus, minus, and >vertical bar signs, instead of the line drawing characters, this is the result >of a design limitation in non-unicode ncurses, which is installed as the >default ncurses regardless of USE flags as of sys-libs/ncurses-5.4-r6 So, with this LC_ALL, i have this new problems. Is there a way to specify ncurses-unicode as the default ncurses? If so, couldn't it be implemented in the ebuild? Thanks!
(In reply to comment #15) > >If the new problem is that you see a window frame composed of plus, minus, and > >vertical bar signs, instead of the line drawing characters, this is the result > >of a design limitation in non-unicode ncurses, which is installed as the > >default ncurses regardless of USE flags as of sys-libs/ncurses-5.4-r6 > > So, with this LC_ALL, i have this new problems. Is there a way to specify > ncurses-unicode as the default ncurses? If so, couldn't it be implemented in the > ebuild? For some locales like ru_RU.UTF-8 set LC_ALL to ru_RU.UTF-8 give you some problems with some programs like unrecognized simbols for examples
> For some locales like ru_RU.UTF-8 set LC_ALL to ru_RU.UTF-8 give you some > problems with some programs like unrecognized simbols for examples Are you sure this is an ncurses problem, rather than a problem with some specific applications which happen to use ncurses? > So, with this LC_ALL, i have this new problems. Is there a way to specify > ncurses-unicode as the default ncurses? If so, couldn't it be implemented in the > ebuild? This, unfortunately, is only possible with a modified ebuild; for hope of getting the official ebuild changed, please see that other bug (bug #106820) for the reasons why this isn't done. (FWIW, I don't agree with those reasons, especially considering the objections would apply just as much to the <=ncurses-5.4-r5 ebuilds, which didn't end up breaking systems, but it's not my call to make.) > after changing LC_ALL to "en_US.UTF-8", lines are drawed with basics | - + > characters both in menuconfig and alsamixer. Having read the ncurses changelog, the reason why it does work for me with *.utf8 and not for you is because I'm using ncurses 5.5, while you're probably using ncurses 5.4. Apparently, ncurses 5.4 checks if the locale name is "<...>.UTF-8" - this obviously fails with "<...>.utf8" - while ncurses 5.5 asks the C library for the name of the character set. Considering this, I think this bug can be closed (ncurses 5.5 is in the portage tree, though it is not yet marked stable), and the other bug can be used for the remaining problem; do you agree?
I will try ncurses 5.5 soon, ive marked this bug as closed for now; hoping it will not be reopened later... anyway, lines drawed with +-| are suficient to use apps. Thanks you for your support :) Charly
