Experiments with classical Greek keyboard input

Discussion:

Jan Willem Stumpel

2006-01-14 15:46:12 UTC

Some results for classical Greek: this is with Debian Sid, en_GB.UTF-=
8
locale, PC104 (US) keyboard. No KDE, no Gnome. Just X with icewm.

Uim and scim do not provide methods for classical Greek. The immodule=
=20
im-classicalgreek does not seem to work anymore with the newer versio=
ns=20
(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. =E1=BF=B6, =E1=BE=B6
dead macron on the [ key with left-windows pressed, e.g. =E1=BE=B1.
dead iota subscriptum on the ] key, e.g. =E1=BE=B3, =E1=BF=83, =E1=
=BF=B3
dead acute accent on the ; key, e.g. =CF=8D, =CE=AC, =CE=AF
dead grave accent on the ' key, e.g. =E1=BD=B0, =E1=BD=B8, =E1=BD=
=B6

Accents can be combined, e.g. ][v becomes =E1=BF=B7, ];h becomes =
=E1=BF=84. The iota
always has to be entered first.

But there is no way to enter the "breathing" signs (spiritus asper an=
d
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 th=
e ;=20
and ' keys, when the left-windows key is pressed. It is then possible=
to=20
enter things like =E1=BE=A6, =E1=BE=94, =E1=BE=87, =E1=BF=A5. The bre=
athing signs have to be entered=20
last (just before the letter itself).

This system is far from ideal. It should be possible to change from t=
he
default keyboard to classical Greek (and back) by some hotkey instead=
of=20
a setxkbmap command. And also, several accent combinations can,
apparently, only be entered in xterm and openoffice, but not in Mozil=
la.
Suggestions for improvement are greatly appreciated. Apologies in=
=20
advance if all this has been covered before.

Regards, Jan

James Cloos

2006-01-14 21:21:51 UTC

Permalink

This post might be inappropriate. Click to display it.

Alexandros Diamantidis

2006-01-14 22:39:06 UTC

Permalink

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 * ***@hellug.gr

Jan Willem Stumpel

2006-01-16 20:52:08 UTC

Permalink

When I made an initial try at a polytonic Greek keyboard, I couldn'=

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=

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 ent=
er
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, whic=
h
uses extra levels (instead of a new group) to get the same effect. Th=
e
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-int=
l)
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 Gr=
eek
mode. All characters, including things like =E1=BE=A6, 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 COM=
MA
ABOVE (0x1000313) and COMBINING REVERSED COMMA ABOVE (0x1000314); the
(default?) US Compose file then has lots of entries for combined Gree=
k
characters.

This change would probably break things for Greek users unless the Gr=
eek
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 cann=
ot
reach the 4th level symbols (you see the warnings after closing X), l=
ike:

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

2006-01-16 23:25:25 UTC

Permalink

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
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...

--
Alexandros Diamantidis * ***@hellug.gr

Jan Willem Stumpel

2006-01-18 13:41:56 UTC

Permalink

All characters, including things like =E1=BE=A6, can be made in Gre=

mode, even in en_GB.UTF-8 locale, if the dead ogonek and horn in th=

symbols/pc/gr file are replaced [..]

Right, that's one way to do it. Another way would be to create a cu=

stom

personal compose file, which includes both the US and GR Compose fi=

les.

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.
=20
I think if you put the following two lines in ~/.XCompose it will w=
=20
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 fir=
st,
then GR) did not work. I mean you can get the accents, but not the
breathing signs. Strangely enough, even calling

LANG=3Del_GR.UTF-8 xterm

and then doing things in the new xterm, did not work! I don't underst=
and
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, us=
ers
must change their locale to Greek to use polytonic Greek (if they wan=
t=20
to use the xkb facilities). But in the true UTF-8 spirit, we should b=
e=20
able to read/print/enter *anything* from *any* locale, as long as it =
is=20
a UTF-8 one.

So perhaps /etc/X11/xkb/symbols/pc/gr should really be changed to=
=20
include the UTF-8 'breathing' signs. Then, I suppose,=20
/usr/lib/X11/locale/en_US.UTF-8/Compose could be used for Greek, as i=
t
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

Alexandros Diamantidis

2006-01-21 14:38:20 UTC

Permalink

This post might be inappropriate. Click to display it.

Jan Willem Stumpel

2006-01-21 17:53:57 UTC

Permalink

Post by Alexandros Diamantidis
[sorry for taking a few days to reply...]
=20
=20

Post by Jan Willem Stumpel
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
=20
LANG=3Del_GR.UTF-8 xterm
=20
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.

=20
=20
I really wonder why... I thought if you had a ~/.XCompose file, you=

r=20

Post by Alexandros Diamantidis
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 cou=

Post by Alexandros Diamantidis
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 re=
sults.

Post by Alexandros Diamantidis
[..]

Post by Jan Willem Stumpel
So perhaps /etc/X11/xkb/symbols/pc/gr should really be changed to=

=20

Post by Alexandros Diamantidis

Post by Jan Willem Stumpel
include the UTF-8 'breathing' signs.

