You know, there really should be a way to create a keyboard layout on
X11 compatible with the Windows XP / typewriter one. Is this currently
possible? To do this, either many more "generic" dead keys are needed,
or a way to have a single keypress produce many keysyms, for use in a
compose sequence.
For reference, here's the Windows XP way to produce polytonic Greek
characters:
http://support.microsoft.com/default.aspx?scid=kb;el;GR750052
According to the table there, the dead keys used are [ ] - = | \ / ; '
combined with Shift, Alt, and AltGr. In total, 27 different "virtual"
dead keys... Not an easy system to learn, but I think anyone
who's learned it, should be able to keep using it under X11.
Is it possible to implement this with the current xkb plus simple
Compose-file infrastructure? Or is it only possible with complex
input method software?
I thought of this too, but I don't see an easy way to do this with xkb.
Anyway, the idea of using combinations of dead keys instead of a dead
key for every mark combination was used before in macintosh and as
long as the single symbol dead keys have the same position with the
old keymap... perhaps it is enough for now.
It is propably better to implement this legacy keyboard map with
some complex input method at a later time, instead of messing up xkb now.
...
I don't know if the latter odd combination would produce conflicts in
an international Compose file, but this idea was used in the past in
greek keyboard, in the following combinations:
dead_tonos + . : above (middle) dot
dead_tonos + < : «
dead_tonos + > : »
I don't think there are any conflicts, and these combinations are very
nice from a usability point of view: you don't have to memorize obscure
AltGr combinations, just to remember that puting an accent on a
character that doesn't take one produces a "special" (less common)
character that looks similart. The three combinations listed above were
also used in some old MS-DOS keyboard drivers.
yes, it is a very good idea, but in an international compose file
it would be a conflict if greek keymap wanted to use:
dead_acute + . : above (middle) dot
and some other language's keymap uses:
dead_acute + . : <degree symbol>
The dead_XXX definitions are accessible for all languages
(and this is correct). The correct way to do this would be to have xkb
defining a different Compose file for every keymap
...
Another idea is to use the same kind of rules to increase the usability
of the polytonic keyboard for writing tenchical texts:
To have a double press of a dead_key and the altGr + dead_key
to produce the "lost" symbol so that the user wouldn't have to
...
I agree with this.
But:
1. it could cause the same kind of conflicts as mentioned above
2. in the proposed keymap dead_horn is placed in ' so we want the rule
dead_horn dead_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 text searching should be
insensitive to unicode-equivalent characters, but this is
the reality, so we must produce these characters too.
Kostas
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
