On Tue, Jan 11, 2005 at 12:55:47AM +0000, Simon wrote: > I would also love to see all of Unicode 4.1 supported > on the Linux console. However it looks difficult to get someone with those > two incompatible(?) skills, Linux kernel programming and love for > linguistics...
A strange remark. Consider the following view: A booting Linux system passes through various rather primitive states until it has started X or a frame buffer device or so and has full power to do whatever it wants with input methods and fonts. One of these primitive states is the one where one has the bare console without graphical capabilities. This bare console is somewhat useful in various circumstances - maybe one's monitor or video card doesn't support anything better, or the video card is good but is not supported, etc. And it is useful at boot time. Maybe at install time. Maybe for kernel debugging. It is not entirely clear why one would enhance the console with complicated support for all kinds of things. Especially since that would have to be done in the kernel, wasting kernel memory for everybody. Clearly, if one wants to support arbitrary Unicode that belongs in user space. In fact the interest in getting more support for the console seems fairly limited. When I made a bidi console nobody was interested. Full Unicode support is really complicated. A year ago or so I needed to create a web page with text in different languages. As it turned out the released version of Mozilla was not yet able to correctly display the Devanagari combining, or vocalized Hebrew. (Jungshik Shin made available a binary that handled Devanagari - have not checked recently how the situation is for Hebrew.) The code needed to handle Unicode is really large and partly nonexistent - it is ridiculous to suppose that one would like to have a modified copy of it in the kernel. Especially since the bare console lacks graphical possibilities. So, the text console can do a little. If one wants to see full support for anything on the console, that is a mistake. But of course improvement is possible. One further point is backwards compatibility - changes must not break anything. And another point is the impopularity of ioctls. Adding further ioctls is frowned upon, one needs a good reason. On the other hand, if someone has a good reason (and clean code), everything is possible. Andries -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
