Re: Experiments with classical Greek keyboard input

[Danilo Segan]

Hi Jan,

Today at 13:02, Jan Willem Stumpel wrote:

>> key.type = "THREE_LEVEL";
>> 
>> key  {[], [ dead_tilde, dead_diaeresis, dead_macron ]}; 
>> key  {[], [ dead_iota,  VoidSymbol, dead_breve  ]};
>> 
>> key  {[], [ dead_acute,   dead_horn   ]}; 
>> key  {[], [ dead_grave,   dead_ogonek ]};
>> 
>> };
>> 
>> I assume the list of keysyms captures the shifted state of the
>> key i.e.  is on the semi-colon key and 
>> 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

[Joe Schaffner]

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  {[], [ dead_tilde, dead_diaeresis, dead_macron ]};
> key  {[], [ dead_iota,  VoidSymbol, dead_breve  ]};
>
> key  {[], [ dead_acute,   dead_horn   ]};
> key  {[], [ dead_grave,   dead_ogonek ]};
>
> };
>
> I assume the list of keysyms captures the shifted state of the
> key i.e.  is on the semi-colon key and 
> 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.

>  is on the single-quote key and  is on
> the double-quote key.
>
> That's a pretty good layout. I like it.
>
> Why not name these keysyms  and ?

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

[Simos Xenitellis]

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  {[], [ dead_tilde, dead_diaeresis, dead_macron ]}; 
key  {[], [ dead_iota,  VoidSymbol, dead_breve  ]};


key  {[], [ dead_acute,   dead_horn   ]}; 
key  {[], [ dead_grave,   dead_ogonek ]};


};

I assume the list of keysyms captures the shifted state of the
key i.e.  is on the semi-colon key and 
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.

  

 is on the single-quote key and  is on
the double-quote key.

That's a pretty good layout. I like it.

Why not name these keysyms  and ?



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  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
http://bugzilla.gnome.org/show_bug.cgi?id=321896

Simos


--
Linux-UTF8:   i18n of 

Re: Experiments with classical Greek keyboard input

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

> key.type = "THREE_LEVEL";
> 
> key  {[], [ dead_tilde, dead_diaeresis, dead_macron ]}; 
> key  {[], [ dead_iota,  VoidSymbol, dead_breve  ]};
> 
> key  {[], [ dead_acute,   dead_horn   ]}; 
> key  {[], [ dead_grave,   dead_ogonek ]};
> 
> };
> 
> I assume the list of keysyms captures the shifted state of the
> key i.e.  is on the semi-colon key and 
> 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.

>  is on the single-quote key and  is on
> the double-quote key.
> 
> That's a pretty good layout. I like it.
> 
> Why not name these keysyms  and ?

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

[Danilo Segan]

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

[Vasilis Vasaitis]

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

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

..[snip]..

>  is on the semi-colon key and  is on the same
> key, shifted, the colon key.
> 
>  is on the single-quote key and  is on the
> double-quote key.
> 
> That's a pretty good layout. I like it.
> 
> Why not name these keysyms  and ?

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

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  { [], [  dead_tilde, dead_diaeresis, dead_macron ] };
   key  { [], [  dead_iota,  VoidSymbol, dead_breve  ] };

   key  { [], [  dead_acute, dead_horn   ] };
   key  { [], [  dead_grave, dead_ogonek ] };

};

I assume the list of keysyms captures the shifted state of the key i.e.

 is on the semi-colon key and  is on the same
key, shifted, the colon key.

 is on the single-quote key and  is on the
double-quote key.

That's a pretty good layout. I like it.

Why not name these keysyms  and ?

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

   : "αΌ€"  U1f00
: "αΌ€"  U1f00
  : "ἁ"  U1f01
  : "ἁ"  U1f01
: "αΌ‚"  U1f02
: "αΌ‚"  U1f02
: "αΌ‚"  U1f02
: "αΌ‚"  U1f02
   : "αΌƒ"  U1f03
   : "αΌƒ"  U1f03
  : "αΌƒ"  U1f03
  : "αΌƒ"  U1f03
   : "αΌ„"  U1f04
   : "αΌ„"  U1f04
: "αΌ„"  U1f04
: "αΌ„"  U1f04
  : "αΌ…"  U1f05
  : "αΌ…"  U1f05

 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  is intended to function as psili and