=20
=20
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': th=
e
Unicode standard (http://www.unicode.org/charts/PDF/U0300.pdf) says t=
hat
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> : "=E1=BE=A6"
U1FA6 # GREEK SMALL LETTER OMEGA WITH PSILI AND PERISPOMENI AND
YPOGEGRAMMENI

In fact there are 20 different compose sequences in the file for the =
=E1=BE=A6
character alone! Some of them involve 5 keystrokes, using ( and ) to
input the 'breathing' signs. I've no idea who put all these definitio=
ns in.

So polytonic Greek does not really need its own Compose file; everyth=
ing
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 tha=
t
the /etc/X11/xkb/symbols/pc/gr file has to reflect this. The dead_hor=
n
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

2006-01-22 13:21:48 UTC

Permalink

Post by Alexandros Diamantidis
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

2006-01-23 11:17:20 UTC

Permalink

Post by Alexandros Diamantidis
[sorry for taking a few days to reply...]
=20
=20

This does not work in my case. Also interchanging the entries (US f=

irst,

Post by Alexandros Diamantidis

then GR) did not work. I mean you can get the accents, but not the
breathing signs. Strangely enough, even calling
LANG=3Del_GR.UTF-8 xterm
and then doing things in the new xterm, did not work! I don't under=

stand

Post by Alexandros Diamantidis

why. I have the el_GR.UTF-8 locale installed.

=20
=20
I really wonder why... I thought if you had a ~/.XCompose file, you=

Post by Alexandros Diamantidis
locale didn't matter (except if you specifically used it in that fi=

le,

Post by Alexandros Diamantidis
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 runnin=
g,
only its own internal version of the compose file is used.=20
Customisations in =E1=BF=80/.XCompose do not work at all. With uim, t=
hey work.=20
The Greek entry must of course come second in the =E1=BF=80/.XCompose=
file. I do=20
not know how uim does it.

This also means that when you run scim, the ogonek and horn do not wo=
rk=20
as breathing signs even if the locale is el_GR.UTF-8, because scim's=
=20
internal copy of the Compose file is only the "common" one.

Regards, Jan

Simos Xenitellis

2006-01-25 16:31:36 UTC

Permalink

Post by Jan Willem Stumpel

Post by Alexandros Diamantidis
[sorry for taking a few days to reply...]

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.

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

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

2006-01-26 19:29:51 UTC

Permalink

Post by Simos Xenitellis

Post by 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.

=20
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
=20
export GTK_IM_MODULE=3Dxim 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=3Dxim (in Debian, you put this=
=20
in /etc/environment). Then you can enter polytonic Greek=20
everywhere (using the xkb facilities) *if* the=20
/etc/X11/xkb/symbols/pc/gr has been hacked, *and* the locale is=20
any type of UTF-8 (with the possible exception of el_GR.UTF-8),=20
*and* the application has access to a proper font.

As far as I could find out, with GTK_IM_MODULE=3Dxim,
xkb-type polytonic Greek works (i.e. you can enter =E1=BE=86) in just=
=20
about all situations; I tested all 12 combinations of 1-3 and A-D=
=20
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)=
=20
not the case. With scim, you must just take care that the keyboard=
=20
is set separately to "English/European" (i.e. direct input,=20
through xkb) for each application.

Some uim and scim docs recommend using GTK_IM_MODULE=3Duim or
GTK_IM_MODULE=3Dscim. It seems this is not necessary;=20
GTK_IM_MODULE=3Dxim works in all circumstances.

But with the original /etc/x11/xkb/symbols/pc/gr, with or without=
=20
el_GR.UTF-8 locale, polytonic Greek does not work with scim. I now=
=20
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=CE=84s own Compose --> scim --> application

Regards, Jan

Simos Xenitellis

2006-01-27 14:42:01 UTC

Permalink

Post by Jan Willem Stumpel

Post by Simos Xenitellis

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.

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.

Post by Jan Willem Stumpel
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
1. No input method framework present
2. uim present
3. scim present
A. text mode programs in xterm

AFAIK, xterm uses XIM by default.

Post by Jan Willem Stumpel
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.

Post by Jan Willem Stumpel
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.

Post by Jan Willem Stumpel
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.

Post by Jan Willem Stumpel
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.

Post by Jan Willem Stumpel
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.

Post by Jan Willem Stumpel
keyboard --> xkb --> xlib Compose --> application
keyboard --> xkb --> xlib Compose --> uim --> application
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

2006-01-27 21:05:34 UTC

Permalink

=20
There is some work to update the settings for Greek Polytonic. Two
thoughts here are: 1. Place =C2=A8 (dyalytika) on the same dead key=

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 shoul=

provide it.

I'll reply to your other points later when I have digested them (ther=
e
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 wa=
s
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 =CE=AC (03AC, small a=
lpha
with tonos) and =E1=BD=B1 (1F71, small alpha with oxia). It is a keyb=
oard
problem. The keyboard does not distinguish between the two. Simple al=
pha
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 f=
or
letters with simple tonos and letters with simple oxia. At present=
,
the Compose file has

<dead_acute> <Greek_alpha> : "=CE=AC" 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 th=
e
old "dead_horn", just like Alexandros did, but this time for moder=
n
Greek:

<dead_horn> <Greek_alpha> : "=CE=AC" U03AC # GREEK SMALL LETTER =
ALPHA
WITH TONOS

<dead_acute> <Greek_alpha> : "=E1=BD=B1" U1F71 # GREEK SMALL LETT=
ER 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 a=
s
"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 m=
ay
be other snags that I did not think of..

Regards, Jan

Thomas Wolff

2006-01-30 11:28:40 UTC

Permalink

I've only followed this discussion partially because I'm not familiar
with ancient Greek, but I noticed a few things.

Post by Jan Willem Stumpel
Proposal (I tested this, with the small alpha only, and it seems to
-- 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 <***@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

2006-01-30 13:05:26 UTC

Permalink

Post by Thomas Wolff
I've only followed this discussion partially because I'm not familiar
with ancient Greek, but I noticed a few things.

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
# 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
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.
* 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.)

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.

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

