Date: Wed, 29 Mar 2000 03:39:08 +0000 From: Anatoly Vorobey <mellon@pobox.com> To: Christian Weisgerber <naddy@mips.rhein-neckar.de> Cc: hackers@freebsd.org Subject: Re: Unicode on FreeBSD Message-ID: <20000329033908.A14122@happy.checkpoint.com> In-Reply-To: <8bitar$2i4f$1@bigeye.rhein-neckar.de>; from naddy@mips.rhein-neckar.de on Sat, Mar 25, 2000 at 06:34:19PM %2B0100 References: <20000320194702.11223.qmail@web3101.mail.yahoo.com> <8bitar$2i4f$1@bigeye.rhein-neckar.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 25, 2000 at 06:34:19PM +0100, Christian Weisgerber wrote: > MikeM <mike_bsdlists@yahoo.com> wrote: > > > Has anyone thought of Unicode support on FreeBSD? > > It has crossed my mind... > > > I think that it is inevitable that eventually FreeBSD > > will *need* to support unicode if it wants to continue > > as a viable operating system in the future. > > Probably. The demand for Unicode support is currently rather limited, > but I expect it to pick up somewhat once it is pervasive under > Linux and applications programmers come to expect its availability. I wonder how useful it would be to teach syscons/kbd to handle Unicode. If I mess up royally in the details below, someone please correct me, I only browsed through the sources a bit. Currently, if I understand this correctly, the keyboard driver, and not the console driver, is aware of the current keymap. The keymap maps keycodes with modifiers to actions, which are either some misc actions or character codes. The console driver gets character codes from kbd driver and doesn't need to know anything about keymaps (?). It doesn't know about screen fonts either; it just throws charcodes to video driver which has current font installed. It converses with applications via charcodes as well; at that level, the charcodes also include terminal emulation sequences. The unhappy drawbacks are: a) different language encodings require separate keymap files even when the actual keyboard layout doesn't change. b) different language encodings require separate screen fonts because those are indexed by character codes. c) general 8-bit limitations. d) ...? Now suppose we change the keymap files to assign Unicode codes to keycodes with mofifiers. (the actual Unicode numbers seem better in this case than short UTF-8 sequences?). The kbd driver returns those to syscons. Syscons now has the notion of the current encoding table which translates 8-bit <--> Unicode. It translates the codes back to 8-bit and gives them to applications. When applications give output, syscons translates it back into Unicode after handling the terminal emulation stuff. The video driver now uses a font which only depends on screen size, but not on encoding. It displays the stuff. If this works, the next step would be to offer UTF-8 as the ultimate table and start teaching usermode apps to be happy with it. However, even before that, the immediate effect would be great simplification and reduction of keymaps/screen fonts structure. Does this sound reasonable? -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000329033908.A14122>