ahall@vision.UUCP (Andy Hall) (07/31/90)
Can anyone enlighten us as to the handling of dead key sequences. For instance, suppose on a IBM style Danish keyboard a user types "umlaut"(which is a dead key), followed by "a". What events are sent to the client ? is it: key down ( umlaut ) key up ( umlaut ) key down ( a ) key up ( a ) or does the server translate the sequence and send only a key down, key up for "a umlaut" Even worse, what happens when the dead key is only dead when shifted? For instance, Swiss German keyboards have "umlaut" and "!" are on the same key. Also, what part does XLookupString play in this ? Are compose chars really not implemented as implied by comments in the X11R4 source ? Ta, Andy
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/31/90)
does the server translate the sequence and send only a key down, key
up for "a umlaut"
The server does not do dead key translation or compose processing.
Also, what part does XLookupString play in this ?
It was supposed to deal with this, but the sample implementation never has.
Some vendors have added support in their products.
The Xlib internationalization work currently underway in the Consortium
involves defining revised interfaces that are capable of supporting not
only European input methods, but Asian input methods as well.john@acorn.co.uk (John Bowler) (08/07/90)
In article <1151@vision.UUCP> ahall@vision.UUCP (Andy Hall) writes: > > Can anyone enlighten us as to the handling of dead key sequences. >For instance, suppose on a IBM style Danish keyboard a user types "umlaut"(which >is a dead key), followed by "a". What events are sent to the client ? As you suggested; key down (umlaut), key up (umlaut), key down (a), key up (a) - supposedly the Consortium is working on the issues raised by internationalisation requirements in this area. Theoretically the processing could be done in the server or Xlib, but the logical place is Xlib (where there are some hooks already, and similar processing already occurs). The problem would seem to be that the current keysym definitions are inadequate - for example XK_acute is present along with XK_apostrophe (XK_quoteright) (two different keysyms) but XK_grave and XK_quoteleft are the same keysym, although there might be keyboards with both a grave accent (non-spacing) and a left quote (spacing). Many national keyboard specifications mix both non-spacing and spacing keys on the same key top (in particular the French one does) - this is a very good reason for not attempting to do the work in the server (which would have to make changes in response to modifier mappings which it currently just caches away). On the other hand, getting a working system looks like a lot of work - given the lack of ISO-8859-~1 fonts, the fact that many of the ``ISO-8859-1'' fonts in the current MIT distribution aren't, the bugs in the Xlib handling of accented characters and so on. (We (Acorn) haven't yet been able to fix the problems in this area in our own system). John Bowler (jbowler@acorn.co.uk)