2006-01-30 18:14:56 UTC

Permalink

You can have a look at this document,=20
http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it
should be feasible to discern the combinations proposed. For exampl=

"=CE=9D=CE=B5=CE=BA=CF=81=CF=8C =CF=80=CE=BB=CE=AE=CE=BA=CF=84=CF=

=81=CE=BF" 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 syst=
em
that we describe here." Mine does not, but I don't trust the Babelfis=
h
translation..

As far as I can see, it would not be difficult to implement it. Nothi=
ng
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), n=
ot
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 keybo=
ards?

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 j=
ust
thinks: wow! I can input any language anywhere, at any time!

There is increasing interest in updating this area of Xorg=20
(http://community.livejournal.com/xkbconfig/) and I hope it gets do=

soon.

Hmm.. "xkb" and "Compose" are two completely different mechanisms. On=
e
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, than=
ks
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

2006-01-30 19:05:26 UTC

Permalink

Post by Jan Willem Stumpel

Post by 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.

The referenced document is indeed a proposal.
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.

Post by Jan Willem Stumpel
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.

As far as I know there is no national standard for Greek polytonic.
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?

Post by Jan Willem Stumpel
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.

Post by Jan Willem Stumpel

Post by Simos Xenitellis
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.

Post by Jan Willem Stumpel
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.

Post by Jan Willem Stumpel

Post by Simos Xenitellis
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.

Simos

Joe Schaffner

2006-02-01 19:56:41 UTC

Permalink

Hi Simos,

How you doing?

Hello to everybody else, Ed Trager, you still there?

I'm sure I'm forgetting some of you. Sorry.

It's me, Elvis, the guy who had problems with xkb last year. You were
all a great help. I could never have fixed the problems myself. My
system still works, better than ever..

Sorry, I have to add to this thread after all. The message I sent
yesterday did not end up in my inbox, so I can't even respond to
myself.

Here's what I said:
-------------
attached below
-------------

This would be my reply:

Funny thing happened to me today.

When I opened Mozilla I saw it was using the SuSE Free Serif again! I
don't know how that happened. It was using the Microsoft TNR. When I
go into Edit/Preferences I get a bewildering array of font selections,
and no positive feedback, so I couldn't get the TNR back.

Not to worry: it's still there, I can select it in Open Office.

But I decided to try out the character map program again, this time
with the SuSE font, and yes, it too supports polytonic Greek.

In fact, the curior monospace also does polygreek.

Unusual, the ones that don't.

That reminds me why I couldn't use the SuSE free serif: it's too fat.
I mean it takes up too much space, so I couldn't fit my dictionary
pages on the PDF I created in Open Office.

Did you know why Adobe calls it "Portable Document Format"?

It's because the PDF actually contains a subset of the font used to
create the document. The mini-font travels around the world with the
document, so your recipient sees exactly what you send, even if he
doesn't have the special font.

Speaking of exotic fonts, I like your Greek fonts, they look great.
But I don't understand why you call them "Greek" fonts, or why some
people call them "Unicode" fonts, for that matter.

Any font is a Greek font if it renders the Greek characters, and any
font should be usable with any characer set, as long as that internal
glyph index maps the character set to the glyphs.

So, do you think you can combine the mono and polytonic Greek
alphabets into a single character keymap?

Joe

PS

Here's what I said:
----------------
Hello.

I've been experimenting with polygreek too, but I hesitate to add to
your already established thread...

I took the Times New Roman ttf of a Windows XP system and installed it
on my SuSE 9.2 at home. To my surprise, I see this font supports
polygreek, so I tried setting a couple entries from a popular
dictionary of modern Greek:

http://modern-greek-verbs.tripod.com/home.html#unicode

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.

I'm using the character map program to capture the data. I know the
Times font is working, because if I select another font, like the SuSE
free fonts, or even the Microsoft Arial, which I also ripped off, the
polygreek characters are not rendered.

I was wondering, since the font worked so unexpectedly well, maybe the
monogreek keymap would too.

But how would I know?

I gather from your correspondence that no polygreek keymap is
currently available, but I'm hoping the monogreek map might already do
something reasonable with poly greek.

True, the monogreek tonos is not the same as the polygreek accents,
but it should be possible to combine the two alphabets in a single
keymap, just like their part of the same font.

This would spare me tha agony of changing keymaps using the
what-ever-you-call-it, the xkb "accelerator" key. (Going from Greek to
English is already a pain in the ass.)

Would it be possible to extend the monogreek keymap to do polygreek?

You'd have one less module to distribute, and one less thing to install.

Getting back to the font:

The Linux Mozilla displays this document properly on my system at
home, but when I go to a MS system at the University, and use Internet
Explorer, the polygreek and some, but not all, of the special
characters are rendered by little boxes.

The Firefox on the XP system is a little better, all the glyphs
display, but not very nicely, at least not as nice as the Linux
Mozilla, which is perfect. There seems to be some kind of glyph
substitution going on.

I assume the font contains a table which maps the integer-valued
unicode character (which comes from the utf-8 byte stream) to a glyph
index inside the font. This table must be created somehow when the
font is designed, so I can't get at it, but I was wondering why the
same font, Microsoft Times New Roman, would behave differently in
different application programs, even if they are running on different
platforms.

Any guesses?

Thanks.

Joe

PS

I was very happy with the Font installation program which is part of
the KDE desktop. You just open the font directory with Konqueror and
click the "Install" button. Congratulations to whoever did it.

(Only I could not figure out how to install the fonts on Gnome. It's
probably just a matter of copying the font files to the right
directory, but which one?)

I assume X windows has its own font api, so Microsoft ttfs should not
work right out of the box on an X system. Maybe that's the job of the
"font server", to convert one interface to another. I have no idea
where it is running, as a separate process, as a module linked to the
X server, nor do I care... But, my compliments to that guy too, who
ever he was.
-------------

Post by Simos Xenitellis

Post by Jan Willem Stumpel

As far as I know there is no national standard for Greek polytonic.
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?

Post by Jan Willem Stumpel
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?

Post by Jan Willem Stumpel

Post by Simos Xenitellis
The "Compose" file should be broken in smaller files per script
rather than having a big monolithic file.

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.

Post by Jan Willem Stumpel

Post by Simos Xenitellis
There is increasing interest in updating this area of Xorg
(http://community.livejournal.com/xkbconfig/) and I hope it gets done
soon.

Jan Willem Stumpel

2006-02-03 14:39:48 UTC

Permalink

[..]
With this font, I can capture the entire entry, no problems, pointi=

fingers, arrows, boxes, tiny-elvises, polygreek etymology... There =

virtually nothing I cannot do with the Unicode character set alone.
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 men=
us).

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 th=
e
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. wh=
en
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 peop=
le
could very well be resident in Greece, so they need to enter both
'ancient' and 'modern' Greek in their computers with a minimum of fus=
s.
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 mode=
rn
Greek, and another one which enables inputting BOTH ancient and
modern Greek (i.e both tonos and ox=C3=ADa) - although it might be
somewhat sub-optimal compared to a keyboard which is 'modern Greek
only'.

BTW What is a 'tiny elvis'?

Regards, Jan

Joe Schaffner

2006-04-12 18:12:38 UTC

Permalink

Hi All,

I'm getting closer... closer to the motherload, to hitting paydirt.
I've been trying to follow your discussion on the gr(polytonic) key
map, but I need some more background...

I could set my key map to gr(polytonic) as you suggested in your mail,
using the 'setxkbmap' as you described, but the keyboard did nothing
useful. Maybe the configuration files are obsolete.

I am using SuSE 9.2 and Gnome.

My .profile:

export LANG=el_GR.UTF-8
setxkbmap "us,el" -option "grp:alt_shift_toggle"

I need to use the polytonic Greek characters. I am translating a
Lexicon of Ancient Greek Verb:

http://modern-greek-verbs.tripod.com/sarris/

Do I even need a special map for polytonic Greek (e.g. "gr") i.e. Can
I get to the poly Greek characters through the mono Greek map?

What is a <Multi_key>?

Maybe I could use it on the mono Greek keymap.

That would be the best for me, because I do not like changing keymaps.
I can't tell you the number of times I forgotten to switch between
Greek and English, only to find I've been typing an English text in
Greek!

The same thing is even more likely between Greek and Greek.

In the meantime, I'm going to write a little script in perl which will
read my html and substitute my own "key codes" to the poly greek
unicode. For example, I can capture the Greek vowels like this:

)/α would be a greek alpha with psili and oxia,
~ω would be a greek omega with perispomeni

