Dear All, This e-mail appears not to have made it to the list (Kostas is probably not subscribed to the list), therefore I forward it as there are some interesting information here.
Simos -------- Forwarded Message -------- From: Πιστιόλης Κωνσταντίνος <pistiolis στο ts τελεία sch τελεία gr> To: Simos Xenitellis <simos74 στο gmx τελεία net>, linux-utf8@nl.linux.org Subject: Re: Experiments with classical Greek keyboard input Date: Tue, 31 Jan 2006 22:11:05 +0200 Την Mon, 30 Jan 2006 19:05:26 +0000,ο(η) Simos Xenitellis <[EMAIL PROTECTED]> έγραψε/wrote: > O/H Jan Willem Stumpel έγραψε: >> Simos Xenitellis wrote: >> >> >>> You can have a look at this document, >>> http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it >>> should be feasible to discern the combinations proposed. For example, >>> "Νεκρό πλήκτρο" is "Dead key" in the list. If there are queries, feel >>> free to refer to me. >>> >> >> Very interesting. Is this a proposal, or has it been implemented? >> According to Babelfish, you say "Your distribution of Linux that >> has been published after October 2005 should include the renewed system >> that we describe here." Mine does not, but I don't trust the Babelfish >> translation.. >> > The referenced document is indeed a proposal. > You are correct about October 2005. Several distributions were released > in October (Ubuntu, OpenSUSE) so the plan was to have the changes > upstream by the end of the summer so that they move to the new > distributions as they appear. > However, this plan did not work out and we still did not submit these > changes. > Konstantinos Pistiolis is working on this subject. >> As far as I can see, it would not be difficult to implement it. Nothing >> would have to be changed in the binaries, only in the xkb and Compose >> files. >> >> I noticed you only want to use 'two level' keys (normal and shift), not >> using AltGr. Is this some kind of standard? (e.g. Greek national >> standard, or some other kind of standard)? The present pc/gr file in xkb >> uses 'three level' keys. >> > As far as I know there is no national standard for Greek polytonic. > Windows XP support Greek polytonic, > however, there is an inherent disadvantage that you cannot stuck more > than one dead key; due to this > quite a lot of keys have to be used as dead keys. In addition, if a > character accepts more than one diacritic, > then you need three dead keys to cover all the cases (diacritic A, > diacritic B, diacritic A+B). If it could be any, it is the old typewriter's standard (computers were not used for text proccessing at the time polytonic was removed from modern greek), but it didn't cover the full polytonic because it didn't have vareia (grave), makron, and vrahy. It was rather used for modern greek than ancient greek. This keymap defines a dead key for every combination, and is more or less followed by the windows XP, using up to 16 or more dead keys! However, the proposed keymap uses the same principles and only needs 9 dead keys > > Regarding the usage of AltGr. There have been quite a few discussions on > whether to use or not. I do not have the full details at my disposal. > Kostas, would you like to chip in for this? the accents, dead iota and the breathing marks shouldn't use it: 1. most of the dead keys are too often used to be put in third level (except for makron, vrahy). Each symbol is aproximately used in 1 every 3-5 words! 2. the altGr chooser was not used in the old typewriter's standard. In fact, all symbols (except vareia=grave) have a position in the old typewriter's standard which is preserved in the proposed keymap. About makron and vrahy, I have proposed putting them in ] and } and not as an altGr combination, as the openning [ and { are already occupied as dead keys (~ and iota subscript in accordance to the typewriter "standard"). The concept is that it wouldn't be bad to lose the closing brace, if the openning brace is lost too, and it would save the altGr+dead_key combinations for future use (see below). The other symbols (ancient greek numbers) are also needed in modern (monotonic) greek, and could be added either as altGr combinations, or composed with dead acute, or even in both ways. eg: altGr + sigma : numeric stigma or dead tonos + sigma : numeric stigma I don't know if the latter odd combination would produce conflicts in an international Compose file, but this idea was used in the past in greek keyboard, in the following combinations: dead_tonos + . : above (middle) dot dead_tonos + < : « dead_tonos + > : » I believe that the Compose should actually be a part of the keymap; not the locale. Dead keys are very good sticky third level choosers, for languages that use them. The present pc/gr file uses altgr for the euro symbol, the middle dot and the «» symbols, along with the Compose combinations and I suggest the same (duality) for all new symbols Another idea is to use the same kind of rules to increase the usability of the polytonic keyboard for writing 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 switch keyboards to write the []{}'"and/ symbols. For example: key [ is proposed to be pesispomeni (~), so dead_[ + dead_[ : [ and/or altGr + dead_[ : [ Again, the first combination could result in conflicts, in an international compose, so probably is is only applicable in the personal .Compose files of the users that need them. >> 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. 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. However, the use of the dublicate accented letters is stongly discouraged, so the keymap would normally produce the letters with tonos. The combination altGr-dead_tonos + vowel is proposed to produce the letter with accent, in case someone needs it. The default symbol produced by the keymap will be the dead_acute and for the polytonic extension I have used the dead_doubleacute (has no reasonable meaning though, but so has the distintion between acute and tonos) >> >>> 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? >> It could become a part of the keymap. As I said, a dead key makes an excelent third level chooser which is sticky. Yet, it seems that xkb is not meant to work like that. > 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). I have a question. It is mentioned that it's a bug to use dead_horn and dead_ogonek and that "combining comma above" 0x0313 and "combining reversed comma above" 0x0314 should be used instead. Wouldn't it be best to ask for a dead_commaabove (or dead_psili) and a dead_reversedcommaabove (dead_daseia) to be added to the xkb binaries? When the polytonic variant was first created, it was thought that it doesn't matter which dead_XXX symbol would be used. Is this true? >> > 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/
