Messages in this thread | | | Date | Sun, 12 Dec 2004 01:05:49 +0100 (MET) | From | Jan Engelhardt <> | Subject | Re: Improved console UTF-8 support for the Linux kernel? |
| |
>I am a bit confused. Could you please comment on the following, as a >common test steps?
I do it a bit faster (i.e. without "od"): if after a Compose operation, I see something, it must have been UTF8. If not (like there has been only 8 bits output), the current line screws up a little. <- My test strategy; does not need `od` to confirm.
>I am not sure how you wrote the above characters. According to UTF-8, >characters with codepoints above 0x79 require two bytes so that to be >valid. When you compose "ö" (you press something like ";", then "o") in >the console?
ö is a "native key" on my keyboard, i.e. i do not need to play with compose to generate ö.
>For simplicity, let's assume you do something like % loadkeys --unicode compose '/' 'e' to U+00F6 # ('ö') ^D %
I did that (a shortened form of yours), and saw by `dumpkeys` that there was now only one compose table entry, so I think `loadkeys --unicode` overwrites the table? Rightly so. Still and despite there are now no compose table entries, with the exception of that one, I can still generate ö. <compose><"><o> rightly gives two 7-bit characters (rightly so at this point).
>Good. I hope more people raise their hands for this.
...want kanji-on-console, but I guess that will not come true with VGA, which only supports 256 (512) chars. OTOH, [free]BSD's mouse support uses a graphical mouse pointer rather than a "block" one like gpm does, and as I think of it, such a graphical mouse (most Norton apps for DOS also had such) needs some VGA magic or so to set single "pixels"/bits. If single bits within the 8x{16,etc.} char cell can be set, we could have kanji. Can anyone elaborate on this graphical mouse stuff?
Jan Engelhardt -- ENOSPC | |