|
»
»
»
Re: One key stroke --> two code-points
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: One key stroke --> two code-points
by Jens Herden
::
Rate this Message:
Hi Simos,
> Checking at > http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=tree;f=nls/en_US.UTF >-8 does not show these lines at the end. It is possible that these compose > sequences were added as a patch to the distribution package. yes indeed, this addition was made by Suse for their package. I am not aware if any other distro picked this up too. But I have filed a bug-report for Xorg about this, which is not resolved yet: https://bugs.freedesktop.org/show_bug.cgi?id=5706 Jens _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@... http://mail.gnome.org/mailman/listinfo/gtk-i18n-list |
|
|
Re: One key stroke --> two code-points
by Anousak Souphavanh-2
::
Rate this Message:
Thanks, Simos for your kind and time.
Much appreciated to Javier for brought a good solution indeed. Lao input method is need a similar solution. Javier please post your solution (where and how to define a new table for Khmer) so I can define these code points for Lao. Thanks, Anousak The Lao team On Tue, Jun 10, 2008 at 1:58 AM, Simos Xenitellis <simos.lists@...> wrote: > O/H Javier SOLA έγραψε: >> >> Thanks Simos !! >> >> Actually, we have had these additions for a while in X11. > > Hi Javier, > > Checking at > http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=tree;f=nls/en_US.UTF-8 > does not show these lines at the end. It is possible that these compose > sequences were added as a patch to the distribution package. >> >> We will do an issue for GTK+, and use the variable meanwhile. >> >> What file is it in GTK+? I have not been able to find it. > > In GTK+ (HEAD), the relevant file is > http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkimcontextsimple.c?view=markup > > However, your case of compose sequences is different from the existing > compose sequences, that result to a single codepoint (you require to produce > two codepoints). > > Therefore, the type of support you are looking for is similar to compose > sequences that result to letter+diacritic mark. Several languages have > characters that no pre-composed letters exist, so the compose sequence > produces letter+diacritic marks (more than one codepoint). Such support is > missing, and there are already bug reports for them. > > Bug 341341 – Compose mechanism in simple input method doesn't support > decomposed forms > http://bugzilla.gnome.org/show_bug.cgi?id=341341 > > Bug 345254 – dead accents should at least produce combining characters > http://bugzilla.gnome.org/show_bug.cgi?id=345254 > > There is a shortcut when trying to solve the above cases of compose > sequences, thus the solution I expect to be different from the Khmer compose > sequences. > Specifically, for the Latin compose sequences, such as (it's a made up > example) > > <dead_acute> <t> : "t́" # LETTER T WITH ACUTE > > one could convert to something like [ dead_acute, 't', 0]. > We would put 0 for the resulting codepoint because we can deduce for this > category of compose sequences that the actual codepoints are 't' and 'acute' > (the resulting codepoints match the body of the compose sequence). > > However, for the case of Khmer, the compose sequences look independent from > the resulting code points. Therefore, a new table should be required. > > To cut the story short, I have filed a bug report for this, > Bug 537457 – Support compose sequences that produce two+ codepoints > http://bugzilla.gnome.org/show_bug.cgi?id=537457 > > Simos > >> >> Thanks, >> >> Javier >> >> Simos Xenitellis wrote >>> >>> O/H Javier SOLA έγραψε: >>>> >>>> Hi, >>>> >>>> I am working on Khmer localization (KhmerOS project). >>>> >>>> In Khmer, some of the basic vowels (which we include in the keyboard) >>>> require two code-points, so one keystroke must generate two code points. >>>> >>>> It used to be that we could do the conversion in KBX by generating a >>>> fictious code-point (Pablo Saratxaga explained this to us a few years ago), >>>> which was later translated to two real code-points by puting the conversion >>>> in the en-US locale file. I did work at the time. >>>> >>>> But now this seems to have stopped working. Does anybody knows how we >>>> can fix this? >>> >>> These additions (pressing a single key and producing two codepoints), are >>> located at >>> /usr/share/X11/locale/en_US.UTF-8/Compose >>> The specific lines appear to be >>> >>> # Khmer digraphs >>> # A keystroke has to generate several characters, so they are defined >>> # in this file >>> >>> <U17fb> : "ុះ" >>> <U17fc> : "ុំ" >>> <U17fd> : "េះ" >>> <U17fe> : "ោះ" >>> <U17ff> : "ាំ" >>> >>> GTK+ based applications duplicate the Compose file in the gtk+ library, >>> and currently the version of the Compose file that exists in gtk+ does not >>> include those specific compose sequences. >>> I think these are a recent addition. >>> Technically, it is possible for gtk+ to include compose sequences that >>> produce more than one code points (requires small change in the code), >>> however these recent Khmer digraphs are the only compose sequences using the >>> facility now. >>> >>> To cut the long story short, you can bypass for now the GTK+ version of >>> the Compose file and use the Compose file that comes with X.Org (shown >>> above) by setting the environment variable GTK_IM_MODULE to "xim". >>> This should not have adverse effect to the OLPC software. >>> >>> It is important that if other keyboard layouts as well require compose >>> sequences that produce >>> two or more codepoints (such as Serbian), to add them to the XOrg Compose >>> file. In the next iteration of update of the GTK+, all these compose >>> sequences can make it in. >>> >>> Simos >>> >>> >> >> > > _______________________________________________ > gnome-i18n mailing list > gnome-i18n@... > http://mail.gnome.org/mailman/listinfo/gnome-i18n > -- Anousak (Anthony) Souphavanh "Small can make a big impact" _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@... http://mail.gnome.org/mailman/listinfo/gtk-i18n-list |
|
|
Re: One key stroke --> two code-points
by Anousak Souphavanh-2
::
Rate this Message:
Thanks, Simos for your kind and time.
Much appreciated to Javier for brought a good solution indeed. Lao input method is need a similar solution. Javier please post your solution (where and how to define a new table for Khmer) so I can define these code points for Lao. Thanks, Anousak The Lao team > On Tue, Jun 10, 2008 at 1:58 AM, Simos Xenitellis > <simos.lists@...> wrote: >> O/H Javier SOLA έγραψε: >>> >>> Thanks Simos !! >>> >>> Actually, we have had these additions for a while in X11. >> >> Hi Javier, >> >> Checking at >> http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=tree;f=nls/en_US.UTF-8 >> does not show these lines at the end. It is possible that these compose >> sequences were added as a patch to the distribution package. >>> >>> We will do an issue for GTK+, and use the variable meanwhile. >>> >>> What file is it in GTK+? I have not been able to find it. >> >> In GTK+ (HEAD), the relevant file is >> http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkimcontextsimple.c?view=markup >> >> However, your case of compose sequences is different from the existing >> compose sequences, that result to a single codepoint (you require to produce >> two codepoints). >> >> Therefore, the type of support you are looking for is similar to compose >> sequences that result to letter+diacritic mark. Several languages have >> characters that no pre-composed letters exist, so the compose sequence >> produces letter+diacritic marks (more than one codepoint). Such support is >> missing, and there are already bug reports for them. >> >> Bug 341341 – Compose mechanism in simple input method doesn't support >> decomposed forms >> http://bugzilla.gnome.org/show_bug.cgi?id=341341 >> >> Bug 345254 – dead accents should at least produce combining characters >> http://bugzilla.gnome.org/show_bug.cgi?id=345254 >> >> There is a shortcut when trying to solve the above cases of compose >> sequences, thus the solution I expect to be different from the Khmer compose >> sequences. >> Specifically, for the Latin compose sequences, such as (it's a made up >> example) >> >> <dead_acute> <t> : "t́" # LETTER T WITH ACUTE >> >> one could convert to something like [ dead_acute, 't', 0]. >> We would put 0 for the resulting codepoint because we can deduce for this >> category of compose sequences that the actual codepoints are 't' and 'acute' >> (the resulting codepoints match the body of the compose sequence). >> >> However, for the case of Khmer, the compose sequences look independent from >> the resulting code points. Therefore, a new table should be required. >> >> To cut the story short, I have filed a bug report for this, >> Bug 537457 – Support compose sequences that produce two+ codepoints >> http://bugzilla.gnome.org/show_bug.cgi?id=537457 >> >> Simos >> >>> >>> Thanks, >>> >>> Javier >>> >>> Simos Xenitellis wrote >>>> >>>> O/H Javier SOLA έγραψε: >>>>> >>>>> Hi, >>>>> >>>>> I am working on Khmer localization (KhmerOS project). >>>>> >>>>> In Khmer, some of the basic vowels (which we include in the keyboard) >>>>> require two code-points, so one keystroke must generate two code points. >>>>> >>>>> It used to be that we could do the conversion in KBX by generating a >>>>> fictious code-point (Pablo Saratxaga explained this to us a few years ago), >>>>> which was later translated to two real code-points by puting the conversion >>>>> in the en-US locale file. I did work at the time. >>>>> >>>>> But now this seems to have stopped working. Does anybody knows how we >>>>> can fix this? >>>> >>>> These additions (pressing a single key and producing two codepoints), are >>>> located at >>>> /usr/share/X11/locale/en_US.UTF-8/Compose >>>> The specific lines appear to be >>>> >>>> # Khmer digraphs >>>> # A keystroke has to generate several characters, so they are defined >>>> # in this file >>>> >>>> <U17fb> : "ុះ" >>>> <U17fc> : "ុំ" >>>> <U17fd> : "េះ" >>>> <U17fe> : "ោះ" >>>> <U17ff> : "ាំ" >>>> >>>> GTK+ based applications duplicate the Compose file in the gtk+ library, >>>> and currently the version of the Compose file that exists in gtk+ does not >>>> include those specific compose sequences. >>>> I think these are a recent addition. >>>> Technically, it is possible for gtk+ to include compose sequences that >>>> produce more than one code points (requires small change in the code), >>>> however these recent Khmer digraphs are the only compose sequences using the >>>> facility now. >>>> >>>> To cut the long story short, you can bypass for now the GTK+ version of >>>> the Compose file and use the Compose file that comes with X.Org (shown >>>> above) by setting the environment variable GTK_IM_MODULE to "xim". >>>> This should not have adverse effect to the OLPC software. >>>> >>>> It is important that if other keyboard layouts as well require compose >>>> sequences that produce >>>> two or more codepoints (such as Serbian), to add them to the XOrg Compose >>>> file. In the next iteration of update of the GTK+, all these compose >>>> sequences can make it in. >>>> >>>> Simos >>>> >>>> >>> >>> >> >> _______________________________________________ >> gnome-i18n mailing list >> gnome-i18n@... >> http://mail.gnome.org/mailman/listinfo/gnome-i18n >> > > > > -- > Anousak (Anthony) Souphavanh > "Small can make a big impact" > -- Anousak (Anthony) Souphavanh "Small can make a big impact" _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@... http://mail.gnome.org/mailman/listinfo/gtk-i18n-list |
| Free Forum Powered by Nabble | Forum Help |