keysymdef.h has wrong implies symbol?

[Markus Kuhn]

Peter Hutterer wrote on 2008-10-27 04:41 UTC:
> On Sat, Oct 25, 2008 at 02:22:03AM -0400, James Cloos wrote:
> > >>>>> "Peter" == Peter Hutterer <peter.hutterer at who-t.net> writes:
> > 
> > Peter> diff --git a/src/xlibi18n/imKStoUCS.c b/src/xlibi18n/imKStoUCS.c
> > Peter> index 83c1483..4b4f628 100644
> > Peter> --- a/src/xlibi18n/imKStoUCS.c
> > Peter> +++ b/src/xlibi18n/imKStoUCS.c
> > Peter> @@ -123,1 +123,1 @@ static unsigned short const keysym_to_unicode_8a4_8fe[] = {
> > Peter> -    0x2245, 0x2246, 0x0000, 0x0000, 0x0000, 0x0000, 0x22a2, 0x0000, /* 0x08c8-0x08cf */
> > Peter> +    0x2245, 0x2246, 0x0000, 0x0000, 0x0000, 0x0000, 0x21d2, 0x0000, /* 0x08c8-0x08cf */
> > 
> > Wow.  Old bug!
> > 
> > AFAICT it was part of the initial import of the Xfree86 code.
> > 
> > You are right; that is definitely the correct fix if the comment in
> > xkeysymdef.h (that XK_implies should be U+21D2 RIGHTWARDS DOUBLE ARROW)
> > is correct.
> 
> well, that's the issue with the whole thing (Erik and me discussed that a
> bit):
> 
> keysymdef.h states that XK_implies is U+21D2 RIGHTWARDS DOUBLE ARROW.
> in mathematics, this is the usual symbol for "implies".
> however, according to http://unicode.org/charts/PDF/U2200.pdf (p 207),
> "implies" is an alias for RIGHT TACK.
> 
> so basically: either the comment is wrong, or the code is wrong. we have to
> pick whether we want to go with unicode or mathematics.

No need to pick anything. We have now a well-defined standard protocol
specification to consult:

The only official mapping (i.e., the one that is "by definition"
correct) between the legacy keysyms and Unicode is now given in
Appendix A "KEYSYM ENCODING" of the document

  X Window System Protocol
  X Consortium Standard
  X Version 11, Release 6.9/7.0
  ftp://ftp.x.org/pub/X11R7.0/doc/PDF/proto.pdf

(Appendix A alone is also at http://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.pdf )

That clearly says (printed page number 103):

 #x08CE   U+21D2   IMPLIES   Technical

I generated the mapping comments in keysymdef.h table automatically from
the table in the above "X Windows System Protocol" specification,
therefore the two should match exactly (unless someone has been fiddling
with them in the meantime) and I referenced the specification in the
commends at the start of keysymdef.h. Anyone else who maintains a
seperate table (gtk+, etc.) should do the same, or use the relevant
libX11 tables instead.

If you are interested in the reason for that particular mapping:

All 0x08?? keysyms are derived from the (historical and otherwise long
forgotten) "DEC TECHNICAL" encoding, as explained in Section A.6 of the
spec. You can see with your own eye a sample of that encoding by typing
the command

  xfd -fn -dec-terminal-medium-r-normal--14-140-75-75-c-80-dec-dectech

That example font shows at position 0xce (= keysym 0x08ce) a glyph that
matches Unicode character U+21D2 RIGHTWARDS DOUBLE ARROW very nicely.

The Unicode mapping table in Appendix A "KEYSYM ENCODING" of the X11
Protocol Specification is the result of considerable character encoding
archeology and should now be taken as fixed. If you find out there any
other legacy keysym <-> Unicode mapping tables that disagree, please
make sure that are fixed to match the mapping defined in Appendix A of
the standard.

Any other historic character name aliases that you may find in the
Unicode database under RIGHT TACK or elsewhere is irrelevant here, as it
bears no relation to the historic origins of the keysyms, which the
official mapping tried to preserve as much as was practical.

The specification also says that these keysyms are deprecated and may be
phased out. Use the proper Unicode keysyms instead for
mathematical-typesetting keyboard layouts.

Markus

P.S.: The real problem may be that X.Org seems not to maintain a well
publicised canonical long-term PDF URL for the current "X Window System
Protocol" specification and similar documents, therefore far too few
people read the spec itself and instead keep refering to various *.h
include files.

-- 
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain