Hello, There are some issues related to a symbols composing and Compose files that were mentioned here (and in Bugzilla) during last monthes. The choice of Compose file depends on the current locale and is very unflexible. The files are placed far from other keyboard-related files (many people even can't find them). There is not any way to customize them (e.g. per-user compose file).
I'd like to offer some changes in that mechanism that solve at least a part of problems. First of all I should remind that whereas in many systems a composing mechanism (dealing with dead_keys and/or Mylti_key like prefix) is a part of keyboard driver and composing rules are a part of keyboard maps, in X Window it has no relations to XKB and its files. Moreover that composing should work if Xserver and/or Xlib are built without XKB. The most unpleasant consequence is that Xlib use different ways to get Compose files and other keyboard-related data. A keyboard map is kept on a server and Xlib retrives it using XKB protocol (or some core protocol requests) but Compose file is always read localy from client machine filesystem. An ideal solution would be to integrate compose rules into XKB (or core protocols) maps but it needs changes in the protocol or a making new extension. My proposals touch existent files (and compose subsytem) only. Locale independence. In existent files a compose rule consists of two parts. A 'left side' part is a sequence of keysym and a right part (the result of composing) is a pair of a mylti_byte string and a keysym. Both members ot that pair are independed. Each of them can be omited and the compose subsystem doesn't check any matching between them and doesn't figure out any one of them from other. On the one hand it provides a flexibility. The multy_byte string may have no corrsponded keysym and even be some arbitrary string (a word or even a sentence). On the other hand it causes problem when user changes a locale. The string there is exactly what XmbLookupString has to return (without any changes). Hence for non-ASCII symbols it should be different for C and UTF-8 locales. (Hans Deragon wrote here about the problem he faced: when he changed a locale to Unicode one, some sequences appeared changed because Xlib used another Compose file.) It can be fixed easy. If the result of a compose rule ia a keysym only Xlib has to convert it to a string according to the current locale in the way used for usual key press/release events. It this case one compose files can be used for different locales and depends on a keybord map only. Customization. I added to Compose file an 'include' instriction. It allows to compose Compose file :-) from some files and add small corrections that user prefers. E.g. if user has custom Compose file it can look like include "<system wide file>" my_own_rules ... Of course, if some rules overlap, Xlib just discards a previous rule and uses latest one. Also I think some substitutions in the included file name could be usefull. A made two ones: %H means the value of HOME variable and %L means the name with full path to a currently used local-depended file (e.g /usr/X11R6/lib/X11/locale/iso8859-1/Compose). The first substitution woild allow to add a per-user preference file into a 'system' Compose file, e.g. system-wide file: common_rules ... include "%H/.XCompose" If the file doesn't exist Xlib silently ignores such instruction. The second substitution would allow user to add currently used files into own custom Compose file without care where that file is actually placed. In finally a most doubtfull part: how to specify needed Compose file. Now I made an environment variable XCOMPOSEFILE which value should be a name (with a path) of Compose file. But I realize it is unhandly for users. Any ideas are welcome. P.S. All changes I'm talking about are already made and tested. I can commit them in any time. But I'd like to hear suggestions/objections. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n