On Thu, 2006-01-26 at 20:29 +0100, Jan Willem Stumpel wrote: > Simos Xenitellis wrote: > > O/H Jan Willem Stumpel έγραψε: > > >> This also means that when you run scim, the ogonek and horn > >> do not work as breathing signs even if the locale is > >> el_GR.UTF-8, because scim's internal copy of the Compose file > >> is only the "common" one. > > > > In addition, when you try to type Greek Polytonic in > > OpenOffice.org, it will not work. The reason is that the > > default Input Method, GTK+ IM does not know yet about these > > dead keys and does not pass them on. Therefore, when selecting > > Greek Polytonic in the X Input Method (XIM), for example, using > > System/Preferences/Keyboard or adding the Keyboard Indicator > > applet, all in GNOME (such as Ubuntu), you have to do first > > > > export GTK_IM_MODULE=xim then run OpenOffice.org > > The situation is very complicated, because there are many factors > which can influence the result. > > Yes, it is best to set GTK_IM_MODULE=xim (in Debian, you put this > in /etc/environment). Then you can enter polytonic Greek > everywhere (using the xkb facilities) *if* the > /etc/X11/xkb/symbols/pc/gr has been hacked, *and* the locale is > any type of UTF-8 (with the possible exception of el_GR.UTF-8), > *and* the application has access to a proper font.
GTK+ 2.x based applications that are linked to pango are in the happy situation where glyphs from different fonts are grouped together to fill in the Unicode table. Therefore, if you have at least one font in your system that has Greek Polytonic support, this will be used for your GTK+ application. For issues like font preference for this, the file /etc/fonts/fonts.conf (fontconfig) is used which can dictate where to choose from first. OpenOffice.org appears to do its internal choosing of fonts (does not obey fontconfig), which causes some pain for Greek. Specifically, if the selected font in OOo does not have Greek glyphs AND your distribution has Asian support, Greek glyphs will be chosen from Asian fonts. > As far as I could find out, with GTK_IM_MODULE=xim, > xkb-type polytonic Greek works (i.e. you can enter ᾆ) in just > about all situations; I tested all 12 combinations of 1-3 and A-D > below: > > 1. No input method framework present > 2. uim present > 3. scim present > > A. text mode programs in xterm AFAIK, xterm uses XIM by default. > B. mozilla, bluefish > C. openoffice Both B and C are based on GTK+, so GTK_IM_MODULE to xim simply directs them use the standard X Input Method. Any scim/uim/iiimf present cannot affect these applications when GTK_IM_MODULE is set to xim. > D. QT programs QT uses XIM directly, so it is not affected by setting GTK_IM_MODULE. The QT folks are actually trying to make a QT Input Method, similar to GTK+ IM. > > With scim, at first I thought that there were program types in > which xkb polytonic Greek did not work. But this is (fortunately) > not the case. With scim, you must just take care that the keyboard > is set separately to "English/European" (i.e. direct input, > through xkb) for each application. Indeed, that should be the case. I did not find Greek Polytonic in either scim or uim, or even iiimf. There was only modern Greek. > Some uim and scim docs recommend using GTK_IM_MODULE=uim or > GTK_IM_MODULE=scim. It seems this is not necessary; > GTK_IM_MODULE=xim works in all circumstances. By setting GTK_IM_MODULE to either xim, uim, scim or iiim, you enable them for GTK+ applications. When the variable was set to "xim", any of the other frameworks where not active for these GTK+ applications. > But with the original /etc/x11/xkb/symbols/pc/gr, with or without > el_GR.UTF-8 locale, polytonic Greek does not work with scim. I now Which distribution are you using? What are the changes that you have for the "gr" file that makes it work for you? The latest is http://cvs.freedesktop.org/xlibs/xkbdesc/symbols/gr?view=markup There is some work to update the settings for Greek Polytonic. Two thoughts here are: 1. Place ¨ (dyalytika) on the same dead key as with modern Greek. 2. There is no way to type oxia; tonos and oxia are considered equivalent in Unicode 3.0+ and tonos is preferred. However, if users would rather have an oxia option, I feel we should provide it. > think the keyboard action is as follows: > > without uim or scim: > > keyboard --> xkb --> xlib Compose --> application > > with uim: > > keyboard --> xkb --> xlib Compose --> uim --> application > > and with scim: > > keyboard --> xkb --> scim΄s own Compose --> scim --> application I think that when one sets GTK_IM_MODULE for GTK+ applications, one injects a framework between keyboard and "xkb". Do you consider the key combination that switches between layouts as part of xkb or xlib Compose? An important issue with all these frameworks is that they make it difficult to have a single interface for the end-user to use irrespective of the language she speaks. Simos Simos -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
