srintuar wrote:
Martin Wiss wrote:
Why do people want to have a full-blown Unicode renderer and
input-method *in the kernel*?
Could you image if the default input-method in the kernel was only
vertical/right-to-left chinese characters.
Would you like to have an input method for ascii then, or would you think
that it wouldnt matter?
I dont know if it has to be in the kernel or not, but I know that I want to be able to read and input characters in my own language without running X. Currently about half of the worlds population are not able to do that.
What about the possibility to have domain names in Unicode in the future?
Wouldnt it be good then to be able to have Unicode-support in the linux
console then
so that one could read and edit those domain names?
The kernel doesnt speak any language, not even English really.
Having a console with full blown unicode input methods, layout engines,
dictionaries, and locales inside the kernel is unreasonable. It does
have to be willing to accept utf-8 strings in system calls, but thats about
it. DNS address are a total non-issue, they dont have anything to do
with the kernel.
Proper i18n of the local console requires it be in userland. Only the locales and language engines that the local users actually care about even need to be installed. (Though a complete set of fonts for the display of any language text should probably be always installed.)
Putting a modern terminal in the kernel makes about as much sense as putting X11 in there.
Fair enough.
However, how does this user-space software for console look like? What exactly should it do? What's to remove/modify from the kernel? Any proof-of-concept code that can show the validity of direction?
Simos
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/01/2005
-- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