the  as the dasia.

Are the names of the keysyms important?

If not, why not call them  and ?

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

(e)~ιμεν)

The  is an undefined tag which the 

Re: Experiments with classical Greek keyboard input

[Joe Schaffner]

Thanks Jan,

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

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

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

> 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

(e)~ιμεν)

The  is an undefined tag which the browser conveniently throws
away, respecting the spacing, like a  or an .

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
>[   [   dead_tilde   α   ᾶ  (perispomeni)
> shift  {   {   dead_diaeresis   υ (=y)  ϋ  (dialytika)
> altgr  «   dead_macron  α   ᾱ  (macron)
>
>]   ]   dead_iotaα   ᾳ  (iota subscript)
> shift  }   }   VoidSymbol   α   α  (does nothing)
> altgr  »   dead_breve   α   ᾰ  (breve)
>
>;   ´   dead_acute   α   ά  (tonos/oxia)
> shift  :   ¨   dead_hornα   ἀ  (psili)
> altgr  ΅   [not defined]α   α  (does nothing)
>
>'   '   dead_grave   α   ὰ  (varia)
> shift  "   "   dead_ogonek  α   ἁ  (dasia)
> altgr  [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 (:) + 

Re: Experiments with classical Greek keyboard input

[Jan Willem Stumpel]

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
   [   [   dead_tilde   α   ᾶ  (perispomeni)
shift  {   {   dead_diaeresis   υ (=y)  ϋ  (dialytika)
altgr  «   dead_macron  α   ᾱ  (macron)

   ]   ]   dead_iotaα   ᾳ  (iota subscript)
shift  }   }   VoidSymbol   α   α  (does nothing)
altgr  »   dead_breve   α   ᾰ  (breve)

   ;   ´   dead_acute   α   ά  (tonos/oxia)
shift  :   ¨   dead_hornα   ἀ  (psili)
altgr  ΅   [not defined]α   α  (does nothing)

   '   '   dead_grave   α   ὰ  (varia)
shift  "   "   dead_ogonek  α   ἁ  (dasia)
altgr  [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  { [   dead_tilde,   dead_iota   ] };
key  { [   dead_macron,  dead_breve  ] };
key  { [   dead_acute,   dead_diaeresis  ] };
key  { [   0x1000313,0x1000314   ] };
key  { [   dead_grave,   question] };
};

This of course makes the / key "dead". The AltGr key is no longer
used. The Compose file does not have to be changed, but if the
other characters mentioned in the 'proposal' would have to be
entered (koppa, digamma, etc.) a few lines should be added to it.

Would this be easier to use than the present xkb system? I don't
know.

Thomas Wolff suggests using 'unused' keys like F6 for oxia, etc.
Again, I think that usability is the most important criterion for
the choice. To type Greek you would have to switch your keyboard
from Latin to Greek anyway. In the 'Greek' state all keys can get
a different function. Ideally the 'Greek' keys would do similar
things to 'Latin' keys (i.e. dead tilde would become dead
perispomeni, dead acute would become dead tonos, perhaps alt-i
could become dead_iota, etc.). But there does not seem to be a
special need to look for 'unused' keys, because in 'Greek' mode,
keys can be re-used.

Finally, would the system which is available on Windows XP
(http://www.microsoft.com/globaldev/perspectives/polytonic.mspx)
be better f

Re: Experiments with classical Greek keyboard input

[Joe Schaffner]

Hello Thomas,

It looks like we're all looking for non-standard ways to capture
polytonic Greek in Linux. This must mean no keymap exists. Given one
hundred years I'll figure out xkb and write one.

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 ?
>
> 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
>
>: "ἀ"  U1f00
> : "ἀ"  U1f00
>   : "ἁ"  U1f01
>   : "ἁ"  U1f01
> : "ἂ"  U1f02
> : "ἂ"  U1f02
> : "ἂ"  U1f02
> : "ἂ"  U1f02
>: "ἃ"  U1f03
>: "ἃ"  U1f03
>   : "ἃ"  U1f03
>   : "ἃ"  U1f03
>: "ἄ"  U1f04
> ...
>   

Re: Experiments with classical Greek keyboard input

[Thomas Wolff]

Πιστιόλης Κωνσταντίνος 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

[Joe Schaffner]

Hi All,

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

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

I am using SuSE 9.2 and Gnome.

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 ?

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

   : "ἀ"  U1f00
: "ἀ"  U1f00
  : "ἁ"  U1f01
  : "ἁ"  U1f01
: "ἂ"  U1f02
: "ἂ"  U1f02
: "ἂ"  U1f02
: "ἂ"  U1f02
   : "ἃ"  U1f03
   : "ἃ"  U1f03
  : "ἃ"  U1f03
  : "ἃ"  U1f03
   : "ἄ"  U1f04
...
 : "ᾅ"  U1f85
   : "ᾅ"  U1f85
   : "ᾅ"  U1f85
   : "ᾅ"  U1f85
   : "ᾅ"  U1f85
   : "ᾅ"  U1f85
   : "ᾅ"  U1f85
  : "ᾆ"  U1f86
  : "ᾆ"  U1f86
  : "ᾆ"  U1f86
  : "ᾆ"  U1f86
  : "ᾆ"  U1f86
  : "ᾆ"  U1f86
 : "ᾆ"  U1f86
 : "ᾆ"  U1f86
 : "ᾆ"  U1f86

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

What are these symbols, , , ,
, etc. and how are they mapped to real keys?

Anybody care to discuss how xkb works?

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

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

Where do I get started?

===
Unicode Fonts

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

Too clever for its own good.

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

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

Which brings up the question:

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

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

Any font designers out there?

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

On 2/3/06, Jan Willem S

Re: Experiments with classical Greek keyboard input

[Jan Willem Stumpel]

Πιστιόλης Κωνσταντίνος wrote:
> Την Fri, 10 Feb 2006 20:14:16 +0100,ο(η) Jan Willem Stumpel 
> <[EMAIL PROTECTED]> έγραψε/wrote:

>> 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'. [..]

I got the impression that typographical fashion in Greece has changed from
http://ptolemy.tlg.uci.edu/~opoudjis/unicode/unicode_gkbkgd.html#oxia :

  It would be an exaggeration to say that the erstwhile dots and
  wedges have completely died out — especially as they have been
  given a new lease of life by font developers' sluggishness.
  However, the non-acute tonos seems to have become restricted
  to display type or otherwise marked circumstances; quality
  typography uses the acute.

This suggested some (recent?) change in typographical fashion to me.

Anyway, what I wanted to say is that the FreeSerif font now, in its very
latest version (Debian package ttf-freefont_20060126-0.1_all.deb),
displays alpha-oxia (0x3ac) the same as alpha-acute (0x1f7). So there is
some progress on the font side. The direct result is that on the
keyboard side, the need for a separate acute and tonos has become less
"acute"!

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

[Jan Willem Stumpel]

Πιστιόλης Κωνσταντίνος 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 12:06:07 +0100,ο(η) Jan Willem Stumpel  
<[EMAIL PROTECTED]> έγραψε/wrote:



Πιστιόλης Κωνσταντίνος wrote:

Την Mon, 06 Feb 2006 21:58:13 +0100,ο(η) Jan Willem Stumpel
<[EMAIL PROTECTED]> έγραψε/wrote:



In ancient greek and modern "katharevousa" (a formal archaic greek)
there were three accents. [..]


Thanks very much for this explanation. I put a digest of it on my
‘user-level’ utf-8 page.

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 propably not viewed correctly if someone
types using the gr(polytonic) keymap with el_GR.UTF-8 locale

Check http://ptolemy.tlg.uci.edu/~opoudjis/unicode/unicode_gkbkgd.html#oxia
to see which fonts define different symbols

Kostas

--
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:
> Την Mon, 06 Feb 2006 21:58:13 +0100,ο(η) Jan Willem Stumpel  
> <[EMAIL PROTECTED]> έγραψε/wrote:

> In ancient greek and modern "katharevousa" (a formal archaic greek)
> there were three accents. [..]

Thanks very much for this explanation. I put a digest of it on my
‘user-level’ utf-8 page.

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

[Rich Felker]

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

[Πιστιόλης Κωνσταντίνος]

Την 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 awar

Re: Experiments with classical Greek keyboard input

[Simos Xenitellis]

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

[Jan Willem Stumpel]

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

[Πιστιόλης Κωνσταντίνος]

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

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, because 

Re: Experiments with classical Greek keyboard input

[Alexandros Diamantidis]

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: Πιστιόλης Κωνσταντίνος 
> 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 a

[Fwd: Re: Experiments with classical Greek keyboard input]

[Simos Xenitellis]

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: Πιστιόλης Κωνσταντίνος 
To: Simos Xenitellis ,
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. De

Re: Experiments with classical Greek keyboard input

[Jan Willem Stumpel]

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/

Re: Experiments with classical Greek keyboard input

[Joe Schaffner]

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

Re: Experiments with classical Greek keyboard input

[Simos Xenitellis]

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

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

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

[Simos Xenitellis]

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



  

   : "ά" 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  
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

[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

>: "ά" 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  
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

[Jan Willem Stumpel]

Simos Xenitellis wrote:
> 
> There is some work to update the settings for Greek Polytonic. Two
> thoughts here are: 1. Place ¨ (dyalytika) on the same dead key as
> with modern Greek. 2. There is no way to type oxia; tonos and oxia
> are considered equivalent in Unicode 3.0+ and tonos is preferred.
> However, if users would rather have an oxia option, I feel we should
> provide it.

I'll reply to your other points later when I have digested them (there
is a lot of information there) but your message made me realise only now
(sorry) that the tonos and oxia are really different. I thought it was
strange that the "acutus" was straight up instead of pointing to the
right. I thought this was a font problem. But it is not, because many
fonts already have different glyphs for Unicode ά (03AC, small alpha
with tonos) and ά (1F71, small alpha with oxia). It is a keyboard
problem. The keyboard does not distinguish between the two. Simple alpha
with acute accent becomes alpha with tonos. But if there are more
accents in the combination, the acute accent becomes oxia.

Proposal (I tested this, with the small alpha only, and it seems to
work):

-- Greek (modern and ancient) should use the common (international)
   Compose file.
-- The international Compose file should have different definitions for
   letters with simple tonos and letters with simple oxia. At present,
   the Compose file has

   : "ά" U03AC # GREEK SMALL LETTER ALPHA
WITH TONOS

   (and grep "GREEK SMALL LETTER ALPHA" Compose|grep -v AND|grep OXIA
   gives nothing!)

   To distinguish between tonos and oxia, on the xkb side, something
   should be chosen to represent the tonos.

   Perhaps we could just use "apostrophe", but in my test I abused the
   old "dead_horn", just like Alexandros did, but this time for modern
   Greek:

   : "ά" U03AC # GREEK SMALL LETTER ALPHA
WITH TONOS

  : "ά" U1F71 # GREEK SMALL LETTER ALPHA
WITH OXIA

   (For the time being, I put these things in ~/.XCompose, but they
   should really be in the common file).

-- Then in xkb (/etc/X11/xkb/symbols/pc/gr) the AC11 key could be
   defined as "dead_horn" in the default (modern Greek) section and as
   "dead_acute" in the polytonic section.

"Modern Greeks" could then use setxkbmap gr (or the corresponding
definition in /etc/X11/xorg.conf) as usual. People who want to type
ancient Greek would use setxkbmap "gr(polytonic)", and would get oxia
instead of tonos for the same key combination. This of course assumes
that ancient Greek does not use the tonos, only the oxia. And there may
be other snags that I did not think of..

Regards, Jan



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

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


--
L

Re: Experiments with classical Greek keyboard input

[Jan Willem Stumpel]

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

[Simos Xenitellis]

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

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


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

[Markus Kuhn]

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

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

: "ᾦ"
 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]

[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

[Simos Xenitellis]

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  has 2 symbols
   Ignoring extra symbols
Warning: Type "THREE_LEVEL" has 3 levels but  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   { [ 2,   quotedbl,  twosuperior,oneeighth ] };
 key   { [ 3,   sterling, threesuperior,sterling ] };

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

Simos


--
Linux-UTF8:   i18n of Linux on all levels
Archive:  http://mai

Re: Experiments with classical Greek keyboard input

[Jan Willem Stumpel]

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

[Alexandros Diamantidis]

* 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  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 Willem Stumpel]

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  has 2 symbols
   Ignoring extra symbols
Warning: Type "THREE_LEVEL" has 3 levels but  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

[Alexandros Diamantidis]

* 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  { [dead_acute,   dead_horn ] };
> key  { [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/

Re: Experiments with classical Greek keyboard input

[James Cloos]

> "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/