Jan Willem Stumpel wrote:

Alexandros Diamantidis wrote:

When I made an initial try at a polytonic Greek keyboard, I couldn't
find a dead_comma_above and a dead_reversed_comma_above, so I just
(ab)used the first two keysyms that weren't otherwise meaningful on a
Greek keyboard. Subsequent updates to the Greek keyboard layout and
Compose files kept this (perhaps not strictly correct) arrangement.


This xkb stuff is not so easy to understand, but Alexandros' and Jim's
comments helped a lot.

I have so far always used a "us_intl" keyboard layout in order to enter
accents. This needs the AltGr key to change groups when a key must
produce more than 2 symbols.

But there is also a variant called alt-int of the "us" keyboard, which
uses extra levels (instead of a new group) to get the same effect. The
AltGr key is used to make the 3rd level. BTW I still don't know what to
press for the 4th level.

From the user's point of view, the behaviour of us_intl and
us(alt-intl) is exactly the same. You get all the accents (dead keys),
the Euro sign, etc. in the same way with both methods. But us(alt-intl)
does not use an extra group. So the groups can be used for other
languages (so you do not need to "switch" groups, only "toggle" them).

I found the following combination works nicely:

setxkbmap "us(alt-intl),gr(polytonic)" \
             -option compose:rwin
             -option grp:lwin_toggle

With this, left-Windows toggles between us(alt-intl) and polytonic Greek
mode. All characters, including things like αΎ¦, can be made in Greek
mode, even in en_GB.UTF-8 locale, if the dead ogonek and horn in the
symbols/pc/gr file are replaced by the utf-8 characters COMBINING COMMA
ABOVE (0x1000313) and COMBINING REVERSED COMMA ABOVE (0x1000314); the
(default?) US Compose file then has lots of entries for combined Greek
characters.

This change would probably break things for Greek users unless the Greek
Compose file is also changed.

Other scripts can be added, e.g us(alt-intl),gr(polytonic),ru.

AFAIK, nowdays Greek uses the en_US.UTF-8 file for dead keys.
Specifically, Greek users of Ubuntu 5.10 have trouble with accents as the Greek file (el_GR.UTF-8) with the dead key sequences is not installed any more. By changing the configuration file to point to en_US.UTF-8, modern Greek works once again. In addition, the name of the keyboard has reverted back to "gr" (country code, as with all other keyboard layouts) compared to "el" that used to be the case for the last few years.

GTK+ has its own input method and requires dead keys to be registered, if you use this GTK+ IM input method. If you notice some GTK+ apps not working, this is where you investigate. For more on this, see
http://bugzilla.gnome.org/show_bug.cgi?id=321896

X.org has been in transition from the monolithic setup to the modular one you find now in X.org 7.0. Due to this, files are being moved around, so you need to know where you submit patches to. My understanding is that Greek (modern/ancient-polytonic) keysyms should come from the generic en_US.UTF-8 and not use a custom one.
The existing en_US.UTF-8 at
http://cvs.freedesktop.org/xorg/xc/nls/Compose/en_US.UTF-8?view=markup
shows that it covers many languages. This file appears to be monolithic one. I will have to look closer to find the "modular" copy somewhere in the source tree. Any hints?

There are clashes with the reusing of dead_acute, dead_ogonek and so on in many different languages, causing trouble and conflicts when having a single compose file for all languages. I did not see a compelling reason against creating more symbol definitions. Are there any? At this point that the transition took place, I think patches would get accepted for a few more symbol definitions (that's their name, right?).

Indeed, keyboard support for X.org is a bit of a mystery as there appears to be no person that claims some expertise and answers questions. The keyboard support was created by Sun engineers in the early 90s and there was this feeling it was "over-engineered". Those engineers moved on to work areas now, some of them still at Sun (irc discussions at #xorg).


Still this setup generates warnings which probably explain why I cannot
reach the 4th level symbols (you see the warnings after closing X), like:

Warning: Type "ONE_LEVEL" has 1 levels but <RALT> has 2 symbols
           Ignoring extra symbols
Warning: Type "THREE_LEVEL" has 3 levels but <AC11> has 4 symbols
           Ignoring extra symbols

Now how to fix this?

See
http://www.xfree86.org/current/XKB-Enhancing4.html

When you specify how many levels your keyboard layout will use, the table that looks like

 key <AE02>  { [         2,   quotedbl,  twosuperior,    oneeighth ] };
 key <AE03>  { [         3,   sterling, threesuperior,    sterling ] };

should have up to that number of columns.
In your case, somehow, more collumns where found so some had to be ignored.

Simos


--
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/

Reply via email to