Re: Experiments with classical Greek keyboard input
Today at 1:00, Vasilis Vasaitis wrote: 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 -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Joe Schaffner wrote:
After lengthy consideration, I have come to the conclusion xkb
[..] only maps keyboard events to keysyms, which are not
characters
Many of them really are just characters.
I have these two keymaps i.e. groups on my system:
/etc/X11/xkb/symbols/el -- The one I'm using
/etc/X11/xkb/symbols/gr -- The dirty bastard
Isn't this dirty bastard /etc/X11/xkb/symbols/pc/gr? Which version
of X do you have?
include el(extended)
This shows that you are really using both, because gr includes el.
BTW in newer versions of X there is no el, only the dirty bastard.
key.type = THREE_LEVEL;
key AD11 {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
key AD12 {[], [ dead_iota, VoidSymbol, dead_breve ]};
key AC10 {[], [ dead_acute, dead_horn ]};
key AC11 {[], [ dead_grave, dead_ogonek ]};
};
I assume the list of keysyms captures the shifted state of the
key i.e. dead_acute is on the semi-colon key and dead_horn
is on the same key, shifted, the colon key.
Yes, and in the case of three-level keys, the third level is
accessed by the AltGr key (right-alt, most probably). So that's
how you get the dead macron etc.
Some keys might be four-level, in which case the fourth level is
accessed by means of Shift-AltGr.
dead_grave is on the single-quote key and dead_ogonek is on
the double-quote key.
That's a pretty good layout. I like it.
Why not name these keysyms dead_psili and dead_dasia?
Because these names are not known to the system. However, all
UTF-8 characters are known to the system by default, having
names beginning with U. So the designer of this layout could, and
in my opinion should, have called them U0313 (for the dead psili)
and U0314 (for the dead dasia).
This would have avoided the need for a special Greek Compose file,
the existence of which is just a bother, ergo censeo delendam
esse. There already exists an international Compose file (it is
called the US file but it is really international), which serves
all languages, including ancient and modern Greek, and which knows
how to combine U0313 and U0314 with Greek letters and with other
accents.
Anyway, I activate the gr keymap like this:
setxkbmap us,gr(polytonic) -option grp:alt_shift_toggle
The command syntax is troublesome. There seem to be other ways
of doing it. Maybe I'm wrong, but it seems to work.
You can put the keyboard options in the X configuration file
(/etc/X11/xorg.conf, or /etc/X11/XF86Config-4).
[..] Yes, I can enter greek characters. The dead_acute seems to
work, but I am not sure if it is outputting a tonos or a acute.
It's probably a tonos.
It should be, because having a separate acute is not considered
correct anymore. The fonts you use should display the tonos as an
acute. But if you really want to have the separate acute (oxia),
there are ways.
None of the other dead keys seem to work.
Any ideas?
All the dead keys can be made to work. It is not magic; it is not
even difficult. I apologise for blowing my own horn, but perhaps
you really should read the bits relating to keyboard and Greek
on http://www.jw-stumpel.nl/stestu.html.
It would be nice to see the entire character map in the same
place.
To get a picture of your character map (or maps, if you have
defined multiple maps) you could try
xkbcomp -xkm $DISPLAY
xkbprint server-0_0.xkm server-0_0.eps
The resulting file, server-0_0.eps, can be viewed with gv. This
xkbprint system seems a little bit flaky, though. You may have
difficulty actually printing the map.
Regards, Jan
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
O/H Jan Willem Stumpel έγραψε:
Joe Schaffner wrote:
After lengthy consideration, I have come to the conclusion xkb
[..] only maps keyboard events to keysyms, which are not
characters
Many of them really are just characters.
I have these two keymaps i.e. groups on my system:
/etc/X11/xkb/symbols/el -- The one I'm using
/etc/X11/xkb/symbols/gr -- The dirty bastard
Isn't this dirty bastard /etc/X11/xkb/symbols/pc/gr? Which version
of X do you have?
include el(extended)
This shows that you are really using both, because gr includes el.
BTW in newer versions of X there is no el, only the dirty bastard.
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.
key.type = THREE_LEVEL;
key AD11 {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
key AD12 {[], [ dead_iota, VoidSymbol, dead_breve ]};
key AC10 {[], [ dead_acute, dead_horn ]};
key AC11 {[], [ dead_grave, dead_ogonek ]};
};
I assume the list of keysyms captures the shifted state of the
key i.e. dead_acute is on the semi-colon key and dead_horn
is on the same key, shifted, the colon key.
Yes, and in the case of three-level keys, the third level is
accessed by the AltGr key (right-alt, most probably). So that's
how you get the dead macron etc.
Some keys might be four-level, in which case the fourth level is
accessed by means of Shift-AltGr.
dead_grave is on the single-quote key and dead_ogonek is on
the double-quote key.
That's a pretty good layout. I like it.
Why not name these keysyms dead_psili and dead_dasia?
Because these names are not known to the system. However, all
UTF-8 characters are known to the system by default, having
names beginning with U. So the designer of this layout could, and
in my opinion should, have called them U0313 (for the dead psili)
and U0314 (for the dead dasia).
The U notation for Unicode characters in the Compose file should be
edited so that any numbers have 0x1000 added to them.
For more on this and the chance to try out such an updated Compose file, see
https://bugs.freedesktop.org/show_bug.cgi?id=5129
I did not manage to try the file myself as I run Breezy (Oldish Xorg 6.8.2).
In Xorg 6.8.2 on Breezy I have an issue of typing psili, daseia and
several other combinations based on these. I think this relates to the
merging of the greek compose file
to the common international one.
See
https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/21637
for more.
If someone has Xorg 7.0 and want to try out, please do and report back.
This would have avoided the need for a special Greek Compose file,
the existence of which is just a bother, ergo censeo delendam
esse. There already exists an international Compose file (it is
called the US file but it is really international), which serves
all languages, including ancient and modern Greek, and which knows
how to combine U0313 and U0314 with Greek letters and with other
accents.
I second that.
Anyway, I activate the gr keymap like this:
setxkbmap us,gr(polytonic) -option grp:alt_shift_toggle
The command syntax is troublesome. There seem to be other ways
of doing it. Maybe I'm wrong, but it seems to work.
You can put the keyboard options in the X configuration file
(/etc/X11/xorg.conf, or /etc/X11/XF86Config-4).
[..] Yes, I can enter greek characters. The dead_acute seems to
work, but I am not sure if it is outputting a tonos or a acute.
It's probably a tonos.
It should be, because having a separate acute is not considered
correct anymore. The fonts you use should display the tonos as an
acute. But if you really want to have the separate acute (oxia),
there are ways.
None of the other dead keys seem to work.
Any ideas?
All the dead keys can be made to work. It is not magic; it is not
even difficult. I apologise for blowing my own horn, but perhaps
you really should read the bits relating to keyboard and Greek
on http://www.jw-stumpel.nl/stestu.html.
It would be nice to see the entire character map in the same
place.
To get a picture of your character map (or maps, if you have
defined multiple maps) you could try
xkbcomp -xkm $DISPLAY
xkbprint server-0_0.xkm server-0_0.eps
The resulting file, server-0_0.eps, can be viewed with gv. This
xkbprint system seems a little bit flaky, though. You may have
difficulty actually printing the map.
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
Re: Experiments with classical Greek keyboard input
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 GREAT!
You know, I have Fedora on another partition. Maybe I'll give that a
try... Oh yeah, I did. It didn't work either, and the configuration
files were virtually identical.
Let's drink a toast... to the next version!
Cheers!
Joe
http://modern-greek-verbs.tripod.com/sarris/
On 5/10/06, Jan Willem Stumpel [EMAIL PROTECTED] wrote:
Joe Schaffner wrote:
After lengthy consideration, I have come to the conclusion xkb
[..] only maps keyboard events to keysyms, which are not
characters
Many of them really are just characters.
I have these two keymaps i.e. groups on my system:
/etc/X11/xkb/symbols/el -- The one I'm using
/etc/X11/xkb/symbols/gr -- The dirty bastard
Isn't this dirty bastard /etc/X11/xkb/symbols/pc/gr? Which version
of X do you have?
include el(extended)
This shows that you are really using both, because gr includes el.
BTW in newer versions of X there is no el, only the dirty bastard.
key.type = THREE_LEVEL;
key AD11 {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
key AD12 {[], [ dead_iota, VoidSymbol, dead_breve ]};
key AC10 {[], [ dead_acute, dead_horn ]};
key AC11 {[], [ dead_grave, dead_ogonek ]};
};
I assume the list of keysyms captures the shifted state of the
key i.e. dead_acute is on the semi-colon key and dead_horn
is on the same key, shifted, the colon key.
Yes, and in the case of three-level keys, the third level is
accessed by the AltGr key (right-alt, most probably). So that's
how you get the dead macron etc.
Some keys might be four-level, in which case the fourth level is
accessed by means of Shift-AltGr.
dead_grave is on the single-quote key and dead_ogonek is on
the double-quote key.
That's a pretty good layout. I like it.
Why not name these keysyms dead_psili and dead_dasia?
Because these names are not known to the system. However, all
UTF-8 characters are known to the system by default, having
names beginning with U. So the designer of this layout could, and
in my opinion should, have called them U0313 (for the dead psili)
and U0314 (for the dead dasia).
This would have avoided the need for a special Greek Compose file,
the existence of which is just a bother, ergo censeo delendam
esse. There already exists an international Compose file (it is
called the US file but it is really international), which serves
all languages, including ancient and modern Greek, and which knows
how to combine U0313 and U0314 with Greek letters and with other
accents.
Anyway, I activate the gr keymap like this:
setxkbmap us,gr(polytonic) -option grp:alt_shift_toggle
The command syntax is troublesome. There seem to be other ways
of doing it. Maybe I'm wrong, but it seems to work.
You can put the keyboard options in the X configuration file
(/etc/X11/xorg.conf, or /etc/X11/XF86Config-4).
[..] Yes, I can enter greek characters. The dead_acute seems to
work, but I am not sure if it is outputting a tonos or a acute.
It's probably a tonos.
It should be, because having a separate acute is not considered
correct anymore. The fonts you use should display the tonos as an
acute. But if you really want to have the separate acute (oxia),
there are ways.
None of the other dead keys seem to work.
Any ideas?
All the dead keys can be made to work. It is not magic; it is not
even difficult. I apologise for blowing my own horn, but perhaps
you really should read the bits relating to keyboard and Greek
on http://www.jw-stumpel.nl/stestu.html.
It would be nice to see the entire character map in the same
place.
To get a picture of your character map (or maps, if you have
defined multiple maps) you could try
xkbcomp -xkm $DISPLAY
xkbprint server-0_0.xkm server-0_0.eps
The resulting file, server-0_0.eps, can be viewed with gv. This
xkbprint system seems a little bit flaky, though. You may have
difficulty actually printing the map.
Regards, Jan
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Hi Jan,
Today at 13:02, Jan Willem Stumpel wrote:
key.type = THREE_LEVEL;
key AD11 {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
key AD12 {[], [ dead_iota, VoidSymbol, dead_breve ]};
key AC10 {[], [ dead_acute, dead_horn ]};
key AC11 {[], [ dead_grave, dead_ogonek ]};
};
I assume the list of keysyms captures the shifted state of the
key i.e. dead_acute is on the semi-colon key and dead_horn
is on the same key, shifted, the colon key.
Yes, and in the case of three-level keys, the third level is
accessed by the AltGr key (right-alt, most probably). So that's
how you get the dead macron etc.
Note that the layout listed above contains two *groups* as well,
i.e. it's not an xkeyboard-config layout (or, do we still have some of
these left?)
Some keys might be four-level, in which case the fourth level is
accessed by means of Shift-AltGr.
Not with key.type = THREE_LEVEL. :)
Because these names are not known to the system. However, all
UTF-8 characters are known to the system by default, having
names beginning with U. So the designer of this layout could, and
in my opinion should, have called them U0313 (for the dead psili)
and U0314 (for the dead dasia).
I think U-ames are available only for those Unicode characters not
having any other representation in keysymdef.h.
Cheers,
Danilo
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
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.
On 4/14/06, Joe Schaffner [EMAIL PROTECTED] wrote:
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?
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
Re: Experiments with classical Greek keyboard input
Since I'm still cc'ed here... On Tue, May 09, 2006 at 09:04:52PM +0300, Joe Schaffner wrote: ..[snip].. dead_acute is on the semi-colon key and dead_horn is on the same key, shifted, the colon key. dead_grave is on the single-quote key and dead_ogonek is on the double-quote key. That's a pretty good layout. I like it. Why not name these keysyms dead_psili and dead_dasia? Because the list of keysyms is fixed, as defined in /usr/include/X11/keysymdef.h. At the time, using arbitrary existing keysyms made more sense than petitioning for correctly-named new ones. It works, after all. But OK, now maybe it's time to ask for a few new names if people are annoyed by the current state of affairs. Anyway, I activate the gr keymap like this: setxkbmap us,gr(polytonic) -option grp:alt_shift_toggle The command syntax is troublesome. There seem to be other ways of doing it. Maybe I'm wrong, but it seems to work. The canonical invocation would be: setxkbmap -layout us,gr -variant ,polytonic \ -option grp:alt_shift_toggle Yes, the keymap is there, I can see it on the task bar. To switch to another group, I can use the alt_shift combination (another meta symbol? Where are all these symbols defined?). In /etc/X11/xkb, rules/xorg transforms grp:alt_shift_toggle to group(alt_shift_toggle). So you can look at the relevant section in symbols/group to see how this implements the layout switching. It all boils down to the generation of the ISO_Next_Group and ISO_Prev_Group keysyms. Yes, I can enter greek characters. The dead_acute seems to work, but I am not sure if it is outputting a tonos or a acute. It's probably a tonos. None of the other dead keys seem to work. Any ideas? For the others to work, you need to have at least LC_CTYPE=el_GR.UTF-8. In my system, with LANG=el_GR.UTF-8, everything is working as it should. Keep in mind that for GTK+ applications you also need GTK_IM_MODULE=xim defined (or else you have to right-click on each textbox, and select Input Methods - X Input Method). -- Vasilis Vasaitis A man is well or woe as he thinks himself so. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Joe Schaffner wrote:
Hello Thomas,
It looks like we're all looking for non-standard ways to
capture polytonic Greek in Linux. This must mean no keymap
exists. Given one hundred years I'll figure out xkb and write
one.
xkb is not so difficult to figure out. At the moment you can
already enter polytonic Greek with it, and if you set the
Greek/Latin switch to a single key (I use left-windows), entering
mixed text consisting of Greek and Latin is not difficult.
The problem is: what is, from a user point of view, the desired
behaviour of the keyboard? At the moment xkb gr(polytonic) has:
key US GR keysym with gives
AD11 [ [ dead_tilde α ᾶ (perispomeni)
shiftAD11 { { dead_diaeresis υ (=y) ϋ (dialytika)
altgrAD12 « dead_macron α ᾱ (macron)
AD12 ] ] dead_iotaα ᾳ (iota subscript)
shiftAD12 } } VoidSymbol α α (does nothing)
altgrAD12 » dead_breve α ᾰ (breve)
AC10 ; ´ dead_acute α ά (tonos/oxia)
shiftAC10 : ¨ dead_hornα ἀ (psili)
altgrAC10 ΅ [not defined]α α (does nothing)
AC11 ' ' dead_grave α ὰ (varia)
shiftAC11dead_ogonek α ἁ (dasia)
altgrAC11 [not defined]α α (does nothing)
AC and AD indicate the third and fourth keyboard row from below,
respectively. The number indicates the position of the key
counting from the left, but not counting shift, capslock, tab.
The column US shows which symbols are engraved on the physical
keys of a standard US PC 104 keyboard. The column GR shows what
is engraved on the physical keys of a Greek keyboard, according to
Wikipedia (http://en.wikipedia.org/wiki/Keyboard_layout#Greek). I
do not know how standard this is (in Greece).
The keysyms dead_ogonek and dead_horn are only interpreted as
dasia and psili if the locale is el_GR.UTF-8. To use gr(polytonic)
with 'international' UTF-locales, these keysyms should be replaced
by 0x1000314 and 0x1000313 respectively (edit the file
/etc/X11/xkb/symbols/pc/gr).
Combinations, like ᾄ, are also possible; you have to use a fixed
order:
-- iota subscript first
-- accent second
-- breathing third
So for ᾧ you woud enter the keystroke sequence (keys as marked on
a US keyboard) ][v. [The order, I admit, seems unnatural. The
order that you propose looks better. This can be changed in the
Compose file, and maybe it should be filed as a bug -- but where?
Where does the Compose file come from?]
This works in openoffice, mozilla, and any text-mode editor you like.
The question is, is this a workable system in practice? I am sure
any desired keyboard behaviour could easily be made to work with
the tools we have (editing the files in /etc/X11/xkb and the
Compose file).
For instance, earlier on the list, Simos Xenitellis called
attention to a proposal for polytonic handling in Linux:
http://planet.hellug.gr/misc/polytonic/
This document has some keyboard combination tables of which a
small part is given below:
tonos/oxia ΄Dead key (;) + vowel
dialytika ¨ Dead key (:) + vowel (only υ, ι)
perispomeni ῀ Dead key ([) + vowel
iota subscript ͺDead key ({) + vowel
psili ᾿ Dead key (') + vowel/ρ
dasia ῾ Dead key () + vowel/ρ
varia ` Dead key (/) + vowel
macron ¯Dead key (]) + vowel
breve ˘ Dead key (}) + vowel
Only a few of those are the same as what xkb now provides, but it
is easy to change /etc/X11/xkb/symbols/pc/gr to give it this
behaviour:
xkb_symbols polytonic {
include pc/el(extended)
name[Group1] = Greece - Polytonic;
key AD11 { [ dead_tilde, dead_iota ] };
key AD12 { [ dead_macron, dead_breve ] };
key AC10 { [ dead_acute, dead_diaeresis ] };
key AC11 { [ 0x1000313,0x1000314 ] };
key AB10 { [ dead_grave, question] };
};
This of course makes the / key dead. The AltGr key is no longer
used. The Compose file does not have to be changed, but if the
other characters mentioned in the 'proposal' would have to be
entered (koppa, digamma, etc.) a few lines should be added to it.
Would this be easier to use than the present xkb system? I don't
know.
Thomas Wolff suggests using 'unused' keys like F6 for oxia, etc.
Again, I think that usability is the most important criterion for
the choice. To type Greek you would have to switch your keyboard
from Latin to Greek anyway. In the 'Greek' state all keys can get
a different function. Ideally the 'Greek' keys would do similar
things to 'Latin' keys (i.e. dead tilde would become dead
perispomeni, dead acute would become dead tonos, perhaps alt-i
could become dead_iota, etc.). But there does not seem to be a
special need to look for 'unused' keys, because in 'Greek' mode,
keys can be re-used.
Finally, would the system which is available on Windows XP
Re: Experiments with classical Greek keyboard input
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?
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
(me)~ιμεν)
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.
===
On 4/14/06, Jan Willem Stumpel [EMAIL PROTECTED] wrote:
Joe Schaffner wrote:
Hello Thomas,
It looks like we're all looking for non-standard ways to
capture polytonic Greek in Linux. This must mean no keymap
exists. Given one hundred years I'll figure out xkb and write
one.
xkb is not so difficult to figure out. At the moment you can
already enter polytonic Greek with it, and if you set the
Greek/Latin switch to a single key (I use left-windows), entering
mixed text consisting of Greek and Latin is not difficult.
The problem is: what is, from a user point of view, the desired
behaviour of the keyboard? At the moment xkb gr(polytonic) has:
key US GR keysym with gives
AD11 [ [ dead_tilde α ᾶ (perispomeni)
shiftAD11 { { dead_diaeresis υ (=y) ϋ (dialytika)
altgrAD12 « dead_macron α ᾱ (macron)
AD12 ] ] dead_iotaα ᾳ (iota subscript)
shiftAD12 } } VoidSymbol α α (does nothing)
altgrAD12 » dead_breve α ᾰ (breve)
AC10 ; ´ dead_acute α ά (tonos/oxia)
shiftAC10 : ¨ dead_hornα ἀ (psili)
altgrAC10 ΅ [not defined]α α (does nothing)
AC11 ' ' dead_grave α ὰ (varia)
shiftAC11dead_ogonek α ἁ (dasia)
altgrAC11 [not defined]α α (does nothing)
AC and AD indicate the third and fourth keyboard row from below,
respectively. The number indicates the position of the key
counting from the left, but not counting shift, capslock, tab.
The column US shows which symbols are engraved on the physical
keys of a standard US PC 104 keyboard. The column GR shows what
is engraved on the physical keys of a Greek keyboard, according to
Wikipedia (http://en.wikipedia.org/wiki/Keyboard_layout#Greek). I
do not know how standard this is (in Greece).
The keysyms dead_ogonek and dead_horn are only interpreted as
dasia and psili if the locale is el_GR.UTF-8. To use gr(polytonic)
with 'international' UTF-locales, these keysyms should be replaced
by 0x1000314 and 0x1000313 respectively (edit the file
/etc/X11/xkb/symbols/pc/gr).
Combinations, like ᾄ, are also possible; you have to use a fixed
order:
-- iota subscript first
-- accent second
-- breathing third
So for ᾧ you woud enter the keystroke sequence (keys as marked on
a US keyboard) ][v. [The order, I admit, seems unnatural. The
order that you propose looks better. This can be changed in the
Compose file, and maybe it should be filed as a bug -- but where?
Where does the Compose file come from?]
This works in openoffice, mozilla, and any text-mode editor you like.
The question is, is this a workable system in practice? I am sure
any desired keyboard behaviour could easily be made to work with
the tools we have (editing the files in /etc/X11/xkb and the
Compose file).
For instance, earlier on the list, Simos Xenitellis called
attention to a proposal for polytonic handling in Linux:
http://planet.hellug.gr/misc/polytonic/
This document has some keyboard combination tables of which a
small part is given below:
tonos/oxia ΄Dead key (;) + vowel
dialytika ¨ Dead key (:) + vowel (only υ, ι)
perispomeni ῀
Re: Experiments with classical Greek keyboard input
Πιστιόλης Κωνσταντίνος wrote: There is only one accent mark for modern greek, and it doesn't really matter how to draw it. It is just that the greek government admitted that 'tonos' which has replaced the former three accents (oxia, varia, perispomeni) is actualy nothing more than 'oxia'. In other words, formally speaking, oxia replaced both varia and perispomeni. ... Some greek terminology which may be useful -- 'Tonos' (τόνος) in greek means 'accent (mark)' in general, so this word was used to indicate an accent without specifying which one there are three tonos'es (οξεία, βαρεία, περισπωμένη) 'pnevma' (πνεῦμα) is the breathing mark. There are two of them -'psili' (ψιλή) smooth breathing mark (comma above) and -'dasia' (δασεία) rough breathing mark (reversed comma above). Both do not exist in modern monotonic greek 'ypogegrameni' (ὑπογεγραμμένη) is the iota subscript (like ῃ, ᾳ) and it also does not exist in monotonic greek. 'monotonic' and 'polytonic' greek, stands for using only one 'tonos' or all the symbols. Modern greek is officially monotonic, but some people (old men, the church, men of literature) still use it (me too). There were two branches of evolution of the greek language. The informal language of people, called 'dimotiki' (δημοτική, which means 'public') and the formal language of ecudated people 'katharevousa' (καθαρεύουσα, which means 'pure'). Katharevousa comes in many versions, depending how close it is to ancient greek. Today dimotiki is the official language and practically only the church sometimes uses 'simple' katharevousa (the most modern version). Church always uses polytonic greek, but it does't distinguish between oxia and varia (uses oxia only) I hope it helped. Feel free to ask any question about greek You have given a nice overview of Greek accent marks but it does not seem complete, looking at Unicode, so what about the others? From UnicodeData.txt, I see that the following combining marks occur in single or multiple combinations with Greek letters: DASIA DIALYTIKA MACRON OXIA PERISPOMENI PROSGEGRAMMENI PSILI TONOS VARIA VRACHY YPOGEGRAMMENI the following of which have not been mentioned in your overview: DIALYTIKA MACRON PROSGEGRAMMENI VRACHY The question that I am interested in most is what attachment of accent prefix to function keys would you suggest? Is any common attachment available with common input methods? I would like to enhance my editor mined with Greek input. Easily, two or three function keys are available, in shift-mode variations: Fn, Shift-Fn, Alt-Fn, Alt-Shift-Fn, Control-Fn, Control-Shift-Fn (where Fn is F2...F12, preferably F5, F6, F7) With some straight-forward X keyboard configuration, e.g. shifted digit keys can be added to the choice: Alt-0, Alt-Shift-0, Control-0, Control-Shift-0, Alt-Control-0, Alt-Control-Shift-0 (with digits 0...9) For discussion, I have the following proposal: (most important?) TONOS ΄ 0384;GREEK TONOS F6 (combined with acute for Latin letters) OXIA ´ 1FFD;GREEK OXIA Control-F6 (combined with circumflex) or Alt-F6 because it's an alternative? VARIA ` 1FEF;GREEK VARIA Shift-F6 (combined with grave) PERISPOMENI ῀ 1FC0;GREEK PERISPOMENI Shift-F5 (combined with tilde) or F5 because it's one of the more frequent accents? (less important?) PSILI ᾿ 1FBF;GREEK PSILI Control-F5 (because it looks similar to oxia on Control-F6) DASIA ῾ 1FFE;GREEK DASIA Shift-F5 (because it looks similar to varia on Shift-F6) YPOGEGRAMMENI ͺ 037A;GREEK YPOGEGRAMMENI Control-F5 (combined with cedilla) or Control-5 (combined with dot below) (even less important?) DIALYTIKA ϊ 03CA;GREEK SMALL LETTER IOTA WITH DIALYTIKA F5 (combined with diaeresis) or (if F5 preferred for perispomeni) ...? MACRON ᾱ 1FB1;GREEK SMALL LETTER ALPHA WITH MACRON Control-9 (combined with stroke) PROSGEGRAMMENI ι 1FBE;GREEK PROSGEGRAMMENI Alt-Control-5 (looking like an alternate to ypogegrammeni) VRACHY ᾰ 1FB0;GREEK SMALL LETTER ALPHA WITH VRACHY Control-7 (combined with breve) I appreciate your comments and suggestions. Kind regards, Thomas Wolff -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
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/ On 4/12/06, Joe Schaffner [EMAIL PROTECTED] wrote: 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: ἃ
Re: Experiments with classical Greek keyboard input
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
Re: Experiments with classical Greek keyboard input
Πιστιόλης Κωνσταντίνος wrote: In that page you propose: ...A font which includes all accent combinations for Classical Greek is, for instance, FreeSerif. The efont bitmap fonts (for xterm) also have them... Which may or may not be valid depending which symbol your keymap produces for acute (oxia or tonos). FreeSerif has a different symbol for 'tonos' and 'oxia' and ancient greek is probably not viewed correctly if someone types using the gr(polytonic) keymap with el_GR.UTF-8 locale You are right of course. But this (I am sorry) is in the 'keyboard input' section of my page, which I have not updated yet, and I am still not quite sure what it should say. Should there, or should there not, be input methods for both 'oxia' and 'tonos', given that they are 'officially' the same? I mean, what should be the advice to the classicists? My request for comment was, so far, only on the new 'font' section of the document, section 4.5. Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Την Fri, 10 Feb 2006 20:14:16 +0100,ο(η) Jan Willem Stumpel [EMAIL PROTECTED] έγραψε/wrote: Πιστιόλης Κωνσταντίνος wrote: In that page you propose: ...A font which includes all accent combinations for Classical Greek is, for instance, FreeSerif. The efont bitmap fonts (for xterm) also have them... Which may or may not be valid depending which symbol your keymap produces for acute (oxia or tonos). FreeSerif has a different symbol for 'tonos' and 'oxia' and ancient greek is probably not viewed correctly if someone types using the gr(polytonic) keymap with el_GR.UTF-8 locale You are right of course. But this (I am sorry) is in the 'keyboard input' section of my page, which I have not updated yet, and I am still not quite sure what it should say. Should there, or should there not, be input methods for both 'oxia' and 'tonos', given that they are 'officially' the same? I mean, what should be the advice to the classicists? My request for comment was, so far, only on the new 'font' section of the document, section 4.5. Ok, quite explanatory! Just one comment: ... Typographical fashions in Greece have now changed, so this solution is right for modern Greek also... It's not like a typographic fashion change; modern greek may still use any glyph for 'tonos'. You may see a dot, an acute, a line, a triangle, even a comma if it is on a capital letter (like capital A-acute Ά, usually accent goes to the left of capital letters). Let me explain more. There is only one accent mark for modern greek, and it doesn't really matter how to draw it. It is just that the greek government admitted that 'tonos' which has replaced the former three accents (oxia, varia, perispomeni) is actualy nothing more than 'oxia'. In other words, formally speaking, oxia replaced both varia and perispomeni. Why is valid for monotonic tonos (oxia) to have any glyph? Because, at least since my parents remember (1940), noone cared about the difference between varia (`) and oxia (΄). The books were printing them correctly but noone bothered in hand writing the formal 'katharevousa' or 'dimotiki' greek. People used to make a distinction only between perispomeni and tonos (meaning oxia or varia) and they usually preffered the glyph of oxia or a vertical line above for this tonos. Modern polytonic greek scripts usually don't use varia (grave). oxia is mostly used in it's place Technically speaking, a 'correct' font may be: 1. monotonic, (with no polytonic characters at all) where it doesn't matter which glyph it uses for tonos 2. polytonic, which shall define the same glyph in 0x1f71 as in 0x3ac and it should be oxia. (if it is not oxia, the font is still usable for monotonic greek, even for polytonic if one does not use varia, but not for ancient greek or modern polytonic greek with varia) The 'correct' way to render different glyphs for every case, is probably a 'smart' font implementation (unfortunately too far from today's reality). Some greek terminology which may be useful -- 'Tonos' (τόνος) in greek means 'accent (mark)' in general, so this word was used to indicate an accent without specifying which one there are three tonos'es (οξεία, βαρεία, περισπωμένη) 'pnevma' (πνεῦμα) is the breathing mark. There are two of them -'psili' (ψιλή) smooth breathing mark (comma above) and -'dasia' (δασεία) rough breathing mark (reversed comma above). Both do not exist in modern monotonic greek 'ypogegrameni' (ὑπογεγραμμένη) is the iota subscript (like ῃ, ᾳ) and it also does not exist in monotonic greek. 'monotonic' and 'polytonic' greek, stands for using only one 'tonos' or all the symbols. Modern greek is officially monotonic, but some people (old men, the church, men of literature) still use it (me too). There were two branches of evolution of the greek language. The informal language of people, called 'dimotiki' (δημοτική, which means 'public') and the formal language of ecudated people 'katharevousa' (καθαρεύουσα, which means 'pure'). Katharevousa comes in many versions, depending how close it is to ancient greek. Today dimotiki is the official language and practically only the church sometimes uses 'simple' katharevousa (the most modern version). Church always uses polytonic greek, but it does't distinguish between oxia and varia (uses oxia only) I hope it helped. Feel free to ask any question about greek regards, Konstantinos -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Imitating the difficult-to-learn Windows system for 'multiple diacriticals' should IMHO be offered as an option, but not as the only option. The ease with which diacriticals can be combined by means of xkb/Compose could be a 'Linux selling point' in the academic world. BTW I am now terribly confused about he tonos/oxia issue. -- Tonos and oxia are considered equivalent in Unicode - but why, then, are there different code points for them (U+1FFD, and all the letters with oxia, vs. U+0384 and all the letters with tonos)? Where does it actually say that they are equivalent? -- Many (maybe most) font creators made different glyphs for oxia and tonos (although others did not, see the Gentium font), because they were looking at unicode. But, surely, that was the correct place to look? -- Kostas calls it a bug of the fonts. If there is a bug, isn't it in the Unicode standard ? I hope there is a way to put the genie back into the bottle. Just making the keyboard entry for oxia hard, forcing people not to use it does not seem to be the right way. Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
On Mon, 2006-02-06 at 21:58 +0100, Jan Willem Stumpel wrote: Imitating the difficult-to-learn Windows system for 'multiple diacriticals' should IMHO be offered as an option, but not as the only I am not sure what complexities the Windows keyboard layout has that make it difficult to re-implement as an extra layout in Xorg. My understanding is that sets too many dead keys, as there is a limitation of stacking dead keys together. option. The ease with which diacriticals can be combined by means of xkb/Compose could be a 'Linux selling point' in the academic world. BTW I am now terribly confused about he tonos/oxia issue. -- Tonos and oxia are considered equivalent in Unicode - but why, then, are there different code points for them (U+1FFD, and all the letters with oxia, vs. U+0384 and all the letters with tonos)? Where does it actually say that they are equivalent? It at http://www.unicode.org/charts/PDF/U1F00.pdf For example, see 1F71, Greek Small Letter Alpha with Oxia. The three horizontal bars show equivalence between glyphs. It shows that 1F71 == 03AC. It is common to have these equivalences; compatible software should take care of these equivalences for the end-users and fold glyphs to their initial equivalences. -- Many (maybe most) font creators made different glyphs for oxia and tonos (although others did not, see the Gentium font), because they were looking at unicode. But, surely, that was the correct place to look? Unicode does not dictate how fonts should look. See the Fonts section at http://www.unicode.org/charts/PDF/U1F00.pdf The selected font was merely a font donated for this purpose. -- Kostas calls it a bug of the fonts. If there is a bug, isn't it in the Unicode standard ? I am not sure about the background of this; I think it has to do with different schools of thought on how original documents looked like. I hope there is a way to put the genie back into the bottle. Just making the keyboard entry for oxia hard, forcing people not to use it does not seem to be the right way. The choice is between 1. do not provide an option for people to type 1F71 and other vowels with oxia. (current situation) 2. provide such a choice to type vowels with oxia. The preference is to move to Choice 2, so that if a user wants this option, he has the freedom of choice to do so. Giving equivalent exposure to both oxia and tonos can create a mess with documents. That's why oxia should be somewhere far away, not on a nearby dead key. Google does not normalise yet texts so that these equivalent glyphs are treated the same. Simos -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Την Mon, 06 Feb 2006 21:58:13 +0100,ο(η) Jan Willem Stumpel [EMAIL PROTECTED] έγραψε/wrote: Imitating the difficult-to-learn Windows system for 'multiple diacriticals' should IMHO be offered as an option, but not as the only option. The ease with which diacriticals can be combined by means of xkb/Compose could be a 'Linux selling point' in the academic world. BTW I am now terribly confused about he tonos/oxia issue. -- Tonos and oxia are considered equivalent in Unicode - but why, then, are there different code points for them (U+1FFD, and all the letters with oxia, vs. U+0384 and all the letters with tonos)? Where does it actually say that they are equivalent? In ancient greek and modern katharevousa (a formal archaic greek) there were three accents. (I don't know the english names) Perispomeni (~), oxia (acute) and grave (`), which were all together named with the word 'tonos' (accents) Yet, in modern greek practically noone was actually distinguishing between acute and grave, so the accents used was oxia and perispomeni. The next step was to deprecate all these accent marks and use only one simpe accent, for the words that have multiple syllabes. This was called 'monotonic greek'. That simple accent was simply called tonos (accent) and actually was the acute. Still typographically there was no prefference about the slope of tonos (/ \ or |) and modern monotonic greek fonts may use a | glyph, or a dot above This glyph may be good for monotonic greek, but it is completely unsuitable for ancient or polytonic greek, so in the meantime font designers were making different glyphs and were using different character codes for each case. This is a very stupid distinction, because there is no such difference between tonos and oxia (acute), and no such symbol as a vertical line above or a dot above in greek; The issue was finally resolved by greek government, which declared that tonos is actually the acute (oxia). But this has become TOO LATE, because EL.O.T. (the Hellenic Standarization Organization) had allready proposed different characters to the unicode consortium. After that, many people who were using polytonic greek (out of Greece) had allready converted their texts from the original 8bit encodings to unicode using the new characters with 'oxia' This faq describes the story. http://www.unicode.org/faq/greek.html and for more info http://ptolemy.tlg.uci.edu/~opoudjis/unicode/unicode.html The difference between 'oxia' and 'tonos' and the problems related to that is mentionned in more detail here: http://ptolemy.tlg.uci.edu/~opoudjis/unicode/unicode_gkbkgd.html#oxia -- Many (maybe most) font creators made different glyphs for oxia and tonos (although others did not, see the Gentium font), because they were looking at unicode. But, surely, that was the correct place to look? Well there is no other way for modern greek. Neither can be a distinction between tonos and oxia, nor we may have two different keycodes for the same character. Imagine what will happen if a Greek user uses polytonic keyboard to enter a filename. It's just a matter of fonts. If someone wants to write monotonic greek is free to use any font he/she likes. But for polytonic greek he/she has to use a polytonic font (which must define correctly the polytonic glyphs) Font designers claim the opposite; that the user should keep oxia and tonos combinations distinct, but this is incorrect according unicode and, as I said, is extremely dangerous when mixed with modern greek. Then again, the actual reason is that unicode cannocinal equivalence is not correctly implemented neither by applications nor by fonts. According to unicode, a proccess must not treat equivalent characters differently, nor assume that some other proccess does. Even more, a text may be automatically normalized at any time (without the user or any other program knowing that) by the system or a intermediate proccess, having some characters decomposed or replaced by their canonical equivalents. -- Kostas calls it a bug of the fonts. If there is a bug, isn't it in the Unicode standard ? As Simos said, this is rather a way of thinking than a bug. Unicode has not altered existing encodings. It has included them all and defined the relationships and the equivalences for future use. The problem is that most applications do not yet implement these rules. And since people are still treating equivalent characters as not equal, some font designers decide to do so too. When it comes to Greek there is another reason. Usually a font implements the basic symbols first (with tonos) in the monotonic way, so later they just add polytonic accents. I hope there is a way to put the genie back into the bottle. Just making the keyboard entry for oxia hard, forcing people not to use it does not seem to be the right way. The correct way is the maturity of unicode: When all the texts are beeing normalized, all programs will become aware of character
Re: Experiments with classical Greek keyboard input
On Tue, Feb 07, 2006 at 01:35:40AM +0200, ? wrote: -- Many (maybe most) font creators made different glyphs for oxia and tonos (although others did not, see the Gentium font), because they were looking at unicode. But, surely, that was the correct place to look? Well there is no other way for modern greek. Neither can be a distinction between tonos and oxia, nor we may have two different keycodes for the same character. Imagine what will happen if a Greek user uses polytonic keyboard to enter a filename. It's just a matter of fonts. If someone wants to write monotonic greek is free to use any font he/she likes. But for polytonic greek he/she has to use a polytonic font (which must define correctly the polytonic glyphs) Font designers claim the opposite; that the user should keep oxia and tonos combinations distinct, but this is incorrect according unicode and, as I said, is extremely dangerous when mixed with modern greek. Then again, the actual reason is that unicode cannocinal equivalence is not correctly implemented neither by applications nor by fonts. Another way of looking at it is that the Unicode people are stuck in the world of Windows and word processors and can't see past it. Clearly something like the filesystem that deals with (essentially, aside from \0 and /) arbitrary binary byte sequences cannot be expected to, and should not, make Unicode canonical equivalence substitutions. If you're actually worried about people using the 'bad' character choices in filenames, a better solution would probably be to advise people making fonts to have these characters represented by the replacement character glyph, so that only the applications which understand canonical equivalences would display anything reasonable at all. That would be a good discouragement against their use. :) [Here I'm talking about people making terminal fonts, gui interface element fonts, etc., not fonts for wordprocessing/print use which we don't really have much influence over.] However, this issue does get much more hairy with other canonical equivalence issues like combining/precombined forms, canonical ordering of combining characters, etc. I don't know any way to address it except asking users not to be stupid. Somehow I expect the ones who will be _typing_ filenames will be savvy enough to stick to sane filename choices, and the rest will just select files from a Qt/GTK/whatever dialog box. It's important to remember that this is really nothing new with Unicode. It's always been possible to make nasty filenames that look equivalent but which are not, for instance embedding terminal escape sequences in filenames... According to unicode, a proccess must not treat equivalent characters differently, nor assume that some other proccess does. This requirement is vague and inherently impossible to satisfy if you use broad enough concepts of 'a process'. For example, is it illegal for strlen to return different numbers on strings that have the same canonical representation, but which are a different number of bytes? :) Even more, a text may be automatically normalized at any time (without the user or any other program knowing that) by the system or a intermediate proccess, having some characters decomposed or replaced by their canonical equivalents. Yes, lovely. A binary-clean text editor or hex editor that processes the text as UTF-8 (or any other unicode encoding) can trash the binary file at any time. Just lovely. Moreover, guidelines like this are encouraging implementors of UTF-8 text editors to make broken non-binary-clean implementations, and discouraging anyone who wants a binary-clean system from considering UTF-8. Gross design mistakes like this, and the Windows/16bit-centricness of the Unicode spec, have me largely convinced that UCS (ISO-10646) is the standard we should follow for basic character handling under *nix, rather than Unicode, and that Unicode should just be used as a guide for supplemental functionality (such as case folding, collation, etc.) in applications that need such features. I hope there is a way to put the genie back into the bottle. Just making the keyboard entry for oxia hard, forcing people not to use it does not seem to be the right way. The correct way is the maturity of unicode: When all the texts are beeing normalized, all programs will become aware of character equivalence, and smart fonts will be used to decide which glyph suits best for every case. Normalization at display time to select a glyph image is a very good idea. Normalization of the actual stored data is a horrible mistake. In the meantime, some font designers use this workaround to improve the displaying of their fonts, thus making the problem persistant :( Rich -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
I'm sorry for not contributing more to this thread or to the work needed to be done to solve the issues discussed here... But here are some thoughts in response to Kostas' message: From: Πιστιόλης Κωνσταντίνος pistiolis στο ts τελεία sch τελεία gr This keymap defines a dead key for every combination, and is more or less followed by the windows XP, using up to 16 or more dead keys! You know, there really should be a way to create a keyboard layout on X11 compatible with the Windows XP / typewriter one. Is this currently possible? To do this, either many more generic dead keys are needed, or a way to have a single keypress produce many keysyms, for use in a compose sequence. For reference, here's the Windows XP way to produce polytonic Greek characters: http://support.microsoft.com/default.aspx?scid=kb;el;GR750052 According to the table there, the dead keys used are [ ] - = | \ / ; ' combined with Shift, Alt, and AltGr. In total, 27 different virtual dead keys... Not an easy system to learn, but I think anyone who's learned it, should be able to keep using it under X11. Is it possible to implement this with the current xkb plus simple Compose-file infrastructure? Or is it only possible with complex input method software? 1. most of the dead keys are too often used to be put in third level (except for makron, vrahy). Each symbol is aproximately used in 1 every 3-5 words! Right! By the way, I've typed a bit more polytonic Greek recently, and the layout currently included in XFree86/X.org worked nicely for me (who isn't used to any other polytonic Greek layout). I don't know if the latter odd combination would produce conflicts in an international Compose file, but this idea was used in the past in greek keyboard, in the following combinations: dead_tonos + . : above (middle) dot dead_tonos + : « dead_tonos + : » I don't think there are any conflicts, and these combinations are very nice from a usability point of view: you don't have to memorize obscure AltGr combinations, just to remember that puting an accent on a character that doesn't take one produces a special (less common) character that looks similart. The three combinations listed above were also used in some old MS-DOS keyboard drivers. The present pc/gr file uses altgr for the euro symbol, the middle dot and the «» symbols, along with the Compose combinations and I suggest the same (duality) for all new symbols Another idea is to use the same kind of rules to increase the usability of the polytonic keyboard for writing tenchical texts: To have a double press of a dead_key and the altGr + dead_key to produce the lost symbol so that the user wouldn't have to ... I agree with this. Another proposed use of altGr is for the dead acute. ELLOT, the Hellenic Standard Organization has proposed and defined different symbols for acute and tonos (which is actually the same symbol) which are equivalent in unicode. That was a mistake... My opinion is that having different glyphs for OXIA and TONOS in fonts is a bug. Upright and slanted oxia don't have any meaningful distinction in Greek, they're just graphic variants. Some fonts are designed with a modern look, where oxia looks like a bullet or an equilateral triangle. These fonts can only be used for modern Greek. Other fonts are designed more traditionally, with a slanted oxia. Putting glyphs with upright oxia in these fonts looks, IMHO, ugly, and I think was only motivated by font creators looking at Unicode, seeing characters both with OXIA and with TONOS in their names, and naïvely deciding to differentiate their appearance, without noticing that they are equivalent according to Unicode, and without a justification in representing actual Greek text. By the way, there is a case where font designers have almost universally drawn two canonically equivalent Unicode characters differently, and that's U+00B7 MIDDLE DOT (·) and U+0387 GREEK ANO TELEIA (·). Here they're next to each other: ·· Most fonts have different glyphs for them, because the usual appearance of middle dot looks wrong as an _ano teleia_. So... in this case there is some justification. But the correct way to solve this according to the Unicode model is with higher-level protocols and smart fonts. For example, with modern smart fonts (OpenType etc.), it's possible to have both U+00B7 and U+0387 assume their correct shape and position depending on their surrounding characters. The combination altGr-dead_tonos + vowel is proposed to produce the letter with accent, in case someone needs it. Well... it probably won't hurt much, except in perpetuating the idea that tonos/accent and oxia/accute are different. And also systems which do their own keysym processing (i.e. GTK+) will have to add some more illogical combinations... I have a question. It is mentioned that it's a bug to use dead_horn and dead_ogonek and that combining comma above 0x0313 and combining reversed comma above
Re: Experiments with classical Greek keyboard input
You know, there really should be a way to create a keyboard layout on X11 compatible with the Windows XP / typewriter one. Is this currently possible? To do this, either many more generic dead keys are needed, or a way to have a single keypress produce many keysyms, for use in a compose sequence. For reference, here's the Windows XP way to produce polytonic Greek characters: http://support.microsoft.com/default.aspx?scid=kb;el;GR750052 According to the table there, the dead keys used are [ ] - = | \ / ; ' combined with Shift, Alt, and AltGr. In total, 27 different virtual dead keys... Not an easy system to learn, but I think anyone who's learned it, should be able to keep using it under X11. Is it possible to implement this with the current xkb plus simple Compose-file infrastructure? Or is it only possible with complex input method software? I thought of this too, but I don't see an easy way to do this with xkb. Anyway, the idea of using combinations of dead keys instead of a dead key for every mark combination was used before in macintosh and as long as the single symbol dead keys have the same position with the old keymap... perhaps it is enough for now. It is propably better to implement this legacy keyboard map with some complex input method at a later time, instead of messing up xkb now. ... I don't know if the latter odd combination would produce conflicts in an international Compose file, but this idea was used in the past in greek keyboard, in the following combinations: dead_tonos + . : above (middle) dot dead_tonos + : « dead_tonos + : » I don't think there are any conflicts, and these combinations are very nice from a usability point of view: you don't have to memorize obscure AltGr combinations, just to remember that puting an accent on a character that doesn't take one produces a special (less common) character that looks similart. The three combinations listed above were also used in some old MS-DOS keyboard drivers. yes, it is a very good idea, but in an international compose file it would be a conflict if greek keymap wanted to use: dead_acute + . : above (middle) dot and some other language's keymap uses: dead_acute + . : degree symbol The dead_XXX definitions are accessible for all languages (and this is correct). The correct way to do this would be to have xkb defining a different Compose file for every keymap ... Another idea is to use the same kind of rules to increase the usability of the polytonic keyboard for writing tenchical texts: To have a double press of a dead_key and the altGr + dead_key to produce the lost symbol so that the user wouldn't have to ... I agree with this. But: 1. it could cause the same kind of conflicts as mentioned above 2. in the proposed keymap dead_horn is placed in ' so we want the rule dead_horndead_horn: '\'' But if someone creates a new keymap with dead_horn placed in ] we won't be able to add a new rule. This will work for only one keymap messing up all the (future) others (if we ever need any) Another proposed use of altGr is for the dead acute. ELLOT, the Hellenic Standard Organization has proposed and defined different symbols for acute and tonos (which is actually the same symbol) which are equivalent in unicode. That was a mistake... My opinion is that having different glyphs for OXIA and TONOS in fonts is a bug. Upright and slanted oxia don't have ... are equivalent according to Unicode, and without a justification in representing actual Greek text. ... is some justification. But the correct way to solve this according to the Unicode model is with higher-level protocols and smart fonts. For example, with modern smart fonts (OpenType etc.), it's possible to have both U+00B7 and U+0387 assume their correct shape and position depending on their surrounding characters. I agree The combination altGr-dead_tonos + vowel is proposed to produce the letter with accent, in case someone needs it. Well... it probably won't hurt much, except in perpetuating the idea that tonos/accent and oxia/accute are different. And also systems which do their own keysym processing (i.e. GTK+) will have to add some more illogical combinations... I could hurt because many people will prefer to use it, in order to avoid this bug of the fonts. (and this will cause a lot of trouble when mixed up with monotonic greek of a linux with hellenic locale) This is why I propose altGr-dead_acute, so that the combination will be hard, forcing people not to use it. Unfortunately this is necessary, because a lot of polytonic greek texts are encoded like that. If you want to search text with google you will have to use this accent. Look at google search results. Searching for: ἀνθρώπου (with tonos) yields 584 results and ἀνθρώπου (with polytonic set's acute) yields 21.400 results! (I think that this happens because most texts are converted from older 8bit encodings) This is a google bug (?) too,
Re: Experiments with classical Greek keyboard input
Joe Schaffner wrote: [..] With this font, I can capture the entire entry, no problems, pointing fingers, arrows, boxes, tiny-elvises, polygreek etymology... There is virtually nothing I cannot do with the Unicode character set alone. And in another message: http://modern-greek-verbs.tripod.com/home.html#unicode Your document is impressive, and it clearly shows why we need Unicode (a system which allows mixing many different languages in one document) and also why we need input systems capable of switching between languages very quickly (i.e. not requiring going through complicated nested menus). Fonts are not a real problem. There are many fonts which can display both ancient and modern Greek in UTF-8. You do not especially need the XP version of Times New Roman (although thanks for the tip). As far as switching between Latin and Greek is concerned, I would recommend setting the group toggle key to only one single key, not something like control-alt-K. I just set it to Left-Windows which (on my system) is not used for anything useful. It really cycles, i.e. when you get to the end of the possible groups, you get back to the beginning. That does not seem to work for you; I do not know why. Greek is, of course, a language which is enormously important in the history of civilisation, and is therefore of interest to people from many different cultures (or, in computer terms, 'locales'). Such people could very well be resident in Greece, so they need to enter both 'ancient' and 'modern' Greek in their computers with a minimum of fuss. Therefore now I think that there should be either -- one gr keyboard layout which allows entering both modern and ancient Greek. -- two gr keyboard layout variants, one which is optimised for modern Greek, and another one which enables inputting BOTH ancient and modern Greek (i.e both tonos and oxía) - although it might be somewhat sub-optimal compared to a keyboard which is 'modern Greek only'. BTW What is a 'tiny elvis'? Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
[Fwd: Re: Experiments with classical Greek keyboard input]
Dear All,
This e-mail appears not to have made it to the list (Kostas is probably
not subscribed to the list), therefore I forward it as there are some
interesting information here.
Simos
Forwarded Message
From: Πιστιόλης Κωνσταντίνος pistiolis στο ts τελεία sch τελεία gr
To: Simos Xenitellis simos74 στο gmx τελεία net,
linux-utf8@nl.linux.org
Subject: Re: Experiments with classical Greek keyboard input
Date: Tue, 31 Jan 2006 22:11:05 +0200
Την Mon, 30 Jan 2006 19:05:26 +,ο(η) Simos Xenitellis
[EMAIL PROTECTED] έγραψε/wrote:
O/H Jan Willem Stumpel έγραψε:
Simos Xenitellis wrote:
You can have a look at this document,
http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it
should be feasible to discern the combinations proposed. For example,
Νεκρό πλήκτρο is Dead key in the list. If there are queries, feel
free to refer to me.
Very interesting. Is this a proposal, or has it been implemented?
According to Babelfish, you say Your distribution of Linux that
has been published after October 2005 should include the renewed system
that we describe here. Mine does not, but I don't trust the Babelfish
translation..
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.
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).
If it could be any, it is the old typewriter's standard (computers were not
used for text proccessing at the time polytonic was removed from modern
greek),
but it didn't cover the full polytonic because it didn't have vareia
(grave),
makron, and vrahy. It was rather used for modern greek than ancient greek.
This keymap defines a dead key for every combination, and is more or less
followed by the windows XP, using up to 16 or more dead keys!
However, the proposed keymap uses the same principles and only needs 9
dead keys
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?
the accents, dead iota and the breathing marks shouldn't use it:
1. most of the dead keys are too often used to be put in third
level (except for makron, vrahy). Each symbol is aproximately
used in 1 every 3-5 words!
2. the altGr chooser was not used in the old typewriter's standard.
In fact, all symbols (except vareia=grave) have a position in
the old typewriter's standard which is preserved in the proposed keymap.
About makron and vrahy, I have proposed putting them in ] and } and not as
an
altGr combination, as the openning [ and { are already occupied
as dead keys (~ and iota subscript in accordance to the typewriter
standard).
The concept is that it wouldn't be bad to lose the closing brace, if
the openning brace is lost too, and it would save the altGr+dead_key
combinations for future use (see below).
The other symbols (ancient greek numbers) are also needed in modern
(monotonic) greek, and could be added either as altGr combinations,
or composed with dead acute, or even in both ways. eg:
altGr + sigma: numeric stigma
or
dead tonos + sigma : numeric stigma
I don't know if the latter odd combination would produce conflicts in
an international Compose file, but this idea was used in the past in
greek keyboard, in the following combinations:
dead_tonos + . : above (middle) dot
dead_tonos + : «
dead_tonos + : »
I believe that the Compose should actually be a part of the keymap;
not the locale. Dead keys are very good sticky third level choosers, for
languages that use them.
The present pc/gr file uses altgr for the euro symbol, the middle dot
and the «» symbols, along with the Compose combinations and I suggest
the same (duality) for all new symbols
Another idea is to use the same kind of rules to increase the usability
of the polytonic keyboard for writing
Re: Experiments with classical Greek keyboard input
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
Re: Experiments with classical Greek keyboard input
I've only followed this discussion partially because I'm not familiar with ancient Greek, but I noticed a few things. Jan Willem Stumpel wrote: Proposal (I tested this, with the small alpha only, and it seems to work): -- Greek (modern and ancient) should use the common (international) Compose file. -- The international Compose file should have different definitions for letters with simple tonos and letters with simple oxia. At present, the Compose file has dead_acute Greek_alpha : ά U03AC # GREEK SMALL LETTER ALPHA WITH TONOS (and grep GREEK SMALL LETTER ALPHA Compose|grep -v AND|grep OXIA gives nothing!) It should actually list the following two entries from Unicode data: 1F71;GREEK SMALL LETTER ALPHA WITH OXIA;Ll;0;L;03ACN;;;1FBB;;1FBB 1FBB;GREEK CAPITAL LETTER ALPHA WITH OXIA;Lu;0;L;0386N1F71; 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 [EMAIL PROTECTED] 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 -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
O/H Thomas Wolff έγραψε: I've only followed this discussion partially because I'm not familiar with ancient Greek, but I noticed a few things. Jan Willem Stumpel wrote: Proposal (I tested this, with the small alpha only, and it seems to work): -- Greek (modern and ancient) should use the common (international) Compose file. -- The international Compose file should have different definitions for letters with simple tonos and letters with simple oxia. At present, the Compose file has dead_acute Greek_alpha : ά U03AC # GREEK SMALL LETTER ALPHA WITH TONOS (and grep GREEK SMALL LETTER ALPHA Compose|grep -v AND|grep OXIA gives nothing!) It should actually list the following two entries from Unicode data: 1F71;GREEK SMALL LETTER ALPHA WITH OXIA;Ll;0;L;03ACN;;;1FBB;;1FBB 1FBB;GREEK CAPITAL LETTER ALPHA WITH OXIA;Lu;0;L;0386N1F71; 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 [EMAIL PROTECTED] 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.) 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 -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Simos Xenitellis wrote: You can have a look at this document, http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it should be feasible to discern the combinations proposed. For example, Νεκρό πλήκτρο is Dead key in the list. If there are queries, feel free to refer to me. Very interesting. Is this a proposal, or has it been implemented? According to Babelfish, you say Your distribution of Linux that has been published after October 2005 should include the renewed system that we describe here. Mine does not, but I don't trust the Babelfish translation.. As far as I can see, it would not be difficult to implement it. Nothing would have to be changed in the binaries, only in the xkb and Compose files. I noticed you only want to use 'two level' keys (normal and shift), not using AltGr. Is this some kind of standard? (e.g. Greek national standard, or some other kind of standard)? The present pc/gr file in xkb uses 'three level' keys. BTW I suppose when you say that tonos/oxia is on the ; key, you mean the key which is ; on US keyboards, not the key which is ; on Greek keyboards? The Compose file should be broken in smaller files per script rather than having a big monolithic file. What advantage would this bring? If we have many small pieces of the Compose file, how is the user (or the system) supposed to decide when to use which piece? Wouldn't this create another configuration problem? UTF-8 allows using one system for all languages and scripts, without changing locales. There is only one, IMHO unavoidable, but small, disadvantage: some files (like fonts, and the Compose file) tend to become rather big. But memory and disk space are not as expensive as they used to be. And the user does not notice anything of this. She just thinks: wow! I can input any language anywhere, at any time! There is increasing interest in updating this area of Xorg (http://community.livejournal.com/xkbconfig/) and I hope it gets done soon. Hmm.. xkb and Compose are two completely different mechanisms. One is input to the other. People often complain about xkb being 'mysterious' or 'arcane'. Since xfree86 4.3 and x.org came around, it isn't anymore. It just lacks user-level documentation. Recently, thanks to this list, I have come close enough to enlightenment to attempt a user-level description on my utf-8 page, sections 6.1 and 6.2 (http://www.jw-stumpel.nl/stestu). Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
O/H Jan Willem Stumpel έγραψε: Simos Xenitellis wrote: You can have a look at this document, http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it should be feasible to discern the combinations proposed. For example, Νεκρό πλήκτρο is Dead key in the list. If there are queries, feel free to refer to me. Very interesting. Is this a proposal, or has it been implemented? According to Babelfish, you say Your distribution of Linux that has been published after October 2005 should include the renewed system that we describe here. Mine does not, but I don't trust the Babelfish translation.. 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. 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? BTW I suppose when you say that tonos/oxia is on the ; key, you mean the key which is ; on US keyboards, not the key which is ; on Greek keyboards? Indeed, ; it is the physical key according to the US keyboard. The proposal document does not include a specific dead key to produce oxia. In the Windows XP layout there is such a dead key, in an uncomfortable location however, for those end-users who would like to use it. The Compose file should be broken in smaller files per script rather than having a big monolithic file. What advantage would this bring? If we have many small pieces of the Compose file, how is the user (or the system) supposed to decide when to use which piece? Wouldn't this create another configuration problem? The configuration mechanism of Xorg would shield the end-user from this complexity. I am referring to the needs of the developers. For example, suppose a lesser known language wants to make an installable package that adds writing support. The way this could be done is by dropping (adding) the appropriate files in the appropriate directory. Otherwise, there would be need to patch the monolithic file. In addition, the Polytonic section in the Compose file is suitable to be auto-generated from a script as the multiple diacritics on vowels bring up combinations. UTF-8 allows using one system for all languages and scripts, without changing locales. There is only one, IMHO unavoidable, but small, disadvantage: some files (like fonts, and the Compose file) tend to become rather big. But memory and disk space are not as expensive as they used to be. And the user does not notice anything of this. She just thinks: wow! I can input any language anywhere, at any time! As I mention above, the splitting of the files would be an advantage for the developers. The end-user would only see a GUI configuration tool. No setxkbmap or editing of xorg.conf. There is increasing interest in updating this area of Xorg (http://community.livejournal.com/xkbconfig/) and I hope it gets done soon. Hmm.. xkb and Compose are two completely different mechanisms. One is input to the other. People often complain about xkb being 'mysterious' or 'arcane'. Since xfree86 4.3 and x.org came around, it isn't anymore. It just lacks user-level documentation. Recently, thanks to this list, I have come close enough to enlightenment to attempt a user-level description on my utf-8 page, sections 6.1 and 6.2 (http://www.jw-stumpel.nl/stestu). Thanks for this. We need to put effort so that gswitchit (Keyboard Indicator applet in GNOME) gets more and more advanced and ubiquitous. The plan is for gswitchit to be used for KDE as well. This is the proper direction so end-users are happy that their settings just work. Simos -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
On Thu, 2006-01-26 at 20:29 +0100, Jan Willem Stumpel wrote: Simos Xenitellis wrote: O/H Jan Willem Stumpel έγραψε: This also means that when you run scim, the ogonek and horn do not work as breathing signs even if the locale is el_GR.UTF-8, because scim's internal copy of the Compose file is only the common one. In addition, when you try to type Greek Polytonic in OpenOffice.org, it will not work. The reason is that the default Input Method, GTK+ IM does not know yet about these dead keys and does not pass them on. Therefore, when selecting Greek Polytonic in the X Input Method (XIM), for example, using System/Preferences/Keyboard or adding the Keyboard Indicator applet, all in GNOME (such as Ubuntu), you have to do first export GTK_IM_MODULE=xim then run OpenOffice.org The situation is very complicated, because there are many factors which can influence the result. Yes, it is best to set GTK_IM_MODULE=xim (in Debian, you put this in /etc/environment). Then you can enter polytonic Greek everywhere (using the xkb facilities) *if* the /etc/X11/xkb/symbols/pc/gr has been hacked, *and* the locale is any type of UTF-8 (with the possible exception of el_GR.UTF-8), *and* the application has access to a proper font. GTK+ 2.x based applications that are linked to pango are in the happy situation where glyphs from different fonts are grouped together to fill in the Unicode table. Therefore, if you have at least one font in your system that has Greek Polytonic support, this will be used for your GTK+ application. For issues like font preference for this, the file /etc/fonts/fonts.conf (fontconfig) is used which can dictate where to choose from first. OpenOffice.org appears to do its internal choosing of fonts (does not obey fontconfig), which causes some pain for Greek. Specifically, if the selected font in OOo does not have Greek glyphs AND your distribution has Asian support, Greek glyphs will be chosen from Asian fonts. As far as I could find out, with GTK_IM_MODULE=xim, xkb-type polytonic Greek works (i.e. you can enter ᾆ) in just about all situations; I tested all 12 combinations of 1-3 and A-D below: 1. No input method framework present 2. uim present 3. scim present A. text mode programs in xterm AFAIK, xterm uses XIM by default. B. mozilla, bluefish C. openoffice Both B and C are based on GTK+, so GTK_IM_MODULE to xim simply directs them use the standard X Input Method. Any scim/uim/iiimf present cannot affect these applications when GTK_IM_MODULE is set to xim. D. QT programs QT uses XIM directly, so it is not affected by setting GTK_IM_MODULE. The QT folks are actually trying to make a QT Input Method, similar to GTK+ IM. With scim, at first I thought that there were program types in which xkb polytonic Greek did not work. But this is (fortunately) not the case. With scim, you must just take care that the keyboard is set separately to English/European (i.e. direct input, through xkb) for each application. Indeed, that should be the case. I did not find Greek Polytonic in either scim or uim, or even iiimf. There was only modern Greek. Some uim and scim docs recommend using GTK_IM_MODULE=uim or GTK_IM_MODULE=scim. It seems this is not necessary; GTK_IM_MODULE=xim works in all circumstances. By setting GTK_IM_MODULE to either xim, uim, scim or iiim, you enable them for GTK+ applications. When the variable was set to xim, any of the other frameworks where not active for these GTK+ applications. But with the original /etc/x11/xkb/symbols/pc/gr, with or without el_GR.UTF-8 locale, polytonic Greek does not work with scim. I now Which distribution are you using? What are the changes that you have for the gr file that makes it work for you? The latest is http://cvs.freedesktop.org/xlibs/xkbdesc/symbols/gr?view=markup There is some work to update the settings for Greek Polytonic. Two thoughts here are: 1. Place ¨ (dyalytika) on the same dead key as with modern Greek. 2. There is no way to type oxia; tonos and oxia are considered equivalent in Unicode 3.0+ and tonos is preferred. However, if users would rather have an oxia option, I feel we should provide it. think the keyboard action is as follows: without uim or scim: keyboard -- xkb -- xlib Compose -- application with uim: keyboard -- xkb -- xlib Compose -- uim -- application and with scim: keyboard -- xkb -- scim΄s own Compose -- scim -- application I think that when one sets GTK_IM_MODULE for GTK+ applications, one injects a framework between keyboard and xkb. Do you consider the key combination that switches between layouts as part of xkb or xlib Compose? An important issue with all these frameworks is that they make it difficult to have a single interface for the end-user to use irrespective of the language she speaks. Simos Simos -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Simos Xenitellis wrote: O/H Jan Willem Stumpel έγραψε: This also means that when you run scim, the ogonek and horn do not work as breathing signs even if the locale is el_GR.UTF-8, because scim's internal copy of the Compose file is only the common one. In addition, when you try to type Greek Polytonic in OpenOffice.org, it will not work. The reason is that the default Input Method, GTK+ IM does not know yet about these dead keys and does not pass them on. Therefore, when selecting Greek Polytonic in the X Input Method (XIM), for example, using System/Preferences/Keyboard or adding the Keyboard Indicator applet, all in GNOME (such as Ubuntu), you have to do first export GTK_IM_MODULE=xim then run OpenOffice.org The situation is very complicated, because there are many factors which can influence the result. Yes, it is best to set GTK_IM_MODULE=xim (in Debian, you put this in /etc/environment). Then you can enter polytonic Greek everywhere (using the xkb facilities) *if* the /etc/X11/xkb/symbols/pc/gr has been hacked, *and* the locale is any type of UTF-8 (with the possible exception of el_GR.UTF-8), *and* the application has access to a proper font. As far as I could find out, with GTK_IM_MODULE=xim, xkb-type polytonic Greek works (i.e. you can enter ᾆ) in just about all situations; I tested all 12 combinations of 1-3 and A-D below: 1. No input method framework present 2. uim present 3. scim present A. text mode programs in xterm B. mozilla, bluefish C. openoffice D. QT programs With scim, at first I thought that there were program types in which xkb polytonic Greek did not work. But this is (fortunately) not the case. With scim, you must just take care that the keyboard is set separately to English/European (i.e. direct input, through xkb) for each application. Some uim and scim docs recommend using GTK_IM_MODULE=uim or GTK_IM_MODULE=scim. It seems this is not necessary; GTK_IM_MODULE=xim works in all circumstances. But with the original /etc/x11/xkb/symbols/pc/gr, with or without el_GR.UTF-8 locale, polytonic Greek does not work with scim. I now think the keyboard action is as follows: without uim or scim: keyboard -- xkb -- xlib Compose -- application with uim: keyboard -- xkb -- xlib Compose -- uim -- application and with scim: keyboard -- xkb -- scim΄s own Compose -- scim -- application Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
O/H Jan Willem Stumpel έγραψε: Alexandros Diamantidis wrote: [sorry for taking a few days to reply...] * Jan Willem Stumpel [2006-01-18 14:41]: This does not work in my case. Also interchanging the entries (US first, then GR) did not work. I mean you can get the accents, but not the breathing signs. Strangely enough, even calling LANG=el_GR.UTF-8 xterm and then doing things in the new xterm, did not work! I don't understand why. I have the el_GR.UTF-8 locale installed. I really wonder why... I thought if you had a ~/.XCompose file, your locale didn't matter (except if you specifically used it in that file, by doing 'include %L'). Maybe it's not used at all? 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. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Alexandros Diamantidis wrote: [sorry for taking a few days to reply...] * Jan Willem Stumpel [2006-01-18 14:41]: This does not work in my case. Also interchanging the entries (US first, then GR) did not work. I mean you can get the accents, but not the breathing signs. Strangely enough, even calling LANG=el_GR.UTF-8 xterm and then doing things in the new xterm, did not work! I don't understand why. I have the el_GR.UTF-8 locale installed. I really wonder why... I thought if you had a ~/.XCompose file, your locale didn't matter (except if you specifically used it in that file, by doing 'include %L'). Maybe it's not used at all? I think it did not work because I am trying out scim and uim. I must have been running scim at the time. It seems that when scim is running, only its own internal version of the compose file is used. Customisations in ῀/.XCompose do not work at all. With uim, they work. The Greek entry must of course come second in the ῀/.XCompose file. I do not know how uim does it. This also means that when you run scim, the ogonek and horn do not work as breathing signs even if the locale is el_GR.UTF-8, because scim's internal copy of the Compose file is only the common one. Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Alexandros Diamantidis wrote on 2006-01-21 14:38 UTC: 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 -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
[sorry for taking a few days to reply...] * Jan Willem Stumpel [2006-01-18 14:41]: This does not work in my case. Also interchanging the entries (US first, then GR) did not work. I mean you can get the accents, but not the breathing signs. Strangely enough, even calling LANG=el_GR.UTF-8 xterm and then doing things in the new xterm, did not work! I don't understand why. I have the el_GR.UTF-8 locale installed. I really wonder why... I thought if you had a ~/.XCompose file, your locale didn't matter (except if you specifically used it in that file, by doing 'include %L'). Maybe it's not used at all? You could try strace on some X program and see if it is opened. $ strace -o foo xterm $ grep XCompose foo open(/home/adia/.XCompose, O_RDONLY) = 5 to use the xkb facilities). But in the true UTF-8 spirit, we should be able to read/print/enter *anything* from *any* locale, as long as it is a UTF-8 one. I agree with this sentiment... I have also had trouble in this department as well :( So perhaps /etc/X11/xkb/symbols/pc/gr should really be changed to include the UTF-8 'breathing' signs. Yes, but which keysyms should be used? U0313 and U0314, which correspond to U+0313 COMBINING COMMA ABOVE and U+0314 COMBINING REVERSED COMMA ABOVE? The current hack which uses dead_horn and dead_ogonek? Or some new keysyms? * Simos Xenitellis [2006-01-18 14:40]: There are clashes with the reusing of dead_acute, dead_ogonek and so on in many different languages, causing trouble and conflicts when having a single compose file for all languages. I did not see a compelling reason against creating more symbol definitions. Are there any? Well, I don't think there is a problem with reusing dead keys for many languages. Can you think of an example where a dead key followed by a letter key (or some other similar sequence) should produce different results depending on the language? X11 keysyms are supposed, I think, to correspond to keys that really appear on keyboards. But in the case of polytonic Greek, for instance, we never had computer keyboards with breathing signs, did we? So these symbols were left out. You are right, a few more symbols for dead keys would be useful. But I don't know who is responsible for defining new ones - X.Org maybe? Perhaps a bug should be opened about this at bugs.freedesktop.org... -- Alexandros Diamantidis * [EMAIL PROTECTED] -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Alexandros Diamantidis wrote: [sorry for taking a few days to reply...] * Jan Willem Stumpel [2006-01-18 14:41]: This does not work in my case. Also interchanging the entries (US first, then GR) did not work. I mean you can get the accents, but not the breathing signs. Strangely enough, even calling LANG=el_GR.UTF-8 xterm and then doing things in the new xterm, did not work! I don't understand why. I have the el_GR.UTF-8 locale installed. I really wonder why... I thought if you had a ~/.XCompose file, your locale didn't matter (except if you specifically used it in that file, by doing 'include %L'). Maybe it's not used at all? You could try strace on some X program and see if it is opened. I am going to investigate this further. Will reply when I get some results. [..] So perhaps /etc/X11/xkb/symbols/pc/gr should really be changed to include the UTF-8 'breathing' signs. Yes, but which keysyms should be used? U0313 and U0314, which correspond to U+0313 COMBINING COMMA ABOVE and U+0314 COMBINING REVERSED COMMA ABOVE? The current hack which uses dead_horn and dead_ogonek? Or some new keysyms? I think it should be U0313 and U0314, because they are 'official': the Unicode standard (http://www.unicode.org/charts/PDF/U0300.pdf) says that 313 and 314 are used as Greek psili and Greek dasia, and the common Compose file (/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose) already has lots of compose sequences defined which use 313 and 314, like dead_iota dead_tilde U0313 Greek_omega : ᾦ U1FA6 # GREEK SMALL LETTER OMEGA WITH PSILI AND PERISPOMENI AND YPOGEGRAMMENI In fact there are 20 different compose sequences in the file for the ᾦ character alone! Some of them involve 5 keystrokes, using ( and ) to input the 'breathing' signs. I've no idea who put all these definitions in. So polytonic Greek does not really need its own Compose file; everything is already in the common file. Using the common file would mean that polytonic Greek could be input from any (UTF-8) locale. It's just that the /etc/X11/xkb/symbols/pc/gr file has to reflect this. The dead_horn and dead_ogonek can then be left alone (for whatever really horn- and ogonek-using languages want to do with them). Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Alexandros Diamantidis wrote: * Jan Willem Stumpel [2006-01-16 21:52]: All characters, including things like ᾦ, can be made in Greek mode, even in en_GB.UTF-8 locale, if the dead ogonek and horn in the symbols/pc/gr file are replaced [..] Right, that's one way to do it. Another way would be to create a custom personal compose file, which includes both the US and GR Compose files. That way, you can use the dead_horn and dead_ogonek keysyms used in the existing greek keymap, with no need to add the combining Unicode characters you mention. I think if you put the following two lines in ~/.XCompose it will work: include /usr/lib/X11/locale/el_GR.UTF-8/Compose include /usr/lib/X11/locale/en_US.UTF-8/Compose This does not work in my case. Also interchanging the entries (US first, then GR) did not work. I mean you can get the accents, but not the breathing signs. Strangely enough, even calling LANG=el_GR.UTF-8 xterm and then doing things in the new xterm, did not work! I don't understand why. I have the el_GR.UTF-8 locale installed. So it seems that when /etc/X11/xkb/symbols/pc/gr is left as it is, users must change their locale to Greek to use polytonic Greek (if they want to use the xkb facilities). But in the true UTF-8 spirit, we should be able to read/print/enter *anything* from *any* locale, as long as it is a UTF-8 one. So perhaps /etc/X11/xkb/symbols/pc/gr should really be changed to include the UTF-8 'breathing' signs. Then, I suppose, /usr/lib/X11/locale/en_US.UTF-8/Compose could be used for Greek, as it is for so many other languages, including Russian, Hindi, Hebrew, Japanese, and even French ;-). Of course there may very well be some special reason for having a separate Greek UTF-8 Compose file which I do not understand. Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Jan Willem Stumpel wrote:
Alexandros Diamantidis wrote:
When I made an initial try at a polytonic Greek keyboard, I couldn't
find a dead_comma_above and a dead_reversed_comma_above, so I just
(ab)used the first two keysyms that weren't otherwise meaningful on a
Greek keyboard. Subsequent updates to the Greek keyboard layout and
Compose files kept this (perhaps not strictly correct) arrangement.
This xkb stuff is not so easy to understand, but Alexandros' and Jim's
comments helped a lot.
I have so far always used a us_intl keyboard layout in order to enter
accents. This needs the AltGr key to change groups when a key must
produce more than 2 symbols.
But there is also a variant called alt-int of the us keyboard, which
uses extra levels (instead of a new group) to get the same effect. The
AltGr key is used to make the 3rd level. BTW I still don't know what to
press for the 4th level.
From the user's point of view, the behaviour of us_intl and
us(alt-intl) is exactly the same. You get all the accents (dead keys),
the Euro sign, etc. in the same way with both methods. But us(alt-intl)
does not use an extra group. So the groups can be used for other
languages (so you do not need to switch groups, only toggle them).
I found the following combination works nicely:
setxkbmap us(alt-intl),gr(polytonic) \
-option compose:rwin
-option grp:lwin_toggle
With this, left-Windows toggles between us(alt-intl) and polytonic Greek
mode. All characters, including things like ᾦ, can be made in Greek
mode, even in en_GB.UTF-8 locale, if the dead ogonek and horn in the
symbols/pc/gr file are replaced by the utf-8 characters COMBINING COMMA
ABOVE (0x1000313) and COMBINING REVERSED COMMA ABOVE (0x1000314); the
(default?) US Compose file then has lots of entries for combined Greek
characters.
This change would probably break things for Greek users unless the Greek
Compose file is also changed.
Other scripts can be added, e.g us(alt-intl),gr(polytonic),ru.
AFAIK, nowdays Greek uses the en_US.UTF-8 file for dead keys.
Specifically, Greek users of Ubuntu 5.10 have trouble with accents as
the Greek file (el_GR.UTF-8) with the dead key sequences is not
installed any more. By changing the configuration file to point to
en_US.UTF-8, modern Greek works once again.
In addition, the name of the keyboard has reverted back to gr (country
code, as with all other keyboard layouts) compared to el that used to
be the case for the last few years.
GTK+ has its own input method and requires dead keys to be registered,
if you use this GTK+ IM input method. If you notice some GTK+ apps not
working, this is where you investigate. For more on this, see
http://bugzilla.gnome.org/show_bug.cgi?id=321896
X.org has been in transition from the monolithic setup to the modular
one you find now in X.org 7.0. Due to this,
files are being moved around, so you need to know where you submit
patches to.
My understanding is that Greek (modern/ancient-polytonic) keysyms should
come from the generic en_US.UTF-8 and not use a custom one.
The existing en_US.UTF-8 at
http://cvs.freedesktop.org/xorg/xc/nls/Compose/en_US.UTF-8?view=markup
shows that it covers many languages. This file appears to be monolithic
one.
I will have to look closer to find the modular copy somewhere in the
source tree. Any hints?
There are clashes with the reusing of dead_acute, dead_ogonek and so on
in many different languages, causing trouble and conflicts when having a
single compose file for all languages. I did not see a compelling reason
against creating more symbol definitions. Are there any?
At this point that the transition took place, I think patches would get
accepted for a few more symbol definitions (that's their name, right?).
Indeed, keyboard support for X.org is a bit of a mystery as there
appears to be no person that claims some expertise and answers questions.
The keyboard support was created by Sun engineers in the early 90s and
there was this feeling it was over-engineered. Those engineers moved
on to work areas now, some of them still at Sun (irc discussions at #xorg).
Still this setup generates warnings which probably explain why I cannot
reach the 4th level symbols (you see the warnings after closing X), like:
Warning: Type ONE_LEVEL has 1 levels but RALT has 2 symbols
Ignoring extra symbols
Warning: Type THREE_LEVEL has 3 levels but AC11 has 4 symbols
Ignoring extra symbols
Now how to fix this?
See
http://www.xfree86.org/current/XKB-Enhancing4.html
When you specify how many levels your keyboard layout will use, the
table that looks like
key AE02 { [ 2, quotedbl, twosuperior,oneeighth ] };
key AE03 { [ 3, sterling, threesuperior,sterling ] };
should have up to that number of columns.
In your case, somehow, more collumns where found so some had to be ignored.
Simos
--
Linux-UTF8: i18n of Linux on all levels
Archive:
Re: Experiments with classical Greek keyboard input
Alexandros Diamantidis wrote: When I made an initial try at a polytonic Greek keyboard, I couldn't find a dead_comma_above and a dead_reversed_comma_above, so I just (ab)used the first two keysyms that weren't otherwise meaningful on a Greek keyboard. Subsequent updates to the Greek keyboard layout and Compose files kept this (perhaps not strictly correct) arrangement. This xkb stuff is not so easy to understand, but Alexandros' and Jim's comments helped a lot. I have so far always used a us_intl keyboard layout in order to enter accents. This needs the AltGr key to change groups when a key must produce more than 2 symbols. But there is also a variant called alt-int of the us keyboard, which uses extra levels (instead of a new group) to get the same effect. The AltGr key is used to make the 3rd level. BTW I still don't know what to press for the 4th level. From the user's point of view, the behaviour of us_intl and us(alt-intl) is exactly the same. You get all the accents (dead keys), the Euro sign, etc. in the same way with both methods. But us(alt-intl) does not use an extra group. So the groups can be used for other languages (so you do not need to switch groups, only toggle them). I found the following combination works nicely: setxkbmap us(alt-intl),gr(polytonic) \ -option compose:rwin -option grp:lwin_toggle With this, left-Windows toggles between us(alt-intl) and polytonic Greek mode. All characters, including things like ᾦ, can be made in Greek mode, even in en_GB.UTF-8 locale, if the dead ogonek and horn in the symbols/pc/gr file are replaced by the utf-8 characters COMBINING COMMA ABOVE (0x1000313) and COMBINING REVERSED COMMA ABOVE (0x1000314); the (default?) US Compose file then has lots of entries for combined Greek characters. This change would probably break things for Greek users unless the Greek Compose file is also changed. Other scripts can be added, e.g us(alt-intl),gr(polytonic),ru. Still this setup generates warnings which probably explain why I cannot reach the 4th level symbols (you see the warnings after closing X), like: Warning: Type ONE_LEVEL has 1 levels but RALT has 2 symbols Ignoring extra symbols Warning: Type THREE_LEVEL has 3 levels but AC11 has 4 symbols Ignoring extra symbols Now how to fix this? Regards, Jan -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
* Jan Willem Stumpel [2006-01-16 21:52]: This xkb stuff is not so easy to understand, but Alexandros' and Jim's comments helped a lot. I don't understand xkb files very well, either! All characters, including things like ᾦ, can be made in Greek mode, even in en_GB.UTF-8 locale, if the dead ogonek and horn in the symbols/pc/gr file are replaced by the utf-8 characters COMBINING COMMA ABOVE (0x1000313) and COMBINING REVERSED COMMA ABOVE (0x1000314); the (default?) US Compose file then has lots of entries for combined Greek characters. Right, that's one way to do it. Another way would be to create a custom personal compose file, which includes both the US and GR Compose files. That way, you can use the dead_horn and dead_ogonek keysyms used in the existing greek keymap, with no need to add the combining Unicode characters you mention. I think if you put the following two lines in ~/.XCompose it will work: include /usr/lib/X11/locale/el_GR.UTF-8/Compose include /usr/lib/X11/locale/en_US.UTF-8/Compose Still this setup generates warnings which probably explain why I cannot reach the 4th level symbols (you see the warnings after closing X), like: Warning: Type THREE_LEVEL has 3 levels but AC11 has 4 symbols Ignoring extra symbols Now how to fix this? I'm sorry, I don't know about this... -- Alexandros Diamantidis * [EMAIL PROTECTED] -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
Jan == Jan Willem Stumpel [EMAIL PROTECTED] writes: Jan setxkbmap gr(polytonic)+level3(lwin_switch) Jan It should be possible to change from the default keyboard to classical Jan Greek (and back) by some hotkey instead of a setxkbmap command. You can accomplish that part by specifying multiple keymaps on the setxkbmap line. I use this command for my standard setup: setxkbmap -layout us,el,ru,il -variant ,,phonetic,phonetic \ -option ctrl:nocaps -option grp_led:scroll \ -option compose:menu -option grp:ctrls_toggle \ -option altwin:super_win that gives me four layouts (the max that can be set at any given time) which I can scroll through by pressing both control keys together ( that is the grp:ctrls_toggle option). When I am in anything other than the us map the scroll lock led is on (the grp_led:scroll option). I also have the cap lock key be a control key and the menu key a compose key. Or at least I used to. el no longer works for me. (The goal was to cover Latin/Greek/Cyrillic; I thru il in as well just cause I could) I also lack a good key to waste as a level3 key. (The laptop lacks a right win key¹ and I use the left win key for icewm.) -JimC ¹ In fact the Fn key plus the left win key generates the keycode of the right win key, but it cannot be used as a modifyier because non-Fn-special keys are ignored when holding down Fn -- James H. Cloos, Jr. [EMAIL PROTECTED] -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: Experiments with classical Greek keyboard input
* Jan Willem Stumpel [2006-01-14 16:46]:
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 * [EMAIL PROTECTED]
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