I can copy/paste the unicode characters from the .Compose file
(attached) into my perl script.

This would esentially move the system-layer, xkb keycode mapping
process to the application domain, which I can manage.

Still, the keymap configuration should be as simple as Perl, no?

But where do I get started?

Joe
http://modern-greek-verbs.tripod.com/

PS
What is a tiny elvis?

He's a wee-tiny Elvis that can live on your dashboard. Sometimes his
fully grown body guards will let him steer the car. "Hey, tiny Elvis,
would you buy me a Cadillac?"

This is from my system:

/usr/lib/X11/locale/el_GR.UTF-8/Compose

# Part 2
#
# Greek Extended multi-key and dead key definitions. These have been
# machine-generated by a perl script, found at:
# http://hal.csd.auth.gr/~vvas/i18n/xkb/polytonic-compose.pl

<Multi_key> <greater> <Greek_alpha> : "ἀ" U1f00
<dead_horn> <Greek_alpha> : "ἀ" U1f00
<Multi_key> <less> <Greek_alpha> : "ἁ" U1f01
<dead_ogonek> <Greek_alpha> : "ἁ" U1f01
<Multi_key> <greater> <grave> <Greek_alpha> : "ἂ" U1f02
<Multi_key> <grave> <greater> <Greek_alpha> : "ἂ" U1f02
<dead_horn> <dead_grave> <Greek_alpha> : "ἂ" U1f02
<dead_grave> <dead_horn> <Greek_alpha> : "ἂ" U1f02
<Multi_key> <less> <grave> <Greek_alpha> : "ἃ" U1f03
<Multi_key> <grave> <less> <Greek_alpha> : "ἃ" U1f03
<dead_ogonek> <dead_grave> <Greek_alpha> : "ἃ" U1f03
<dead_grave> <dead_ogonek> <Greek_alpha> : "ἃ" U1f03
<Multi_key> <greater> <apostrophe> <Greek_alpha> : "ἄ" U1f04
...
<Multi_key> <apostrophe> <less> <bar> <Greek_alpha> : "ᾅ" U1f85
<dead_iota> <dead_ogonek> <dead_acute> <Greek_alpha> : "ᾅ" U1f85
<dead_iota> <dead_acute> <dead_ogonek> <Greek_alpha> : "ᾅ" U1f85
<dead_ogonek> <dead_iota> <dead_acute> <Greek_alpha> : "ᾅ" U1f85
<dead_ogonek> <dead_acute> <dead_iota> <Greek_alpha> : "ᾅ" U1f85
<dead_acute> <dead_iota> <dead_ogonek> <Greek_alpha> : "ᾅ" U1f85
<dead_acute> <dead_ogonek> <dead_iota> <Greek_alpha> : "ᾅ" U1f85
<Multi_key> <bar> <greater> <asciitilde> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <bar> <asciitilde> <greater> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <greater> <bar> <asciitilde> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <greater> <asciitilde> <bar> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <asciitilde> <bar> <greater> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <asciitilde> <greater> <bar> <Greek_alpha> : "ᾆ" U1f86
<dead_iota> <dead_horn> <dead_tilde> <Greek_alpha> : "ᾆ" U1f86
<dead_iota> <dead_tilde> <dead_horn> <Greek_alpha> : "ᾆ" U1f86
<dead_horn> <dead_iota> <dead_tilde> <Greek_alpha> : "ᾆ" U1f86

