[EMAIL PROTECTED] (Niels Möller) writes:
[removed a good insight in unicode<->char-code translation] > > > But using X for telling how to get characters from keyboard scancodes > > to Unicode is compatible with using Unicode internaly. > > Huh? I don't understand you. My point is that it is easier to convert > X keysyms to the user's choice of local character set (be that latin1 > or utf8 or whatever) than to convert from unicode, because, as far as > I'm aware, X keysums have a simple one to one mapping between > characters and integers, without any of those equivalence rules which > you have to understand and implement in order to deal with unicode > properly. > > Add composing later. > Doing unicode sans composing characters may be a start, but it is > *not* really "unicode". > > /Niels But what I do suggest is to fix mapping later. Make it so that users could change that them self. Have API's prepared for unicode to fix mapping later is a better beginning than to dig into 8-bit LATIN-n char code problems, and then try to fix it. But then again. I'm not the one who does the work (for now at least). /Jackson _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
