On Wednesday 2003.08.06 11:46:33 -0400, Edward H. Trager wrote: > On Wednesday 2003.08.06 08:29:37 -0400, Chris Heath wrote: > > > Also, I think that console-keyboard drivers may be divided to 2 versions, > > > with kernel build option: > > > > > > the simple, with fixed 8bit codepage, unused legacy things like VT100 graphics > > > removed > > > (for people who dont'n need i18n or work not so much in console) > > > > > > and the sophisticated, full-functional and well internationalized. > > > > Yes, I think this is the way to go. I imagine we will meet a lot of > > resistance if we try to add heavyweight Unicode stuff into the existing > > console. > > > > The heavyweight version would need a LOT of requirements gathering > > before we even begin programming. It probably should include support > > for: > > > > * lots of encodings, but use Unicode internally > > Hmmm ... If I knew how to do this stuff myself (which I don't), I would > not bother with any encoding except Unicode UTF-8 (If people did not like > my patch, they wouldn't have to use it, right?). That would cut down on > the requirements and complexity a bit ... (a BIG BIT, N'est-ce pas?). >
When I do software projects, I invariably think of which requirements I am going to implement in "phase 1", "phase 2", and finally "phase 3" ... What I should have suggested is to just go ahead and implement robust UTF-8 encoding support in "phase 1". One can then worry about whether it will still be necessary to support all of those legacy encodings in "phase 2" or "phase 3" which will be a year or 2 or 3 away ... If the whole Linux world is converted to UTF-8 by then, maybe you will get lucky and won't need to bother with the legacy encodings after all ;-). > I (and many others ...) would argue that everyone needs to move to Unicode. > So when you buy that shiny new version of Linux 5 years in the future, > it's going to support Unicode very well, and it is perhaps no longer going to > support the 3-5 mutually incompatible legacy encodings of your language that you > previously > had to struggle with ... > > > * user-space pluggability for extra-heavyweight stuff like Japanese > > input methods or fonts > > I wonder if the object oriented design of SCIM (Simple Common Input Method: > http://ns.turbolinux.com.cn/~suzhe/scim/index.html) could support CJK and > other IMs on the console? > > > * bidi text (Arabic) > > * variable width fonts (CJK), > > * variable-width encodings (Unicode combining chars), > > Yes, it would be nice if console worked as well as (or better than) > mlterm (http://mlterm.sourceforge.net/) > does for bidi, ligatures and combining characters for complex > layout languages > > > * absolute positioning for things like line drawing... > > * ANSI / ECMA and VT100 compatibility > > > > Hmmm... I suspect I've hardly even scratched the surface and already this > > looks like it's going to be way too big for the kernel. Maybe the > > entire thing should be in user space. > > > > How important is it to have an in-kernel console? > > > > Chris > > > > -- > > Linux-UTF8: i18n of Linux on all levels > > Archive: http://mail.nl.linux.org/linux-utf8/ > > > -- > Linux-UTF8: i18n of Linux on all levels > Archive: http://mail.nl.linux.org/linux-utf8/ > -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
