>On Tue, 29 Dec 1998, Stanislav V. Voronyi wrote:
>> Yes, this all true. But is symbols which not display correctly
>> needed on keyboard ?
>Probably rarely, but fonts that share glyphs among multiple characters
>have much sense. Keyboard-to-application mapping is independent from
Yes, of course. In my Unicode font map I substitute english
letter with diacritic symbols by the same, but without diacritics (ASCII)
just because I have cyrillyc letters instead of diacritic latin, greek, etc.
>application-to-screen mapping. There is no reason to restrict inputtable
>characters to those that are uniquely outputtable. It gives completely no
>advantage and does have bad effects - the only reason is our laziness.
I agree, but I use single way that exist in console driver now
for converting Unicode symbols to user codeset. Another way - add to
console driver unsigned short unicode2codeset[3][65535] table. Only this
complete table allow make conversion from Unicode to codeset always right.
But imho 256kb of traslating table its too big for kernel driver. Any other
methods can't be right in any circumstances.
>> And add to console driver one another screen buffer in which will be
>> stored unicode symbols.
>And this is another thing; it could give correct gpm pasting when using
>fonts that share glyphs. Unicoded screen buffer is not needed for proper
>keyboard translation, but would have its own advantage.
Imho selection used screen glyphs now just because there is not
correct Unicode to codeset translating in kernel. If it will be invented
(in 2.3 may be ?) it will be very usefull both for keyboard & for selection.
Have you any ideas how make such translation without eating a lot of memory ?
SY, Stanislav Voronyi.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/