On Tue, Jan 06, 2009 at 09:38:19AM +0100, Erik Streb del Toro wrote: > Please do something. Or tell my what keeps you from correcting this? As > Simon wrote, it was only a conversion error:
Pushed as 091c1624fd2f9d933329d6152e4ecd865aa7903a. Sorry, sometimes things fall under the radar. Thanks for reminding me though. Cheers, Peter > Simos Xenitellis schrieb am 27.10.2008 12:14: >> keysyms and Unicode characters. This mapping apparently originates >> from the work of Marcus Kuhn,a copy of which is at >> http://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.txt >> >> I checked the gtk+ commit logs that go back to 2000, and I see that still it >> was >> >> { 0x08ce, 0x21d2 }, /* implies ⇒ RIGHTWARDS >> DOUBLE ARROW */ >> >> In XFree86, it appears there was an error when they converted the >> original table to >> http://cvsweb.xfree86.org/cvsweb/xc/lib/X11/imKStoUCS.c?rev=1.1&content-type=text/vnd.viewcvs-markup >> and the problem still shows up there (November 2000). > > The proposed fix: > > Peter Hutterer schrieb am 15.10.2008 08:02: >>> When I have “implies”¹ in my xkbmap it produces not the expected >>> > U+21D2 RIGHTWARDS DOUBLE ARROW >>> > as described in the comment of keysymdef.h but the symbol >>> > U+22A2 RIGHT TACK >>> > >> >> Could this be the fix? Applies to libX11. >> (I don't claim that I know what I'm doing here). >> >> diff --git a/src/xlibi18n/imKStoUCS.c b/src/xlibi18n/imKStoUCS.c >> index 83c1483..4b4f628 100644 >> --- a/src/xlibi18n/imKStoUCS.c >> +++ b/src/xlibi18n/imKStoUCS.c >> @@ -120,7 +120,7 @@ static unsigned short const keysym_to_unicode_8a4_8fe[] >> = { >> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, /* >> 0x08b0-0x08b7 */ >> 0x0000, 0x0000, 0x0000, 0x0000, 0x2264, 0x2260, 0x2265, 0x222b, /* >> 0x08b8-0x08bf */ >> 0x2234, 0x0000, 0x221e, 0x0000, 0x0000, 0x2207, 0x0000, 0x0000, /* >> 0x08c0-0x08c7 */ >> - 0x2245, 0x2246, 0x0000, 0x0000, 0x0000, 0x0000, 0x22a2, 0x0000, /* >> 0x08c8-0x08cf */ >> + 0x2245, 0x2246, 0x0000, 0x0000, 0x0000, 0x0000, 0x21d2, 0x0000, /* >> 0x08c8-0x08cf */ >> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x221a, 0x0000, /* >> 0x08d0-0x08d7 */ >> 0x0000, 0x0000, 0x2282, 0x2283, 0x2229, 0x222a, 0x2227, 0x2228, /* >> 0x08d8-0x08df */ >> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, /* >> 0x08e0-0x08e7 */ >> >> Cheers, >> Peter > > hasn’t any discrepancies: > > Erik Streb del Toro schrieb am 17.11.2008 15:40: >> James Cloos schrieb am 28.10.2008 00:21: >>>>>>>> "Peter" == Peter Hutterer <[email protected]> writes: >>> >>> Peter> well, that's the issue with the whole thing (Erik and me >>> Peter> discussed that a bit): >>> >>> Peter> keysymdef.h states that XK_implies is U+21D2 RIGHTWARDS DOUBLE >>> Peter> ARROW. in mathematics, this is the usual symbol for "implies". >>> Peter> however, according to http://unicode.org/charts/PDF/U2200.pdf (p >>> Peter> 207), "implies" is an alias for RIGHT TACK. >>> >>> I wonder whether ⊢ is used for implies in APL? >>> >>> Peter> As Erik pointed out, right tack does have its own symbol >>> Peter> XK_righttack, whereas there's no other XK_... for the double >>> Peter> right arrow. >>> >>> Sounds like a good reason to go with the comment. As does Erik’s note >>> that Gnome’s code follows the comment rather than the current imKStoUCS >>> implementation. >>> >>> Has anyone audited imKStoUCS.c to see whether there are any other >>> discrepancies? >>> >>> -JimC >> >> I’m still waiting for the solution of this little problem. I searched >> for discrepancies in imKStoUCS.c but couldn’t find any. >> >> So, will someone please commit the small bugfix? Or what are we waiting >> for? > > I don’t want to remind you again, because I want to forget about this > problem. ;-) > > Greetings, > Erik _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
