Path: utzoo!attcan!uunet!mcsun!ukc!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re: Dead Keys and X
Message-ID: <2651@acorn.co.uk>
Date: 7 Aug 90 11:08:54 GMT
References: <1151@vision.UUCP>
Reply-To: john@acorn.UUCP (John Bowler)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 31

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)