It looks like all the characters are there, only how do I get them?

What are these symbols, <Multi_key>, <greater>, <apostrophe>,
<Greek_alpha>, etc. and how are they mapped to real keys?

Anybody care to discuss how xkb works?

Anybody care to describe the multitude of configuration files used by
the locale/Xkb system?

It looks like all these X/locale configuration files are text files.
They all seem to work together.

Where do I get started?

===============================================
Unicode Fonts

I'd like to correct something I wrote earlier. Microsoft TNR does
*NOT* support the polytonic Greek characters. I only thought so
because 1) the SuSE Free Serif does, and 2) the gnome "Character
Table" application does a clever font substitution even when I select
M-TNR as the font.

Too clever for its own good.

Font substitution good in a browser, but it is a very bad idea in a
system utility like this "Character Table" (sorry I have a Greek
desktop, and I don't know what you call it in English). If the
characters are not present in the font being considered, then there I
want to know about it!

In fact Mozilla and Firefox work quite well, even on Windows, but IE
6.0 does nothing at all! In fact, the only poly Greek font on my Xp
system is the "arial unicode ms" which, 1) is sans serif and 2) is a
pig (22M byte), even though there are other fonts on the Xp which call
themselves "unicode". IE doesn not use it though, not even for font
substitution.

Which brings up the question:

The font is a set of glyphs and has nothing to do whatsoever with the
character set, so why are we calling them "unicode" fonts anyway?

I assume a font can work with any character set, ISO-8859-7, Unicode,
WinGreek, "My First Character set", "Foobar"... any.

Any font designers out there?

There needs to be a map between the character set and the glyph-set
(the font) which I always assumed was in the font itself, because only
the font know which glyphs it has implemented.
=================================================

Post by Joe Schaffner
[..]
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.
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
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/li

Joe Schaffner

2006-04-13 19:16:37 UTC

Permalink

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.

In the meantime:

1) I wonder if Yudit has a built in map for polytonic Greek. It has a
monotonic map, which only works in Yudit, but thank God for Yudit,
because xkb is pretty tough to deal with right out of the box. With
Yudit you do not need xkb [but if you've managed to configure the Grk
keymap, Yudit will goof up. It need the straight, vanilla flavored
keyboard].

2) Borrowing a trick from a macro add on to Microsoft Word back in
Windows 98 -- which had no polytonic Greek either -- I've gotten used
to using the "special" characters on normal keyboard to enter poly
Greek.

)/α is a greek alpha with psili and oxia,
~ω is a greek omega with perispomeni
)~|η is a greek eta with psili, perispomeni and ypogegrammeni or in
latin, soft breathing, circumflex and iota subscript
\ε is a greek epsilon with varia (i.e. grave) accent.

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:

http://modern-greek-verbs.tripod.com/sarris/poly.pl

I tested it on this page:

http://modern-greek-verbs.tripod.com/sarris/lexicon.html

(I would have posted the resulting page, but I won't be able to upload
it until tomorrow. technical problems at the University)

Just capture your document using the mono Greek keymap, but don't use
the tonos, just the unaccented vowels, marked up with my "dead key"
characters, then run the script over the file:

$ ./poly.gr < lexicon.html > tmp.html

The temporary file has all the lower case polytonic Greek vowels. I
haven't noticed any conflicts with normal punctuation (yet). I don't
need the uppercase for my lexicon.

This is ideal for me because I can capture both mono and poly greek
using just the mono Greek map.

Joe
http://modern-greek-verbs.tripod.com/

