Date: Thu, 19 Apr 2001 18:56:39 -0400 (EDT) From: mi@aldan.algebra.com To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/syscons/fonts cp866u-8x14.fnt cp866u-8x16 .fnt cp866u-8x8.fnt koi8-u-8x14.fnt koi8-u-8x16.fnt koi8-u-8x8.fnt INDEX.fonts Makefile src/share/syscons/keymaps ua.koi8-u.sh ift.al t.kbd INDEX.keymaps Makefile ... Message-ID: <200104192256.f3JMueC41583@misha.privatelabs.com> In-Reply-To: <20010420022925.A74072@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20 Apr, Andrey A. Chernov wrote: = On Thu, Apr 19, 2001 at 18:19:29 -0400, mi@aldan.algebra.com wrote: = = > Well, let me rephrase it. Are ALL of the pseudo-graphics symbols = > available in ASCII also available in KOI8-R (even if at different = > positions)? = = There is no pseudographics in ASCII. Oh... I think, you understood, what I meant, but I'll try again. Replace "ASCII" above by "the charset commonly used by pseudo-graphics using programs, whose authors are unaware of any other languages or character sets but English and latin". Or, in particular, the koi8-r table on your web-site http://koi8.pp.ru/koi8-r.gif seems to suggest, that two pseudo-graphical symbols (not sure which ones) were sacrificed to make room for e: and E: (positions 163 and 179). = > In any case, I'd suggest we make a symlink koi8 -> koi8-u for = > compatibility with OpenBSD if for no other reasons. = = I suggest OpenBSD developers to fix their mistaken decision. Well, in the bad old days of Soviet Union there was no KOI8-R or KOI8-U. There was KOI8: "Kod Obmena Informaciej, 8-bitovyj". Having at least something, that is called KOI8 is good, IMO. For completeness sake, I think, that "something" should be, what is now called koi8-u. Whether or not OpenBSD's decision is mistaken is irrelevant -- we can be compatible without making the same mistake (if it is a mistake). = > May be, teach the termcap to look for: $TERM-$CHARSET prior to = > looking for $TERM itself in the database (with charset being = > obtained from LANG)? What will this break? = = It breaks libtermcap and libncurses documented way of things making = unportable programs at least. Well, the programs themselves will be portable, since all of the assumptions and modifications will be inside libtermcap -- the app will continue to (portably) call vline, hline, etc, but the library will try to harder to figure out the correct characters... The portability argument does not apply, I think. As far as the "documented way of doing things" -- I just don't know: . is the breakage that big? . perhaps, it is worth it (assuming, the documentation is modified too) -- to solve the problems I'm referring to (having to mess with /etc/ttys in addition to specifying your language and charset preferences)? -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104192256.f3JMueC41583>