lkml.org 
[lkml]   [1996]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Unicode status

At 01:52 01.12.1996 GMT, Andries Brouwer wrote:
>: Yes of course you can say the kernel not to care about input and
>: pipe characters (nearly) unprocessed into the application. But I
>: thought of a stable/robust solution. As far as I know switching
>: to K_UNICODE is risky. Nobody handles ^C, ^Z ... and if ^C would
>: be processed the user would end up with K_UNICODE in his shell.
>
>All these statements are incorrect.
>Clearly, you have never executed the command "unicode_start"
>from the kbd package.
>
>Note that ASCII is a proper subset of UTF8.
>As long as you only use ASCII, you do not notice any difference
>between `unicode mode' and `standard mode'.


Yes you're right. My kbd-package was a little bit outdated (kbd_mode -u
was broken and resulted in raw mode).

But improvements are possible:

1. There are problems with history scrolling in bash where the text is
shifted left.

2. There are exist no keymaps for Unicode. (Or at least I didn't find
them in the kbd distribution).

3. Applications are limited to 512 characters. This means that
an application always has to ask the kernel what characters are
available, or to believe, that the user hat set up the correct
font/fontmap/keymap combination. This is ok as long as you use only
your own texts. For unknown documents you can only open and pray.
The application *could* load appropriate fonts/keymaps. But in the
way fonts/keymaps are stored today you would have to read in all
fonts/keymaps and search for the most appropriate and this doesn't
guarantee, that you find all chars if they only in different files...
There should be at last a kind of registry for these files.

4. A graphical console would make life easier, if you can download large
fonts ...

At 11:15 30.11.1996 -0600, Aaron Ucko wrote:
>while 512 is certainly less than 65536, it is plenty for many people.
>Nevertheless, it shouldn't be too hard to get GGI to support it if
At 15:59 30.11.1996 -0600, Aaron Ucko wrote:
>The general graphics interface. See
>http://synergy.caltech.edu/~ggi/GGIFAQ.html for more information.

Yes I agree about GGC. But as far as I understood their docu, it's
available only after kernel bootup (but can be easily changed to
go completely into the kernel...).


Sometimes reading your replies I thought we are talking two different things.
In my opinion Unicode should solve problems not create new ones. The idea is
to have *one* "codepage" instead of hundreds. In this point the handling
under
Linux doesn't differ from DOS (MODE CON CODEPAGE ...). You should be able
to write in any language and even mix them if necessary. I think it's not
the idea behind Unicode that you issue 10 commands to switch between
codepages.
(Don't even think of a shell script -- that's definitely not what I'm talking
about). A good Unicode implementation should work like Linux would do if all
users worldwide would need only 7bit ASCII to express everything they
want to write down. Unicode for Linux shouldn't be an emulation
(OK, it isn't but it looks like one).

Sorry if I repeating myself:
In WinNT the user has to 1 mouse click to select another keyboard and then he
simply starts typing. In WinNT a programmer has to write "#define _UNICODE"
to
create a Unicode-aware program. Please compare this to what has to be done
under Linux. (That's also an libc issue.)



Michael

To all who are still supporting the codepage concept: Maybe we will meet the
Borgs first. And then you will have only your Klingon codepage available.

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.056 / U:15.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site