Post by Joe Schaffner
Hi All,
I'm getting closer... closer to the motherload, to hitting paydirt.
I've been trying to follow your discussion on the gr(polytonic) key
map, but I need some more background...
I could set my key map to gr(polytonic) as you suggested in your mail,
using the 'setxkbmap' as you described, but the keyboard did nothing
useful. Maybe the configuration files are obsolete.
I am using SuSE 9.2 and Gnome.
export LANG=el_GR.UTF-8
setxkbmap "us,el" -option "grp:alt_shift_toggle"
I need to use the polytonic Greek characters. I am translating a
http://modern-greek-verbs.tripod.com/sarris/
Do I even need a special map for polytonic Greek (e.g. "gr") i.e. Can
I get to the poly Greek characters through the mono Greek map?
What is a <Multi_key>?
Maybe I could use it on the mono Greek keymap.
That would be the best for me, because I do not like changing keymaps.
I can't tell you the number of times I forgotten to switch between
Greek and English, only to find I've been typing an English text in
Greek!
The same thing is even more likely between Greek and Greek.
In the meantime, I'm going to write a little script in perl which will
read my html and substitute my own "key codes" to the poly greek
)/α would be a greek alpha with psili and oxia,
~ω would be a greek omega with perispomeni
I can copy/paste the unicode characters from the .Compose file
(attached) into my perl script.
This would esentially move the system-layer, xkb keycode mapping
process to the application domain, which I can manage.
Still, the keymap configuration should be as simple as Perl, no?
But where do I get started?
Joe
http://modern-greek-verbs.tripod.com/
PS
What is a tiny elvis?
He's a wee-tiny Elvis that can live on your dashboard. Sometimes his
fully grown body guards will let him steer the car. "Hey, tiny Elvis,
would you buy me a Cadillac?"
/usr/lib/X11/locale/el_GR.UTF-8/Compose
# Part 2
#
# Greek Extended multi-key and dead key definitions. These have been
# http://hal.csd.auth.gr/~vvas/i18n/xkb/polytonic-compose.pl
<Multi_key> <greater> <Greek_alpha> : "ἀ" U1f00
<dead_horn> <Greek_alpha> : "ἀ" U1f00
<Multi_key> <less> <Greek_alpha> : "ἁ" U1f01
<dead_ogonek> <Greek_alpha> : "ἁ" U1f01
<Multi_key> <greater> <grave> <Greek_alpha> : "ἂ" U1f02
<Multi_key> <grave> <greater> <Greek_alpha> : "ἂ" U1f02
<dead_horn> <dead_grave> <Greek_alpha> : "ἂ" U1f02
<dead_grave> <dead_horn> <Greek_alpha> : "ἂ" U1f02
<Multi_key> <less> <grave> <Greek_alpha> : "ἃ" U1f03
<Multi_key> <grave> <less> <Greek_alpha> : "ἃ" U1f03
<dead_ogonek> <dead_grave> <Greek_alpha> : "ἃ" U1f03
<dead_grave> <dead_ogonek> <Greek_alpha> : "ἃ" U1f03
<Multi_key> <greater> <apostrophe> <Greek_alpha> : "ἄ" U1f04
...
<Multi_key> <apostrophe> <less> <bar> <Greek_alpha> : "ᾅ" U1f85
<dead_iota> <dead_ogonek> <dead_acute> <Greek_alpha> : "ᾅ" U1f85
<dead_iota> <dead_acute> <dead_ogonek> <Greek_alpha> : "ᾅ" U1f85
<dead_ogonek> <dead_iota> <dead_acute> <Greek_alpha> : "ᾅ" U1f85
<dead_ogonek> <dead_acute> <dead_iota> <Greek_alpha> : "ᾅ" U1f85
<dead_acute> <dead_iota> <dead_ogonek> <Greek_alpha> : "ᾅ" U1f85
<dead_acute> <dead_ogonek> <dead_iota> <Greek_alpha> : "ᾅ" U1f85
<Multi_key> <bar> <greater> <asciitilde> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <bar> <asciitilde> <greater> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <greater> <bar> <asciitilde> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <greater> <asciitilde> <bar> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <asciitilde> <bar> <greater> <Greek_alpha> : "ᾆ" U1f86
<Multi_key> <asciitilde> <greater> <bar> <Greek_alpha> : "ᾆ" U1f86
<dead_iota> <dead_horn> <dead_tilde> <Greek_alpha> : "ᾆ" U1f86
<dead_iota> <dead_tilde> <dead_horn> <Greek_alpha> : "ᾆ" U1f86
<dead_horn> <dead_iota> <dead_tilde> <Greek_alpha> : "ᾆ" U1f86
It looks like all the characters are there, only how do I get them?
What are these symbols, <Multi_key>, <greater>, <apostrophe>,
<Greek_alpha>, etc. and how are they mapped to real keys?
Anybody care to discuss how xkb works?
Anybody care to describe the multitude of configuration files used by
the locale/Xkb system?
It looks like all these X/locale configuration files are text files.
They all seem to work together.
Where do I get started?
===============================================
Unicode Fonts
I'd like to correct something I wrote earlier. Microsoft TNR does
*NOT* support the polytonic Greek characters. I only thought so
because 1) the SuSE Free Serif does, and 2) the gnome "Character
Table" application does a clever font substitution even when I select
M-TNR as the font.
Too clever for its own good.
Font substitution good in a browser, but it is a very bad idea in a
system utility like this "Character Table" (sorry I have a Greek
desktop, and I don't know what you call it in English). If the
characters are not present in the font being considered, then there I
want to know about it!
In fact Mozilla and Firefox work quite well, even on Windows, but IE
6.0 does nothing at all! In fact, the only poly Greek font on my Xp
system is the "arial unicode ms" which, 1) is sans serif and 2) is a
pig (22M byte), even though there are other fonts on the Xp which call
themselves "unicode". IE doesn not use it though, not even for font
substitution.
The font is a set of glyphs and has nothing to do whatsoever with the
character set, so why are we calling them "unicode" fonts anyway?
I assume a font can work with any character set, ISO-8859-7, Unicode,
WinGreek, "My First Character set", "Foobar"... any.
Any font designers out there?
There needs to be a map between the character set and the glyph-set
(the font) which I always assumed was in the font itself, because only
the font know which glyphs it has implemented.
=================================================

Jan Willem Stumpel

2006-04-14 15:06:51 UTC

Permalink

Post by Joe Schaffner
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 =CE=B1 =E1=BE=B6 (perisp=
omeni)
shift<AD11> { { dead_diaeresis =CF=85 (=3Dy) =CF=8B (dialyti=
ka)
altgr<AD12> =C2=AB dead_macron =CE=B1 =E1=BE=B1 (m=
acron)

<AD12> ] ] dead_iota =CE=B1 =E1=BE=B3 (iota s=
ubscript)
shift<AD12> } } VoidSymbol =CE=B1 =CE=B1 (does noth=
ing)
altgr<AD12> =C2=BB dead_breve =CE=B1 =E1=BE=B0 (b=
reve)

