Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!bloom-beacon!HARRY.CRIM.CA!justin From: justin@HARRY.CRIM.CA (Justin Bur) Newsgroups: comp.windows.x Subject: Re: dead keys again, and ISO 6937/2 Message-ID: <8909032227.AA00235@harry.crim.ca> Date: 3 Sep 89 22:27:34 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 41 > I assume you are referring to "non-spacing diacritical marks". If so, > I don't see the need for them. There are already keysyms for letters > with diacritical marks. There are also keysyms for the diacritical > marks themselves. 6937/2 has the non-spacing forms (as I understand > it) merely as a representation mechanism within an octet stream. There > is no need for this in X keysyms. A few weeks ago I posted a query to xpert about dead keys, asking how they should be implemented, but if there were any replies I missed them. The only X keyboard with dead keys that I have seen is H-P's (HPwindows on the Series 300 under HP-UX 6.1), and it uses special keysyms for these keys (based on HP's Latin8 character set rather than 6937/2). Granted, the diacritics provided in the upper 128 keysyms of Latin1-4 could be assumed to be dead keys whenever they occur. However, three diacritics (grave, circumflex, tilde) are considered to be part of the lower 128 by the ISO, yet just about everyone, including the X keysyms, uses them as standalone graphics: quoteleft, asciicircum, and asciitilde. My X11.3 has no grave, circumflex, or tilde. I need to create a French keyboard mapping that can be installed and removed at will, whether the physical keyboard happens to have French keycaps or not, whether I'm on a Sun server or an X terminal. The only tool I know of to do this is xmodmap. Assuming that dead keys are to be implemented in Xlib, in XKeyBind.c along with compose-character, I need to be able to distinguish a real grave accent (a dead key) from a quoteleft (a standalone), a real circumflex from an asciicircum, a real tilde from an asciitilde. Hence my suggestion to use ISO 6937/2. The remaining characters in my list were only for completeness, though I do think the ij and oe ligatures have some chance of being useful in some application. Still, the need for 6937/2 keysyms exists only as long as my current idea of how to produce a switchable keyboard with dead keys is the only idea I have. It has occurred to me that Digital has had to solve the same problem, and I would like to know if they did it differently from Hewlett-Packard, or if there is a `correct' or `official' solution. Justin Bur CRIM, Montreal