Experiments with classical Greek keyboard input
Jan Willem Stumpel
locale, PC104 (US) keyboard. No KDE, no Gnome. Just X with icewm.
Uim and scim do not provide methods for classical Greek. The immodule
im-classicalgreek does not seem to work anymore with the newer versions
(2.4.0) of gtk-2. So another method has to be found.
I tried to use the facilities offered by xkb.
Open an xterm and type
setxkbmap us_intl (or whatever your favourite keyboard is).
This is an insurance policy; by pressing up-arrow you can always get
this command back.
Then type
setxkbmap "gr(polytonic)+level3(lwin_switch)"
You keyboard changes to Greek, with some accents available:
dead perispomenon on the [ key, e.g. ῶ, ᾶ
dead macron on the [ key with left-windows pressed, e.g. ᾱ.
dead iota subscriptum on the ] key, e.g. ᾳ, ῃ, ῳ
dead acute accent on the ; key, e.g. ύ, ά, ί
dead grave accent on the ' key, e.g. ὰ, ὸ, ὶ
Accents can be combined, e.g. ][v becomes ῷ, ];h becomes ῄ. The iota
always has to be entered first.
But there is no way to enter the "breathing" signs (spiritus asper and
spiritus lenis, as they were called when I was at school).
The only way I found (so far) to enter the breathing signs is to edit
the file /etc/X11/xkb/symbols/pc/gr and change the lines
key <AC10> { [ dead_acute, dead_horn ] };
key <AC11> { [ dead_grave, dead_ogonek ] };
to
key <AC10> { [ dead_acute, dead_horn, 0x1000313 ] };
key <AC11> { [ dead_grave, dead_ogonek, 0x1000314 ] };
This makes the "breathing" signs available (after an X restart) on the ;
and ' keys, when the left-windows key is pressed. It is then possible to
enter things like ᾦ, ᾔ, ᾇ, ῥ. The breathing signs have to be entered
last (just before the letter itself).
This system is far from ideal. It should be possible to change from the
default keyboard to classical Greek (and back) by some hotkey instead of
a setxkbmap command. And also, several accent combinations can,
apparently, only be entered in xterm and openoffice, but not in Mozilla.
Suggestions for improvement are greatly appreciated. Apologies in
advance if all this has been covered before.
Regards, Jan
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
James Cloos
Jan> setxkbmap "gr(polytonic)+level3(lwin_switch)"
Jan> It should be possible to change from the default keyboard to classical
Jan> Greek (and back) by some hotkey instead of a setxkbmap command.
You can accomplish that part by specifying multiple keymaps on the
setxkbmap line.
I use this command for my standard setup:
setxkbmap -layout us,el,ru,il -variant ,,phonetic,phonetic \
-option ctrl:nocaps -option grp_led:scroll \
-option compose:menu -option grp:ctrls_toggle \
-option altwin:super_win
that gives me four layouts (the max that can be set at any given time)
which I can scroll through by pressing both control keys together (
that is the grp:ctrls_toggle option). When I am in anything other
than the us map the scroll lock led is on (the grp_led:scroll option).
I also have the cap lock key be a control key and the menu key a
compose key.
Or at least I used to. el no longer works for me.
(The goal was to cover Latin/Greek/Cyrillic; I thru il in as well just
cause I could....)
I also lack a good key to waste as a level3 key. (The laptop lacks a
right win keyน and I use the left win key for icewm.)
-JimC
น In fact the Fn key plus the left win key generates the keycode of
the right win key, but it cannot be used as a modifyier because
non-Fn-special keys are ignored when holding down Fn....
--
James H. Cloos, Jr. <cl...@jhcloos.com>
Alexandros Diamantidis
> But there is no way to enter the "breathing" signs (spiritus asper and
> spiritus lenis, as they were called when I was at school).
>
> The only way I found (so far) to enter the breathing signs is to edit
> the file /etc/X11/xkb/symbols/pc/gr and change the lines
>
> key <AC10> { [ dead_acute, dead_horn ] };
> key <AC11> { [ dead_grave, dead_ogonek ] };
That dead_horn and dead_ogonek are "really" dead spiritus lenis (psili)
and spiritus asper (daseia) respectively. Just try, for example, ;:a in
greek mode, and you should get ἄ - with one caveat: this works only when
your locale is el_GR.UTF-8, so that the el_GR.UTF-8/Compose is used.
Alternatively, you can put the line
include "/usr/lib/X11/locale/el_GR.UTF-8/Compose"
at the top of your ~/.XCompose and after that add any sequences you need
that aren't there (or you can just include many other Compose files -
when the same sequence appears multiple times, later ones override
earlier ones).
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.
--
Alexandros Diamantidis * ad...@hellug.gr
Jan Willem Stumpel
> 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.
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?
Regards, Jan
Alexandros Diamantidis
> This xkb stuff is not so easy to understand, but Alexandros' and Jim's
> comments helped a lot.
I don't understand xkb files very well, either!
> 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.
Right, that's one way to do it. Another way would be to create a custom
personal compose file, which includes both the US and GR Compose files.
That way, you can use the dead_horn and dead_ogonek keysyms used in the
existing greek keymap, with no need to add the combining Unicode
characters you mention.
I think if you put the following two lines in ~/.XCompose it will work:
include "/usr/lib/X11/locale/el_GR.UTF-8/Compose"
include "/usr/lib/X11/locale/en_US.UTF-8/Compose"
> 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 "THREE_LEVEL" has 3 levels but <AC11> has 4 symbols
> Ignoring extra symbols
>
> Now how to fix this?
I'm sorry, I don't know about this...
Jan Willem Stumpel
> * Jan Willem Stumpel [2006-01-16 21:52]:
>>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 [..]
> Right, that's one way to do it. Another way would be to create a custom
> personal compose file, which includes both the US and GR Compose files.
> That way, you can use the dead_horn and dead_ogonek keysyms used in the
> existing greek keymap, with no need to add the combining Unicode
> characters you mention.
>
> I think if you put the following two lines in ~/.XCompose it will work:
>
> include "/usr/lib/X11/locale/el_GR.UTF-8/Compose"
> include "/usr/lib/X11/locale/en_US.UTF-8/Compose"
This does not work in my case. Also interchanging the entries (US first,
then GR) did not work. I mean you can get the accents, but not the
breathing signs. Strangely enough, even calling
LANG=el_GR.UTF-8 xterm
and then doing things in the new xterm, did not work! I don't understand
why. I have the el_GR.UTF-8 locale installed.
So it seems that when /etc/X11/xkb/symbols/pc/gr is left as it is, users
must change their locale to Greek to use polytonic Greek (if they want
to use the xkb facilities). But in the true UTF-8 spirit, we should be
able to read/print/enter *anything* from *any* locale, as long as it is
a UTF-8 one.
So perhaps /etc/X11/xkb/symbols/pc/gr should really be changed to
include the UTF-8 'breathing' signs. Then, I suppose,
/usr/lib/X11/locale/en_US.UTF-8/Compose could be used for Greek, as it
is for so many other languages, including Russian, Hindi, Hebrew,
Japanese, and even French ;-). Of course there may very well be some
special reason for having a separate Greek UTF-8 Compose file which I do
not understand.
Regards, Jan
Simos Xenitellis
> 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
Alexandros Diamantidis
* Jan Willem Stumpel [2006-01-18 14:41]:
> This does not work in my case. Also interchanging the entries (US first,
> then GR) did not work. I mean you can get the accents, but not the
> breathing signs. Strangely enough, even calling
>
> LANG=el_GR.UTF-8 xterm
>
> and then doing things in the new xterm, did not work! I don't understand
> why. I have the el_GR.UTF-8 locale installed.
I really wonder why... I thought if you had a ~/.XCompose file, your
locale didn't matter (except if you specifically used it in that file,
by doing 'include "%L"'). Maybe it's not used at all? You could try
strace on some X program and see if it is opened.
$ strace -o foo xterm
$ grep XCompose foo
open("/home/adia/.XCompose", O_RDONLY) = 5
> to use the xkb facilities). But in the true UTF-8 spirit, we should be
> able to read/print/enter *anything* from *any* locale, as long as it is
> a UTF-8 one.
I agree with this sentiment... I have also had trouble in this department
as well :(
> So perhaps /etc/X11/xkb/symbols/pc/gr should really be changed to
> include the UTF-8 'breathing' signs.
Yes, but which keysyms should be used? U0313 and U0314, which correspond
to U+0313 COMBINING COMMA ABOVE and U+0314 COMBINING REVERSED COMMA
ABOVE? The current hack which uses dead_horn and dead_ogonek? Or some
new keysyms?
* Simos Xenitellis [2006-01-18 14:40]:
> 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?
Well, I don't think there is a problem with reusing dead keys for many
languages. Can you think of an example where a dead key followed by a
letter key (or some other similar sequence) should produce different
results depending on the language?
X11 keysyms are supposed, I think, to correspond to keys that really
appear on keyboards. But in the case of polytonic Greek, for instance,
we never had computer keyboards with breathing signs, did we? So these
symbols were left out. You are right, a few more symbols for dead keys
would be useful. But I don't know who is responsible for defining new
ones - X.Org maybe? Perhaps a bug should be opened about this at
bugs.freedesktop.org...
Jan Willem Stumpel
> [sorry for taking a few days to reply...]
>
> * Jan Willem Stumpel [2006-01-18 14:41]:
>
>> This does not work in my case. Also interchanging the entries (US
>> first, then GR) did not work. I mean you can get the accents, but
>> not the breathing signs. Strangely enough, even calling
>>
>> LANG=el_GR.UTF-8 xterm
>>
>> and then doing things in the new xterm, did not work! I don't
>> understand why. I have the el_GR.UTF-8 locale installed.
>
>
> I really wonder why... I thought if you had a ~/.XCompose file, your
> locale didn't matter (except if you specifically used it in that
> file, by doing 'include "%L"'). Maybe it's not used at all? You could
> try strace on some X program and see if it is opened.
I am going to investigate this further. Will reply when I get some results.
> [..]
>> So perhaps /etc/X11/xkb/symbols/pc/gr should really be changed to
>> include the UTF-8 'breathing' signs.
>
>
> Yes, but which keysyms should be used? U0313 and U0314, which
> correspond to U+0313 COMBINING COMMA ABOVE and U+0314 COMBINING
> REVERSED COMMA ABOVE? The current hack which uses dead_horn and
> dead_ogonek? Or some new keysyms?
I think it should be U0313 and U0314, because they are 'official': the
Unicode standard (http://www.unicode.org/charts/PDF/U0300.pdf) says that
313 and 314 are used as Greek psili and Greek dasia, and the
common Compose file (/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose)
already has lots of compose sequences defined which use 313 and 314, like
<dead_iota> <dead_tilde> <U0313> <Greek_omega> : "ᾦ"
U1FA6 # GREEK SMALL LETTER OMEGA WITH PSILI AND PERISPOMENI AND
YPOGEGRAMMENI
In fact there are 20 different compose sequences in the file for the ᾦ
character alone! Some of them involve 5 keystrokes, using ( and ) to
input the 'breathing' signs. I've no idea who put all these definitions in.
So polytonic Greek does not really need its own Compose file; everything
is already in the common file. Using the common file would mean that
polytonic Greek could be input from any (UTF-8) locale. It's just that
the /etc/X11/xkb/symbols/pc/gr file has to reflect this. The dead_horn
and dead_ogonek can then be left alone (for whatever really horn- and
ogonek-using languages want to do with them).
Regards, Jan
Markus Kuhn
> Yes, but which keysyms should be used? U0313 and U0314, which correspond
> to U+0313 COMBINING COMMA ABOVE and U+0314 COMBINING REVERSED COMMA
> ABOVE? The current hack which uses dead_horn and dead_ogonek? Or some
> new keysyms?
If you need new functional keysyms in the X11 standard, then please post
a proposal on http://bugs.freedesktop.org/, and assign it to me.
You may also want to review the keysyms section in Appendix A of the X11
Protocol spec, which was substantially rewritten in X6.9 (by yours
truely).
ftp://ftp.x.org/pub/X11R7.0/doc/PDF/proto.pdf
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Jan Willem Stumpel
> [sorry for taking a few days to reply...]
>
> * Jan Willem Stumpel [2006-01-18 14:41]:
>
>>This does not work in my case. Also interchanging the entries (US first,
>>then GR) did not work. I mean you can get the accents, but not the
>>breathing signs. Strangely enough, even calling
>>
>>LANG=el_GR.UTF-8 xterm
>>
>>and then doing things in the new xterm, did not work! I don't understand
>>why. I have the el_GR.UTF-8 locale installed.
>
>
> I really wonder why... I thought if you had a ~/.XCompose file, your
> locale didn't matter (except if you specifically used it in that file,
> by doing 'include "%L"'). Maybe it's not used at all?
I think it did not work because I am trying out scim and uim. I must
have been running scim at the time. It seems that when scim is running,
only its own internal version of the compose file is used.
Customisations in ῀/.XCompose do not work at all. With uim, they work.
The Greek entry must of course come second in the ῀/.XCompose file. I do
not know how uim does it.
This also means that when you run scim, the ogonek and horn do not work
as breathing signs even if the locale is el_GR.UTF-8, because scim's
internal copy of the Compose file is only the "common" one.
Regards, Jan
Simos Xenitellis
> Alexandros Diamantidis wrote:
>> [sorry for taking a few days to reply...]
>>
>> * Jan Willem Stumpel [2006-01-18 14:41]:
>>
>>> This does not work in my case. Also interchanging the entries (US
>>> first,
>>> then GR) did not work. I mean you can get the accents, but not the
>>> breathing signs. Strangely enough, even calling
>>>
>>> LANG=el_GR.UTF-8 xterm
>>>
>>> and then doing things in the new xterm, did not work! I don't
>>> understand
>>> why. I have the el_GR.UTF-8 locale installed.
>>
>>
>> I really wonder why... I thought if you had a ~/.XCompose file, your
>> locale didn't matter (except if you specifically used it in that file,
>> by doing 'include "%L"'). Maybe it's not used at all?
>
> have been running scim at the time. It seems that when scim is running,
> only its own internal version of the compose file is used.
> Customisations in ῀/.XCompose do not work at all. With uim, they work.
> The Greek entry must of course come second in the ῀/.XCompose file. I
> do not know how uim does it.
>
> This also means that when you run scim, the ogonek and horn do not
> work as breathing signs even if the locale is el_GR.UTF-8, because
> scim's internal copy of the Compose file is only the "common" one.
will not work.
The reason is that the default Input Method, GTK+ IM does not know yet
about these dead keys and does not pass them on.
Therefore, when selecting Greek Polytonic in the X Input Method (XIM),
for example, using System/Preferences/Keyboard or adding the Keyboard
Indicator applet, all in GNOME (such as Ubuntu), you have to do first
export GTK_IM_MODULE=xim
then run OpenOffice.org
In standard GNOME applications you can change the the X Input Method
(XIM) if you right-click in any text box and select XIM from the context
sensitive menu.
Simos
p.s.
Did I write about this in a previous e-mail?
The GTK+ IM bug with not supporting Greek Polytonic is at
http://bugzilla.gnome.org/show_bug.cgi?id=321896
and we are stuck in how to interpret some additions in the Compose file.
Jan Willem Stumpel
> O/H Jan Willem Stumpel έγραψε:
>> This also means that when you run scim, the ogonek and horn
>> do not work as breathing signs even if the locale is
>> el_GR.UTF-8, because scim's internal copy of the Compose file
>> is only the "common" one.
>
> In addition, when you try to type Greek Polytonic in
> OpenOffice.org, it will not work. The reason is that the
> default Input Method, GTK+ IM does not know yet about these
> dead keys and does not pass them on. Therefore, when selecting
> Greek Polytonic in the X Input Method (XIM), for example, using
> System/Preferences/Keyboard or adding the Keyboard Indicator
> applet, all in GNOME (such as Ubuntu), you have to do first
>
> export GTK_IM_MODULE=xim then run OpenOffice.org
The situation is very complicated, because there are many factors
which can influence the result.
Yes, it is best to set GTK_IM_MODULE=xim (in Debian, you put this
in /etc/environment). Then you can enter polytonic Greek
everywhere (using the xkb facilities) *if* the
/etc/X11/xkb/symbols/pc/gr has been hacked, *and* the locale is
any type of UTF-8 (with the possible exception of el_GR.UTF-8),
*and* the application has access to a proper font.
As far as I could find out, with GTK_IM_MODULE=xim,
xkb-type polytonic Greek works (i.e. you can enter ᾆ) in just
about all situations; I tested all 12 combinations of 1-3 and A-D
below:
1. No input method framework present
2. uim present
3. scim present
A. text mode programs in xterm
B. mozilla, bluefish
C. openoffice
D. QT programs
With scim, at first I thought that there were program types in
which xkb polytonic Greek did not work. But this is (fortunately)
not the case. With scim, you must just take care that the keyboard
is set separately to "English/European" (i.e. direct input,
through xkb) for each application.
Some uim and scim docs recommend using GTK_IM_MODULE=uim or
GTK_IM_MODULE=scim. It seems this is not necessary;
GTK_IM_MODULE=xim works in all circumstances.
But with the original /etc/x11/xkb/symbols/pc/gr, with or without
el_GR.UTF-8 locale, polytonic Greek does not work with scim. I now
think the keyboard action is as follows:
without uim or scim:
keyboard --> xkb --> xlib Compose --> application
with uim:
keyboard --> xkb --> xlib Compose --> uim --> application
and with scim:
keyboard --> xkb --> scim΄s own Compose --> scim --> application
Regards, Jan
Simos Xenitellis
> Simos Xenitellis wrote:
> > O/H Jan Willem Stumpel έγραψε:
>
> >> do not work as breathing signs even if the locale is
> >> el_GR.UTF-8, because scim's internal copy of the Compose file
> >> is only the "common" one.
> >
> > In addition, when you try to type Greek Polytonic in
> > OpenOffice.org, it will not work. The reason is that the
> > default Input Method, GTK+ IM does not know yet about these
> > dead keys and does not pass them on. Therefore, when selecting
> > Greek Polytonic in the X Input Method (XIM), for example, using
> > System/Preferences/Keyboard or adding the Keyboard Indicator
> > applet, all in GNOME (such as Ubuntu), you have to do first
> >
> > export GTK_IM_MODULE=xim then run OpenOffice.org
>
> which can influence the result.
>
> Yes, it is best to set GTK_IM_MODULE=xim (in Debian, you put this
> in /etc/environment). Then you can enter polytonic Greek
> everywhere (using the xkb facilities) *if* the
> /etc/X11/xkb/symbols/pc/gr has been hacked, *and* the locale is
> any type of UTF-8 (with the possible exception of el_GR.UTF-8),
> *and* the application has access to a proper font.
GTK+ 2.x based applications that are linked to pango are in the happy
situation where glyphs from different fonts are grouped together to fill
in the Unicode table. Therefore, if you have at least one font in your
system that has Greek Polytonic support, this will be used for your GTK+
application. For issues like font preference for this, the file
/etc/fonts/fonts.conf (fontconfig) is used which can dictate where to
choose from first.
OpenOffice.org appears to do its internal choosing of fonts (does not
obey fontconfig), which causes some pain for Greek. Specifically, if the
selected font in OOo does not have Greek glyphs AND your distribution
has Asian support, Greek glyphs will be chosen from Asian fonts.
> As far as I could find out, with GTK_IM_MODULE=xim,
> xkb-type polytonic Greek works (i.e. you can enter ᾆ) in just
> about all situations; I tested all 12 combinations of 1-3 and A-D
> below:
>
> 1. No input method framework present
> 2. uim present
> 3. scim present
>
> A. text mode programs in xterm
AFAIK, xterm uses XIM by default.
> B. mozilla, bluefish
> C. openoffice
Both B and C are based on GTK+, so GTK_IM_MODULE to xim simply directs
them use the standard X Input Method. Any scim/uim/iiimf present cannot
affect these applications when GTK_IM_MODULE is set to xim.
> D. QT programs
QT uses XIM directly, so it is not affected by setting GTK_IM_MODULE.
The QT folks are actually trying to make a QT Input Method, similar to
GTK+ IM.
>
> With scim, at first I thought that there were program types in
> which xkb polytonic Greek did not work. But this is (fortunately)
> not the case. With scim, you must just take care that the keyboard
> is set separately to "English/European" (i.e. direct input,
> through xkb) for each application.
Indeed, that should be the case.
I did not find Greek Polytonic in either scim or uim, or even iiimf.
There was only modern Greek.
> Some uim and scim docs recommend using GTK_IM_MODULE=uim or
> GTK_IM_MODULE=scim. It seems this is not necessary;
> GTK_IM_MODULE=xim works in all circumstances.
By setting GTK_IM_MODULE to either xim, uim, scim or iiim, you enable
them for GTK+ applications. When the variable was set to "xim", any of
the other frameworks where not active for these GTK+ applications.
> But with the original /etc/x11/xkb/symbols/pc/gr, with or without
> el_GR.UTF-8 locale, polytonic Greek does not work with scim. I now
Which distribution are you using?
What are the changes that you have for the "gr" file that makes it work
for you?
The latest is
http://cvs.freedesktop.org/xlibs/xkbdesc/symbols/gr?view=markup
There is some work to update the settings for Greek Polytonic.
Two thoughts here are:
1. Place ¨ (dyalytika) on the same dead key as with modern Greek.
2. There is no way to type oxia; tonos and oxia are considered
equivalent in Unicode 3.0+ and tonos is preferred. However, if users
would rather have an oxia option, I feel we should provide it.
> think the keyboard action is as follows:
>
> without uim or scim:
>
> keyboard --> xkb --> xlib Compose --> application
>
> with uim:
>
> keyboard --> xkb --> xlib Compose --> uim --> application
>
> and with scim:
>
> keyboard --> xkb --> scim΄s own Compose --> scim --> application
I think that when one sets GTK_IM_MODULE for GTK+ applications, one
injects a framework between keyboard and "xkb".
Do you consider the key combination that switches between layouts as
part of xkb or xlib Compose? An important issue with all these
frameworks is that they make it difficult to have a single interface for
the end-user to use irrespective of the language she speaks.
Simos
Simos
Jan Willem Stumpel
>
> There is some work to update the settings for Greek Polytonic. Two
> thoughts here are: 1. Place ¨ (dyalytika) on the same dead key as
> with modern Greek. 2. There is no way to type oxia; tonos and oxia
> are considered equivalent in Unicode 3.0+ and tonos is preferred.
> However, if users would rather have an oxia option, I feel we should
> provide it.
I'll reply to your other points later when I have digested them (there
is a lot of information there) but your message made me realise only now
(sorry) that the tonos and oxia are really different. I thought it was
strange that the "acutus" was straight up instead of pointing to the
right. I thought this was a font problem. But it is not, because many
fonts already have different glyphs for Unicode ά (03AC, small alpha
with tonos) and ά (1F71, small alpha with oxia). It is a keyboard
problem. The keyboard does not distinguish between the two. Simple alpha
with acute accent becomes alpha with tonos. But if there are more
accents in the combination, the acute accent becomes oxia.
Proposal (I tested this, with the small alpha only, and it seems to
work):
-- Greek (modern and ancient) should use the common (international)
Compose file.
-- The international Compose file should have different definitions for
letters with simple tonos and letters with simple oxia. At present,
the Compose file has
<dead_acute> <Greek_alpha> : "ά" U03AC # GREEK SMALL LETTER ALPHA
WITH TONOS
(and grep "GREEK SMALL LETTER ALPHA" Compose|grep -v AND|grep OXIA
gives nothing!)
To distinguish between tonos and oxia, on the xkb side, something
should be chosen to represent the tonos.
Perhaps we could just use "apostrophe", but in my test I abused the
old "dead_horn", just like Alexandros did, but this time for modern
Greek:
<dead_horn> <Greek_alpha> : "ά" U03AC # GREEK SMALL LETTER ALPHA
WITH TONOS
<dead_acute> <Greek_alpha> : "ά" U1F71 # GREEK SMALL LETTER ALPHA
WITH OXIA
(For the time being, I put these things in ~/.XCompose, but they
should really be in the common file).
-- Then in xkb (/etc/X11/xkb/symbols/pc/gr) the AC11 key could be
defined as "dead_horn" in the default (modern Greek) section and as
"dead_acute" in the polytonic section.
"Modern Greeks" could then use setxkbmap gr (or the corresponding
definition in /etc/X11/xorg.conf) as usual. People who want to type
ancient Greek would use setxkbmap "gr(polytonic)", and would get oxia
instead of tonos for the same key combination. This of course assumes
that ancient Greek does not use the tonos, only the oxia. And there may
be other snags that I did not think of..
Regards, Jan
Thomas Wolff
with ancient Greek, but I noticed a few things.
Jan Willem Stumpel wrote:
> Proposal (I tested this, with the small alpha only, and it seems to
> work):
> -- Greek (modern and ancient) should use the common (international)
> Compose file.
> -- The international Compose file should have different definitions for
> letters with simple tonos and letters with simple oxia. At present,
> the Compose file has
> <dead_acute> <Greek_alpha> : "ά" U03AC # GREEK SMALL LETTER> ALPHA
> WITH TONOS
> (and grep "GREEK SMALL LETTER ALPHA" Compose|grep -v AND|grep OXIA
> gives nothing!)
It should actually list the following two entries from Unicode data:
1F71;GREEK SMALL LETTER ALPHA WITH OXIA;Ll;0;L;03AC;;;;N;;;1FBB;;1FBB
1FBB;GREEK CAPITAL LETTER ALPHA WITH OXIA;Lu;0;L;0386;;;;N;;;;1F71;
I guess that's due to the following comments quoted from
en_US.UTF-8/Compose (SUSE Linux 10.0):
# Part 2
# Compose map for Korean Hangul(Choseongul) Conjoining Jamos automatically
# generated from UnicodeData-2.0.14.txt at
# ftp://ftp.unicode.org/Public/2.0-Update/UnicodeData-2.0.14.txt
# by Jungshik Shin <js...@jshin.net> 2002-10-17
This means the Compose data are quite outdated (Unicode 2.0!) and should
be updated.
Jungshik Shin, would you provide us with the script or program that you
used to generate these entries automatically? That would be much
appreciated.
Actually, I would also like to equip my editor mined <http://towo.net/mined>
with compose data automatically generated from Unicode data. I could
do that myself but Jungshik Shin's contribution would help.
Also, the following information would help:
* What are the preferred keys that users would like to use to enter
oxia, tonos, etc as accent prefix or combination keys?
* Are any common keys (like quote mark, grave, acute) typically
associated with Greek accents or is that rather random and subject
to individual preference?
* Are any common keyboard mappings in use that set some de facto standard
here? What are their mappings?
If someone would answer these questions in a generic way (i.e. not
referring to X key names or mappings or even the more mysterious X
keyboard configuration properties), I would be grateful.
(I admit the questions are a little bit redundant, trying to achieve
the same result under different aspects.)
Thomas Wolff
Simos Xenitellis
http://planet.hellug.gr/misc/polytonic/
Although it is in Greek, it should be feasible to discern the
combinations proposed. For example, "Νεκρό πλήκτρο" is "Dead key" in the
list.
If there are queries, feel free to refer to me.
The "Compose" file should be broken in smaller files per script rather
than having a big monolithic file.
There is increasing interest in updating this area of Xorg
(http://community.livejournal.com/xkbconfig/) and I home it gets done soon.
Simos
Jan Willem Stumpel
> You can have a look at this document,
> http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it
> should be feasible to discern the combinations proposed. For example,
> "Νεκρό πλήκτρο" is "Dead key" in the list. If there are queries, feel
> free to refer to me.
Very interesting. Is this a proposal, or has it been implemented?
According to Babelfish, you say "Your distribution of Linux that
has been published after October 2005 should include the renewed system
that we describe here." Mine does not, but I don't trust the Babelfish
translation..
As far as I can see, it would not be difficult to implement it. Nothing
would have to be changed in the binaries, only in the xkb and Compose
files.
I noticed you only want to use 'two level' keys (normal and shift), not
using AltGr. Is this some kind of standard? (e.g. Greek national
standard, or some other kind of standard)? The present pc/gr file in xkb
uses 'three level' keys.
BTW I suppose when you say that tonos/oxia is on the ; key, you mean the
key which is ; on US keyboards, not the key which is ; on Greek keyboards?
> The "Compose" file should be broken in smaller files per script
> rather than having a big monolithic file.
What advantage would this bring? If we have many small pieces of the
Compose file, how is the user (or the system) supposed to decide when to
use which piece? Wouldn't this create another configuration problem?
UTF-8 allows using one system for all languages and scripts, without
changing locales. There is only one, IMHO unavoidable, but small,
disadvantage: some files (like fonts, and the Compose file) tend to
become rather big. But memory and disk space are not as expensive as
they used to be. And the user does not notice anything of this. She just
thinks: wow! I can input any language anywhere, at any time!
> There is increasing interest in updating this area of Xorg
> (http://community.livejournal.com/xkbconfig/) and I hope it gets done
> soon.
Hmm.. "xkb" and "Compose" are two completely different mechanisms. One
is input to the other. People often complain about xkb being
'mysterious' or 'arcane'. Since xfree86 4.3 and x.org came around, it
isn't anymore. It just lacks user-level documentation. Recently, thanks
to this list, I have come close enough to enlightenment to attempt a
user-level description on my utf-8 page, sections 6.1 and 6.2
(http://www.jw-stumpel.nl/stestu).
Regards, Jan
Simos Xenitellis
>
>
>> You can have a look at this document,
>> http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it
>> should be feasible to discern the combinations proposed. For example,
>> "Νεκρό πλήκτρο" is "Dead key" in the list. If there are queries, feel
>> free to refer to me.
>>
>
> According to Babelfish, you say "Your distribution of Linux that
> has been published after October 2005 should include the renewed system
> that we describe here." Mine does not, but I don't trust the Babelfish
> translation..
>
You are correct about October 2005. Several distributions were released
in October (Ubuntu, OpenSUSE) so the plan was to have the changes
upstream by the end of the summer so that they move to the new
distributions as they appear.
However, this plan did not work out and we still did not submit these
changes.
Konstantinos Pistiolis is working on this subject.
> As far as I can see, it would not be difficult to implement it. Nothing
> would have to be changed in the binaries, only in the xkb and Compose
> files.
>
> I noticed you only want to use 'two level' keys (normal and shift), not
> using AltGr. Is this some kind of standard? (e.g. Greek national
> standard, or some other kind of standard)? The present pc/gr file in xkb
> uses 'three level' keys.
>
Windows XP support Greek polytonic,
however, there is an inherent disadvantage that you cannot stuck more
than one dead key; due to this
quite a lot of keys have to be used as dead keys. In addition, if a
character accepts more than one diacritic,
then you need three dead keys to cover all the cases (diacritic A,
diacritic B, diacritic A+B).
Regarding the usage of AltGr. There have been quite a few discussions on
whether to use or not. I do not have the full details at my disposal.
Kostas, would you like to chip in for this?
> BTW I suppose when you say that tonos/oxia is on the ; key, you mean the
> key which is ; on US keyboards, not the key which is ; on Greek keyboards?
>
Indeed, ; it is the physical key according to the US keyboard.
The proposal document does not include a specific dead key to produce
oxia. In the Windows XP layout there is such a dead key,
in an uncomfortable location however, for those end-users who would like
to use it.
>
>> The "Compose" file should be broken in smaller files per script
>> rather than having a big monolithic file.
>>
>
> What advantage would this bring? If we have many small pieces of the
> Compose file, how is the user (or the system) supposed to decide when to
> use which piece? Wouldn't this create another configuration problem?
>
The configuration mechanism of Xorg would shield the end-user from this
complexity. I am referring to the needs of the developers.
For example, suppose a lesser known language wants to make an
installable package that adds writing support. The way this could be
done is by dropping (adding) the appropriate files in the appropriate
directory. Otherwise, there would be need to patch the monolithic file.
In addition, the Polytonic section in the Compose file is suitable to be
auto-generated from a script as the multiple diacritics on vowels bring up
combinations.
> UTF-8 allows using one system for all languages and scripts, without
> changing locales. There is only one, IMHO unavoidable, but small,
> disadvantage: some files (like fonts, and the Compose file) tend to
> become rather big. But memory and disk space are not as expensive as
> they used to be. And the user does not notice anything of this. She just
> thinks: wow! I can input any language anywhere, at any time!
>
As I mention above, the splitting of the files would be an advantage for
the developers.
The end-user would only see a GUI configuration tool. No setxkbmap or
editing of xorg.conf.
>> There is increasing interest in updating this area of Xorg
>> (http://community.livejournal.com/xkbconfig/) and I hope it gets done
>> soon.
>>
>
> Hmm.. "xkb" and "Compose" are two completely different mechanisms. One
> is input to the other. People often complain about xkb being
> 'mysterious' or 'arcane'. Since xfree86 4.3 and x.org came around, it
> isn't anymore. It just lacks user-level documentation. Recently, thanks
> to this list, I have come close enough to enlightenment to attempt a
> user-level description on my utf-8 page, sections 6.1 and 6.2
> (http://www.jw-stumpel.nl/stestu).
>
Thanks for this.
We need to put effort so that gswitchit (Keyboard Indicator applet in
GNOME) gets more and more advanced and ubiquitous.
The plan is for gswitchit to be used for KDE as well.
This is the proper direction so end-users are happy that their settings
just work.
Jan Willem Stumpel
> [..]
> With this font, I can capture the entire entry, no problems, pointing
> fingers, arrows, boxes, tiny-elvises, polygreek etymology... There is
> virtually nothing I cannot do with the Unicode character set alone.
And in another message:
> http://modern-greek-verbs.tripod.com/home.html#unicode
Your document is impressive, and it clearly shows why we need Unicode (a
system which allows mixing many different languages in one document) and
also why we need input systems capable of switching between languages
very quickly (i.e. not requiring going through complicated nested menus).
Fonts are not a real problem. There are many fonts which can display
both ancient and modern Greek in UTF-8. You do not especially need the
XP version of Times New Roman (although thanks for the tip).
As far as switching between Latin and Greek is concerned, I would
recommend setting the "group toggle" key to only one single key, not
something like control-alt-K. I just set it to "Left-Windows" which (on
my system) is not used for anything useful. It really cycles, i.e. when
you get to the end of the possible groups, you get back to the
beginning. That does not seem to work for you; I do not know why.
Greek is, of course, a language which is enormously important in the
history of civilisation, and is therefore of interest to people from
many different cultures (or, in computer terms, 'locales'). Such people
could very well be resident in Greece, so they need to enter both
'ancient' and 'modern' Greek in their computers with a minimum of fuss.
Therefore now I think that there should be either
-- one "gr" keyboard layout which allows entering both modern and
ancient Greek.
-- two "gr" keyboard layout variants, one which is optimised for modern
Greek, and another one which enables inputting BOTH ancient and
modern Greek (i.e both tonos and oxía) - although it might be
somewhat sub-optimal compared to a keyboard which is 'modern Greek
only'.
BTW What is a 'tiny elvis'?
Regards, Jan
Jan Willem Stumpel
> Hello Thomas,
>
> It looks like we're all looking for non-standard ways to
> capture polytonic Greek in Linux. This must mean no keymap
> exists. Given one hundred years I'll figure out xkb and write
> one.
xkb is not so difficult to figure out. At the moment you can
already enter polytonic Greek with it, and if you set the
Greek/Latin switch to a single key (I use left-windows), entering
mixed text consisting of Greek and Latin is not difficult.
The problem is: what is, from a user point of view, the desired
behaviour of the keyboard? At the moment xkb gr(polytonic) has:
key US GR keysym with gives
<AD11> [ [ dead_tilde α ᾶ (perispomeni)
shift<AD11> { { dead_diaeresis υ (=y) ϋ (dialytika)
altgr<AD12> « dead_macron α ᾱ (macron)
<AD12> ] ] dead_iota α ᾳ (iota subscript)
shift<AD12> } } VoidSymbol α α (does nothing)
altgr<AD12> » dead_breve α ᾰ (breve)
<AC10> ; ´ dead_acute α ά (tonos/oxia)
shift<AC10> : ¨ dead_horn α ἀ (psili)
altgr<AC10> ΅ [not defined] α α (does nothing)
<AC11> ' ' dead_grave α ὰ (varia)
shift<AC11> " " dead_ogonek α ἁ (dasia)
altgr<AC11> [not defined] α α (does nothing)
AC and AD indicate the third and fourth keyboard row from below,
respectively. The number indicates the position of the key
counting from the left, but not counting shift, capslock, tab.
The column "US" shows which symbols are engraved on the physical
keys of a standard US PC 104 keyboard. The column "GR" shows what
is engraved on the physical keys of a Greek keyboard, according to
Wikipedia (http://en.wikipedia.org/wiki/Keyboard_layout#Greek). I
do not know how standard this is (in Greece).
The keysyms dead_ogonek and dead_horn are only interpreted as
dasia and psili if the locale is el_GR.UTF-8. To use gr(polytonic)
with 'international' UTF-locales, these keysyms should be replaced
by 0x1000314 and 0x1000313 respectively (edit the file
/etc/X11/xkb/symbols/pc/gr).
Combinations, like ᾄ, are also possible; you have to use a fixed
order:
-- iota subscript first
-- accent second
-- breathing third
So for ᾧ you woud enter the keystroke sequence (keys as marked on
a US keyboard) ]["v. [The order, I admit, seems unnatural. The
order that you propose looks better. This can be changed in the
Compose file, and maybe it should be filed as a bug -- but where?
Where does the Compose file come from?]
This works in openoffice, mozilla, and any text-mode editor you like.
The question is, is this a workable system in practice? I am sure
any desired keyboard behaviour could easily be made to work with
the tools we have (editing the files in /etc/X11/xkb and the
Compose file).
For instance, earlier on the list, Simos Xenitellis called
attention to a proposal for polytonic handling in Linux:
http://planet.hellug.gr/misc/polytonic/
This document has some keyboard combination tables of which a
small part is given below:
tonos/oxia ΄ Dead key (;) + vowel
dialytika ¨ Dead key (:) + vowel (only υ, ι)
perispomeni ῀ Dead key ([) + vowel
iota subscript ͺ Dead key ({) + vowel
psili ᾿ Dead key (') + vowel/ρ
dasia ῾ Dead key (") + vowel/ρ
varia ` Dead key (/) + vowel
macron ¯ Dead key (]) + vowel
breve ˘ Dead key (}) + vowel
Only a few of those are the same as what xkb now provides, but it
is easy to change /etc/X11/xkb/symbols/pc/gr to give it this
behaviour:
xkb_symbols "polytonic" {
include "pc/el(extended)"
name[Group1] = "Greece - Polytonic";
key <AD11> { [ dead_tilde, dead_iota ] };
key <AD12> { [ dead_macron, dead_breve ] };
key <AC10> { [ dead_acute, dead_diaeresis ] };
key <AC11> { [ 0x1000313, 0x1000314 ] };
key <AB10> { [ dead_grave, question ] };
};
This of course makes the / key "dead". The AltGr key is no longer
used. The Compose file does not have to be changed, but if the
other characters mentioned in the 'proposal' would have to be
entered (koppa, digamma, etc.) a few lines should be added to it.
Would this be easier to use than the present xkb system? I don't
know.
Thomas Wolff suggests using 'unused' keys like F6 for oxia, etc.
Again, I think that usability is the most important criterion for
the choice. To type Greek you would have to switch your keyboard
from Latin to Greek anyway. In the 'Greek' state all keys can get
a different function. Ideally the 'Greek' keys would do similar
things to 'Latin' keys (i.e. dead tilde would become dead
perispomeni, dead acute would become dead tonos, perhaps alt-i
could become dead_iota, etc.). But there does not seem to be a
special need to look for 'unused' keys, because in 'Greek' mode,
keys can be re-used.
Finally, would the system which is available on Windows XP
(http://www.microsoft.com/globaldev/perspectives/polytonic.mspx)
be better for people who type a lot of polytonic? This may require
fewer keystrokes. However, there are a lot of altgr and
shift-altgr combinations, and it looks like it would take quite
some effort to learn them. To make this method work on Linux it
seems we would have to invent keysyms for 'combined accents'
(treating, for instance, dasia+oxia+dead_iota as 'one thing'). Or
perhaps existing keysyms could be (ab)used, like the ogonek in the
original xkb gr file. It certainly can be done (although it would
be a bit of work). Well, unless μ$ has patented this.
> [..] The encoding always begins with the breathing (if it
> exists)followed by the accents (if they exist) followed by the
> iota subscript (if it exists). [My locale Config file at home
> has listed all the combinations in any order, but I find that
> tedious.]
> [..] The perl script works. Here it is: [..]
It certainly works, but it is an 'off-line' method, similar to the
beta code to utf-8 converter by Dimitri Marinakis
(http://tlgu.carmen.gr). Such utilities are useful, but wouldn't
it be better to type polytonic utf-8 directly?
Ceterum censeo /usr/lib/X11/locale/el_GR.UTF-8/Compose esse delendam.
Regards, Jan
http://www.jw-stumpel.nl/stestu
Vasilis Vasaitis
On Tue, May 09, 2006 at 09:04:52PM +0300, Joe Schaffner wrote:
..[snip]..
> <dead_acute> is on the semi-colon key and <dead_horn> is on the same
> key, shifted, the colon key.
>
> <dead_grave> is on the single-quote key and <dead_ogonek> is on the
> double-quote key.
>
> That's a pretty good layout. I like it.
>
> Why not name these keysyms <dead_psili> and <dead_dasia>?
Because the list of keysyms is fixed, as defined in
/usr/include/X11/keysymdef.h. At the time, using arbitrary existing
keysyms made more sense than petitioning for "correctly-named" new
ones. It works, after all. But OK, now maybe it's time to ask for a
few new names if people are annoyed by the current state of affairs.
> Anyway, I activate the gr keymap like this:
>
> setxkbmap "us,gr(polytonic)" -option "grp:alt_shift_toggle"
>
> The command syntax is troublesome. There seem to be other ways of
> doing it. Maybe I'm wrong, but it seems to work.
The canonical invocation would be:
setxkbmap -layout us,gr -variant ,polytonic \
-option grp:alt_shift_toggle
> Yes, the keymap is there, I can see it on the task bar. To switch to
> another group, I can use the alt_shift combination (another meta
> symbol? Where are all these symbols defined?).
In /etc/X11/xkb, rules/xorg transforms grp:alt_shift_toggle to
group(alt_shift_toggle). So you can look at the relevant section in
symbols/group to see how this implements the layout switching. It all
boils down to the generation of the ISO_Next_Group and ISO_Prev_Group
keysyms.
> Yes, I can enter greek characters. The <dead_acute> seems to work, but
> I am not sure if it is outputting a tonos or a acute. It's probably a
> tonos.
>
> None of the other dead keys seem to work.
>
> Any ideas?
For the others to work, you need to have at least
LC_CTYPE=el_GR.UTF-8. In my system, with LANG=el_GR.UTF-8, everything
is working as it should. Keep in mind that for GTK+ applications you
also need GTK_IM_MODULE=xim defined (or else you have to right-click
on each textbox, and select Input Methods -> X Input Method).
--
Vasilis Vasaitis
"A man is well or woe as he thinks himself so."
Danilo Segan
> For the others to work, you need to have at least
> LC_CTYPE=el_GR.UTF-8. In my system, with LANG=el_GR.UTF-8, everything
> is working as it should. Keep in mind that for GTK+ applications you
> also need GTK_IM_MODULE=xim defined (or else you have to right-click
> on each textbox, and select Input Methods -> X Input Method).
With a more recent X, you can also create your own ~/.Xcompose and
stick relevant combinations there.
Cheers,
Danilo
Jan Willem Stumpel
> After lengthy consideration, I have come to the conclusion xkb
> [..] only maps keyboard events to keysyms, which are not
> characters
Many of them really are just characters.
> I have these two keymaps i.e. "groups" on my system:
>
> /etc/X11/xkb/symbols/el -- The one I'm using
>
> /etc/X11/xkb/symbols/gr -- The dirty bastard
Isn't this dirty bastard /etc/X11/xkb/symbols/pc/gr? Which version
of X do you have?
> include "el(extended)"
This shows that you are really using both, because gr includes el.
BTW in newer versions of X there is no el, only the dirty bastard.
> key.type = "THREE_LEVEL";
>
> key <AD11> {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
> key <AD12> {[], [ dead_iota, VoidSymbol, dead_breve ]};
>
> key <AC10> {[], [ dead_acute, dead_horn ]};
> key <AC11> {[], [ dead_grave, dead_ogonek ]};
>
> };
>
> I assume the list of keysyms captures the shifted state of the
> key i.e. <dead_acute> is on the semi-colon key and <dead_horn>
> is on the same key, shifted, the colon key.
Yes, and in the case of three-level keys, the third level is
accessed by the AltGr key (right-alt, most probably). So that's
how you get the dead macron etc.
Some keys might be four-level, in which case the fourth level is
accessed by means of Shift-AltGr.
> <dead_grave> is on the single-quote key and <dead_ogonek> is on
> the double-quote key.
>
> That's a pretty good layout. I like it.
>
> Why not name these keysyms <dead_psili> and <dead_dasia>?
Because these names are not known to "the system". However, all
UTF-8 characters are known to "the system" by default, having
names beginning with U. So the designer of this layout could, and
in my opinion should, have called them U0313 (for the dead psili)
and U0314 (for the dead dasia).
This would have avoided the need for a special Greek Compose file,
the existence of which is just a bother, ergo censeo delendam
esse. There already exists an international Compose file (it is
called the "US" file but it is really international), which serves
all languages, including ancient and modern Greek, and which knows
how to combine U0313 and U0314 with Greek letters and with other
accents.
> Anyway, I activate the gr keymap like this:
>
> setxkbmap "us,gr(polytonic)" -option "grp:alt_shift_toggle"
>
> The command syntax is troublesome. There seem to be other ways
> of doing it. Maybe I'm wrong, but it seems to work.
You can put the keyboard options in the X configuration file
(/etc/X11/xorg.conf, or /etc/X11/XF86Config-4).
> [..] Yes, I can enter greek characters. The <dead_acute> seems to
> work, but I am not sure if it is outputting a tonos or a acute.
> It's probably a tonos.
It should be, because having a separate acute is not considered
correct anymore. The fonts you use should display the tonos as an
acute. But if you really want to have the separate acute (oxia),
there are ways.
> None of the other dead keys seem to work.
>
> Any ideas?
All the dead keys can be made to work. It is not magic; it is not
even difficult. I apologise for blowing my own horn, but perhaps
you really should read the bits relating to "keyboard" and "Greek"
on http://www.jw-stumpel.nl/stestu.html.
> It would be nice to see the entire character map in the same
> place.
To get a picture of your character map (or maps, if you have
defined multiple maps) you could try
xkbcomp -xkm $DISPLAY
xkbprint server-0_0.xkm server-0_0.eps
The resulting file, server-0_0.eps, can be viewed with gv. This
xkbprint system seems a little bit flaky, though. You may have
difficulty actually printing the map.
Regards, Jan
Simos Xenitellis
>
>> After lengthy consideration, I have come to the conclusion xkb
>> [..] only maps keyboard events to keysyms, which are not
>> characters
>>
>
> Many of them really are just characters.
>
>
>> I have these two keymaps i.e. "groups" on my system:
>>
>> /etc/X11/xkb/symbols/el -- The one I'm using
>>
>> /etc/X11/xkb/symbols/gr -- The dirty bastard
>>
>
> Isn't this dirty bastard /etc/X11/xkb/symbols/pc/gr? Which version
> of X do you have?
>
>
>> include "el(extended)"
>>
>
> This shows that you are really using both, because gr includes el.
> BTW in newer versions of X there is no el, only the dirty bastard.
>
configurations continue to work.
This is in Xorg 7.0+ and xkeyboard-config, in earlier Xorg your mileage
may vary.
>> key.type = "THREE_LEVEL";
>>
>> key <AD11> {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
>> key <AD12> {[], [ dead_iota, VoidSymbol, dead_breve ]};
>>
>> key <AC10> {[], [ dead_acute, dead_horn ]};
>> key <AC11> {[], [ dead_grave, dead_ogonek ]};
>>
>> };
>>
>> I assume the list of keysyms captures the shifted state of the
>> key i.e. <dead_acute> is on the semi-colon key and <dead_horn>
>> is on the same key, shifted, the colon key.
>>
>
> Yes, and in the case of three-level keys, the third level is
> accessed by the AltGr key (right-alt, most probably). So that's
> how you get the dead macron etc.
>
> Some keys might be four-level, in which case the fourth level is
> accessed by means of Shift-AltGr.
>
>
>> <dead_grave> is on the single-quote key and <dead_ogonek> is on
>> the double-quote key.
>>
>> That's a pretty good layout. I like it.
>>
>> Why not name these keysyms <dead_psili> and <dead_dasia>?
>>
>
> Because these names are not known to "the system". However, all
> UTF-8 characters are known to "the system" by default, having
> names beginning with U. So the designer of this layout could, and
> in my opinion should, have called them U0313 (for the dead psili)
> and U0314 (for the dead dasia).
>
edited so that any numbers have 0x10000000 added to them.
For more on this and the chance to try out such an updated Compose file, see
https://bugs.freedesktop.org/show_bug.cgi?id=5129
I did not manage to try the file myself as I run Breezy (Oldish Xorg 6.8.2).
In Xorg 6.8.2 on Breezy I have an issue of typing psili, daseia and
several other combinations based on these. I think this relates to the
merging of the greek compose file
to the common international one.
See
https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/21637
for more.
If someone has Xorg 7.0 and want to try out, please do and report back.
> This would have avoided the need for a special Greek Compose file,
> the existence of which is just a bother, ergo censeo delendam
> esse. There already exists an international Compose file (it is
> called the "US" file but it is really international), which serves
> all languages, including ancient and modern Greek, and which knows
> how to combine U0313 and U0314 with Greek letters and with other
> accents.
>
I second that.
You can also use "xev". Run it from command line and give focus to the
"xev" window.
Switch keyboard to Greek Polytonic and type ancient greek. You will be
able to see
the individual characters being sent. You will also be able to see if
GTK+ filters and cuts off any dead keys.
There are some patches for GTK+ to add support for Greek polytonic
(it actually synchs Compose-Xorg with GTK+).
If you are the compile type of person (Gentoo?), try out
http://bugzilla.gnome.org/show_bug.cgi?id=321896
Joe Schaffner
It looks like my system is configured properly, only something is not
working, perhaps in the implementation. I have a SuSE 9.2 which I
installed last year, but I believe I have seen copyright notices
dating to 2003.
I know that 9.3 came out last year, and I think a friend of mine was
telling me that 9.4 was already available.
Only I don't have the time to make such frequent updates. For the
moment, I'll stick with my perl script. It's really no problem. In
fact, it's GRRRRREAT!
You know, I have Fedora on another partition. Maybe I'll give that a
try... Oh yeah, I did. It didn't work either, and the configuration
files were virtually identical.
Let's drink a toast... to the next version!
Cheers!
Joe
http://modern-greek-verbs.tripod.com/sarris/
On 5/10/06, Jan Willem Stumpel <jstu...@planet.nl> wrote:
> Joe Schaffner wrote:
> > After lengthy consideration, I have come to the conclusion xkb
> > [..] only maps keyboard events to keysyms, which are not
> > characters
>
> Many of them really are just characters.
>
> > I have these two keymaps i.e. "groups" on my system:
> >
> > /etc/X11/xkb/symbols/el -- The one I'm using
> >
> > /etc/X11/xkb/symbols/gr -- The dirty bastard
>
> Isn't this dirty bastard /etc/X11/xkb/symbols/pc/gr? Which version
> of X do you have?
>
> > include "el(extended)"
>
> This shows that you are really using both, because gr includes el.
> BTW in newer versions of X there is no el, only the dirty bastard.
>
> > key.type = "THREE_LEVEL";
> >
> > key <AD11> {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
> > key <AD12> {[], [ dead_iota, VoidSymbol, dead_breve ]};
> >
> > key <AC10> {[], [ dead_acute, dead_horn ]};
> > key <AC11> {[], [ dead_grave, dead_ogonek ]};
> >
> > };
> >
> > I assume the list of keysyms captures the shifted state of the
> > key i.e. <dead_acute> is on the semi-colon key and <dead_horn>
> > is on the same key, shifted, the colon key.
>
> Yes, and in the case of three-level keys, the third level is
> accessed by the AltGr key (right-alt, most probably). So that's
> how you get the dead macron etc.
>
> Some keys might be four-level, in which case the fourth level is
> accessed by means of Shift-AltGr.
>
> > <dead_grave> is on the single-quote key and <dead_ogonek> is on
> > the double-quote key.
> >
> > That's a pretty good layout. I like it.
> >
> > Why not name these keysyms <dead_psili> and <dead_dasia>?
>
> Because these names are not known to "the system". However, all
> UTF-8 characters are known to "the system" by default, having
> names beginning with U. So the designer of this layout could, and
> in my opinion should, have called them U0313 (for the dead psili)
> and U0314 (for the dead dasia).
>
> This would have avoided the need for a special Greek Compose file,
> the existence of which is just a bother, ergo censeo delendam
> esse. There already exists an international Compose file (it is
> called the "US" file but it is really international), which serves
> all languages, including ancient and modern Greek, and which knows
> how to combine U0313 and U0314 with Greek letters and with other
> accents.
>
> Regards, Jan
Danilo Segan
Today at 13:02, Jan Willem Stumpel wrote:
>> key.type = "THREE_LEVEL";
>>
>> key <AD11> {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
>> key <AD12> {[], [ dead_iota, VoidSymbol, dead_breve ]};
>>
>> key <AC10> {[], [ dead_acute, dead_horn ]};
>> key <AC11> {[], [ dead_grave, dead_ogonek ]};
>>
>> };
>>
>> I assume the list of keysyms captures the shifted state of the
>> key i.e. <dead_acute> is on the semi-colon key and <dead_horn>
>> is on the same key, shifted, the colon key.
>
> Yes, and in the case of three-level keys, the third level is
> accessed by the AltGr key (right-alt, most probably). So that's
> how you get the dead macron etc.
Note that the layout listed above contains two *groups* as well,
i.e. it's not an xkeyboard-config layout (or, do we still have some of
these left?)
> Some keys might be four-level, in which case the fourth level is
> accessed by means of Shift-AltGr.
Not with key.type = "THREE_LEVEL". :)
> Because these names are not known to "the system". However, all
> UTF-8 characters are known to "the system" by default, having
> names beginning with U. So the designer of this layout could, and
> in my opinion should, have called them U0313 (for the dead psili)
> and U0314 (for the dead dasia).
I think U-ames are available only for those Unicode characters not
having any other representation in keysymdef.h.
Cheers,
Danilo