<AC10> ; =C2=B4 dead_acute =CE=B1 =CE=AC (tono=
s/oxia)
shift<AC10> : =C2=A8 dead_horn =CE=B1 =E1=BC=80 (p=
sili)
altgr<AC10> =CE=85 [not defined] =CE=B1 =CE=B1 (does=
nothing)

<AC11> ' ' dead_grave =CE=B1 =E1=BD=B0 (varia)
shift<AC11> " " dead_ogonek =CE=B1 =E1=BC=81 (dasia)
altgr<AC11> [not defined] =CE=B1 =CE=B1 (does noth=
ing)

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 =E1=BE=84, are also possible; you have to use a fi=
xed
order:

-- iota subscript first
-- accent second
-- breathing third

So for =E1=BE=A7 you woud enter the keystroke sequence (keys as marke=
d 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 =CE=84 Dead key (;) + vowel
dialytika =C2=A8 Dead key (:) + vowel (only =CF=85, =CE=B9)
perispomeni =E1=BF=80 Dead key ([) + vowel
iota subscript =CD=BA Dead key ({) + vowel
psili =E1=BE=BF Dead key (') + vowel/=CF=81
dasia =E1=BF=BE Dead key (") + vowel/=CF=81
varia =E1=BF=AF Dead key (/) + vowel
macron =C2=AF Dead key (]) + vowel
breve =CB=98 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] =3D "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
=66rom 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 =CE=BC$ has patented this.

Post by Joe Schaffner
[..] 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

Joe Schaffner

2006-04-14 18:24:02 UTC

Permalink

Thanks Jan,

Your message gave me some encouragement. I'll try starting the
gr(polytonic) map again tomorrow, and experiment with the dead keys,
but I don't have much time to lose. It took me 2 or 3 hours to do the
perl script, and I have lost days experimenting with system software.

The problem I have with system software is that it usually makes a
fool out of me, and I don't find the xkb intuitive at all. By
intuitive, I mean it reads my mind and does what I want.

I found the mono Greek map quite intuitive, but I believe I saw a
program somewhere which had a Gui keyboard with all the keys marked. I
was wondering, is there anyway to see the poly greek keyboard on my
system?

Post by Jan Willem Stumpel
Ceterum censeo /usr/lib/X11/locale/el_GR.UTF-8/Compose esse delendam.

I was happy to find it, because it listed all the poly greek
characters, but I was a bit surprised to find it in a 'locale'
directory, well, in an X11/locale directory. I'd eventually like to
sort out the locale and the keymap stuff, because at first glance, I
don't know what one has to do with the other.

Joe
http://modern-greek-verbs.tripod.com/

PS

I found a key conflict with my program. Sometimes I need to enclose
greek text inside parentheses, like this:

(εἶμεν)

[damn, these windows fonts suck]

In this case I don't want dasia epsilon and I don't want a space
between the LP and the epsilon, so I encoded the text like this

(<m>e)~ιμεν)

The <m> is an undefined tag which the browser conveniently throws
away, respecting the spacing, like a <b> or an <i>.

I realize my program only works on text files. It won't help entering
poly Greek into OO, but I do all my work in gedit.

=======================

Post by Jan Willem Stumpel

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
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
-- 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
http://planet.hellug.gr/misc/polytonic/
This document has some keyboard combination tables of which a
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
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.

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

Joe Schaffner

2006-05-09 18:04:52 UTC

Permalink

After lengthy consideration, I have come to the conclusion xkb has
nothing to do with character mapping.

It only maps keyboard events to keysyms, which are not characters i.e.
it creates the (integer-valued, I assume) names of the key
combinations, and 2) it allows you to "group" the keysyms into
language-specific quasi-keyboards.

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

Here is an excerpt from the latter:

partial alphanumeric_keys alternate_group
xkb_symbols "polytonic" {

include "el(extended)"

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.

<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>?

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.

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?).

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?

Joe
http://modern-greek-verbs.tripod.com/sarris/

PS

The character mapping seems to take place in the per-locale Compose
file (ergo non potest delendum esse). That would make sense, because
you'd need a separate character mapping for each character set. One
group corresponds to many Compose files. The one I seem to be using
is:

/usr/X11R6/lib/X11/locale/el_GR.UTF-8/Compose

Here are some character mappings:

<Multi_key> <greater> <Greek_alpha> : "αΌ€" U1f00
<dead_horn> <Greek_alpha> : "αΌ€" U1f00
<Multi_key> <less> <Greek_alpha> : "αΌ" U1f01
<dead_ogonek> <Greek_alpha> : "αΌ" U1f01
<Multi_key> <greater> <grave> <Greek_alpha> : "αΌ‚" U1f02
<Multi_key> <grave> <greater> <Greek_alpha> : "αΌ‚" U1f02
<dead_horn> <dead_grave> <Greek_alpha> : "αΌ‚" U1f02
<dead_grave> <dead_horn> <Greek_alpha> : "αΌ‚" U1f02
<Multi_key> <less> <grave> <Greek_alpha> : "αΌƒ" U1f03
<Multi_key> <grave> <less> <Greek_alpha> : "αΌƒ" U1f03
<dead_ogonek> <dead_grave> <Greek_alpha> : "αΌƒ" U1f03
<dead_grave> <dead_ogonek> <Greek_alpha> : "αΌƒ" U1f03
<Multi_key> <greater> <apostrophe> <Greek_alpha> : "αΌ„" U1f04
<Multi_key> <apostrophe> <greater> <Greek_alpha> : "αΌ„" U1f04
<dead_horn> <dead_acute> <Greek_alpha> : "αΌ„" U1f04
<dead_acute> <dead_horn> <Greek_alpha> : "αΌ„" U1f04
<Multi_key> <less> <apostrophe> <Greek_alpha> : "αΌ…" U1f05
<Multi_key> <apostrophe> <less> <Greek_alpha> : "αΌ…" U1f05

<Multi_key> is a diversionary tactic. I guess it would let me use the
polytonic characters while in monotonic mode. I wouldn't have to
change groups. (I tried it, but it didn't work. However, I could use
all the French characters while in USA mode)

I can see that the <dead_horn> is intended to function as psili and
the <dead_ogonek> as the dasia.

Are the names of the keysyms important?

If not, why not call them <dead_psili> and <dead_dasia>?

Question: The greek-locale Compose file contains character mappings
for all the composed characters.

Where are the mappings for the simple, non-composed greek characters?

It would be nice to see the entire character map in the same place.
====================================

Post by Joe Schaffner
Thanks Jan,
Your message gave me some encouragement. I'll try starting the
gr(polytonic) map again tomorrow, and experiment with the dead keys,
but I don't have much time to lose. It took me 2 or 3 hours to do the
perl script, and I have lost days experimenting with system software.
The problem I have with system software is that it usually makes a
fool out of me, and I don't find the xkb intuitive at all. By
intuitive, I mean it reads my mind and does what I want.
I found the mono Greek map quite intuitive, but I believe I saw a
program somewhere which had a Gui keyboard with all the keys marked. I
was wondering, is there anyway to see the poly greek keyboard on my
system?

Post by Jan Willem Stumpel
Ceterum censeo /usr/lib/X11/locale/el_GR.UTF-8/Compose esse delendam.

I was happy to find it, because it listed all the poly greek
characters, but I was a bit surprised to find it in a 'locale'
directory, well, in an X11/locale directory. I'd eventually like to
sort out the locale and the keymap stuff, because at first glance, I
don't know what one has to do with the other.
Joe
http://modern-greek-verbs.tripod.com/
PS
I found a key conflict with my program. Sometimes I need to enclose
(εἶμεν)
[damn, these windows fonts suck]
In this case I don't want dasia epsilon and I don't want a space
between the LP and the epsilon, so I encoded the text like this
(<m>e)~ιμεν)
The <m> is an undefined tag which the browser conveniently throws
away, respecting the spacing, like a <b> or an <i>.
I realize my program only works on text files. It won't help entering
poly Greek into OO, but I do all my work in gedit.
=======================

