[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Experiments with classical Greek keyboard input

O/H Jan Willem Stumpel έγραψε:
Simos Xenitellis wrote:

You can have a look at this document, http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it
should be feasible to discern the combinations proposed. For example,
"Νεκρό πλήκτρο" is "Dead key" in the list. If there are queries, feel
free to refer to me.

Very interesting. Is this a proposal, or has it been implemented?
According to Babelfish, you say "Your distribution of Linux that
has been published after October 2005 should include the renewed system
that we describe here." Mine does not, but I don't trust the Babelfish
translation..
The referenced document is indeed a proposal.
You are correct about October 2005. Several distributions were released in October (Ubuntu, OpenSUSE) so the plan was to have the changes upstream by the end of the summer so that they move to the new distributions as they appear.
However, this plan did not work out and we still did not submit these changes.
Konstantinos Pistiolis is working on this subject. 
As far as I can see, it would not be difficult to implement it. Nothing
would have to be changed in the binaries, only in the xkb and Compose
files.

I noticed you only want to use 'two level' keys (normal and shift), not
using AltGr. Is this some kind of standard? (e.g. Greek national
standard, or some other kind of standard)? The present pc/gr file in xkb
uses 'three level' keys.
As far as I know there is no national standard for Greek polytonic. Windows XP support Greek polytonic,
however, there is an inherent disadvantage that you cannot stuck more than one dead key; due to this
quite a lot of keys have to be used as dead keys. In addition, if a character accepts more than one diacritic,
then you need three dead keys to cover all the cases (diacritic A, diacritic B, diacritic A+B).

Regarding the usage of AltGr. There have been quite a few discussions on whether to use or not. I do not have the full details at my disposal.
Kostas, would you like to chip in for this?
BTW I suppose when you say that tonos/oxia is on the ; key, you mean the
key which is ; on US keyboards, not the key which is ; on Greek keyboards?
Indeed, ; it is the physical key according to the US keyboard.
The proposal document does not include a specific dead key to produce oxia. In the Windows XP layout there is such a dead key,
in an uncomfortable location however, for those end-users who would like to use it.
The "Compose" file should be broken in smaller files per script
rather than having a big monolithic file.

What advantage would this bring? If we have many small pieces of the
Compose file, how is the user (or the system) supposed to decide when to
use which piece? Wouldn't this create another configuration problem?
The configuration mechanism of Xorg would shield the end-user from this complexity. I am referring to the needs of the developers.
For example, suppose a lesser known language wants to make an installable package that adds writing support. The way this could be done is by dropping (adding) the appropriate files in the appropriate directory. Otherwise, there would be need to patch the monolithic file.
In addition, the Polytonic section in the Compose file is suitable to be auto-generated from a script as the multiple diacritics on vowels bring up
combinations.
UTF-8 allows using one system for all languages and scripts, without
changing locales. There is only one, IMHO unavoidable, but small,
disadvantage: some files (like fonts, and the Compose file) tend to
become rather big. But memory and disk space are not as expensive as
they used to be. And the user does not notice anything of this. She just
thinks: wow! I can input any language anywhere, at any time!
As I mention above, the splitting of the files would be an advantage for the developers.
The end-user would only see a GUI configuration tool. No setxkbmap or editing of xorg.conf.
There is increasing interest in updating this area of Xorg (http://community.livejournal.com/xkbconfig/) and I hope it gets done
soon.

Hmm.. "xkb" and "Compose" are two completely different mechanisms. One
is input to the other. People often complain about xkb being
'mysterious' or 'arcane'. Since xfree86 4.3 and x.org came around, it
isn't anymore. It just lacks user-level documentation. Recently, thanks
to this list, I have come close enough to enlightenment to attempt a
user-level description on my utf-8 page, sections 6.1 and 6.2
(http://www.jw-stumpel.nl/stestu).
Thanks for this.
We need to put effort so that gswitchit (Keyboard Indicator applet in GNOME) gets more and more advanced and ubiquitous.
The plan is for gswitchit to be used for KDE as well.
This is the proper direction so end-users are happy that their settings just work.

Simos


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