Post by Jan Willem Stumpel

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
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
-- 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
http://planet.hellug.gr/misc/polytonic/
This document has some keyboard combination tables of which a
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
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.

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.n

Vasilis Vasaitis

2006-05-09 23:00:31 UTC

Permalink

Since I'm still cc'ed here...

On Tue, May 09, 2006 at 09:04:52PM +0300, Joe Schaffner wrote:

..[snip]..

Post by Joe Schaffner
<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.

Post by Joe Schaffner
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

Post by Joe Schaffner
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.

Post by Joe Schaffner
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

2006-05-10 07:47:25 UTC

Permalink

Post by Vasilis Vasaitis
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

2006-05-10 11:02:34 UTC

Permalink

Post by Joe Schaffner
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.

Post by Joe Schaffner
/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?

Post by Joe Schaffner
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.

Post by Joe Schaffner
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.

Post by Joe Schaffner
<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.

Post by Joe Schaffner
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).

Post by Joe Schaffner
[..] 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.

Post by Joe Schaffner
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.

Post by Joe Schaffner
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

2006-05-10 13:21:32 UTC

Permalink

Post by Jan Willem Stumpel

Post by Joe Schaffner
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.

Post by Joe Schaffner
/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?

Post by Joe Schaffner
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.

Now the official is "gr". "el" is an alias to "gr", to let old
configurations continue to work.
This is in Xorg 7.0+ and xkeyboard-config, in earlier Xorg your mileage
may vary.

Post by Jan Willem Stumpel

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.

The Uxxxx notation for Unicode characters in the Compose file should be
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.

Post by Jan Willem Stumpel
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.

Post by Jan Willem Stumpel

Post by Joe Schaffner
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).

Post by Joe Schaffner
[..] 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.

Post by Joe Schaffner
None of the other dead keys seem to work.
Any ideas?

Post by Joe Schaffner
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.

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

Simos

Joe Schaffner

2006-05-10 19:21:24 UTC

Permalink

Thanks to Everyone for your help.

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/

Post by Jan Willem Stumpel

Post by Joe Schaffner
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.

Post by Joe Schaffner
/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?

Post by Joe Schaffner
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.

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.

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.

Post by Joe Schaffner
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).

Post by Joe Schaffner
[..] 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.

Post by Joe Schaffner
None of the other dead keys seem to work.
Any ideas?

Post by Joe Schaffner
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
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/

Danilo Segan

2006-05-10 19:29:25 UTC

Permalink

Hi Jan,

Post by Jan Willem Stumpel

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?)

Post by Jan Willem Stumpel
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". :)

Post by Jan Willem Stumpel
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

Simos Xenitellis

2006-01-18 14:40:19 UTC

Permalink

Post by Alexandros Diamantidis
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).
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
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