Bug 435880 - [si_LK] [ta_LK] [th_TH] ibus-gtk requires surrounding-text support for editing complex text
[si_LK] [ta_LK] [th_TH] ibus-gtk requires surrounding-text support for editin...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ibus-m17n (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Daiki Ueno
Fedora Extras Quality Assurance
: FutureFeature, i18n, MoveUpstream, Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-04 03:46 EST by Parag Nemade
Modified: 2010-10-06 16:45 EDT (History)
10 users (show)

See Also:
Fixed In Version: ibus-m17n-1.3.1-4.fc14
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-06 16:45:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
sinhala-testcase-incorrect-rendering.png (22.20 KB, image/png)
2008-03-04 06:14 EST, Parag Nemade
no flags Details
sinhala-testcase-correct-rendering.png (17.53 KB, image/png)
2008-03-04 06:17 EST, Parag Nemade
no flags Details
modified si-wijesekera-preedit.mim (6.09 KB, application/octet-stream)
2008-03-05 22:20 EST, Parag Nemade
no flags Details
modified si-wijesekera.mim (10.72 KB, application/octet-stream)
2008-03-05 22:20 EST, Parag Nemade
no flags Details
Patch for ibus-m17n engine.c (5.96 KB, patch)
2010-09-12 22:41 EDT, fujiwara
no flags Details | Diff

  None (edit)
Description Parag Nemade 2008-03-04 03:46:53 EST
Description of problem:
incorrect rendering of typed text using sinhala keymaps.

Version-Release number of selected component (if applicable):
scim-bridge-0.4.14-2.fc9.i386
m17n-lib-1.5.1-1.fc9.i386
scim-m17n-0.2.2-3.fc9.i386
m17n-db-sinhala-1.5.1-1.fc9.noarch
m17n-contrib-sinhala-1.1.6-2.fc9.noarch
scim-1.4.7-12.fc9.i386

How reproducible:
always

Steps to Reproduce:
1.open gedit or evolution
2. select si-wijesekera.mim from upstream tarball and install it to
/usr/share/m17n and then scim-restart or si-phonetic-dynamic.mim from scim toolbar
3.observe rendering of characters.


  
Actual results:
incorrect rendering

Expected results:
should support surround text and correct rendering of text

Additional info:
Test cases
a)Select m17n si-wijesekera (non-preedit):
 1)TYPE: fkda (incorrect): ෙනා්
 2)TYPE: fkda (correct): නෝ

b)Select m17n si-phonetic-dynamic:
 1)TYPE: nO (incorrect): නඕ
 2)TYPE: nO (correct): නෝ
Comment 1 Parag Nemade 2008-03-04 03:49:51 EST
I found that this problem can be solved when gedit or evolution is started like
GTK_IM_MODULE=scim gedit
or
GTK_IM_MODULE=scim evolution
Comment 2 Parag Nemade 2008-03-04 04:00:00 EST
NOTE:- Sinhala community requested to add si-wijesekera.mim in m17n-db-sinhala
package. Currently we are manually removing it in SPEC. 
   Changes need to test si-wijesekera.mim on rawhide is to 
1)mv /usr/share/m17n/si-wijesekera.mim  /usr/share/m17n/si-wijesekera-preedit.mim
2)open /usr/share/m17n/si-wijesekera-preedit.mim and replace line
(input-method si wijesekera)
to
(input-method si wijesekera-preedit)
3) manually copy si-wijesekera.mim to /usr/share/m17n/ from upstream tarball
http://www.m17n.org/m17n-lib-download/m17n-db-1.5.1.tar.gz
4) then scim-restart
5) use testcase given in initial comment.
Comment 3 Peng Huang 2008-03-04 05:07:59 EST
Could attach some screenshot for this bug? Thanks.
Comment 4 Parag Nemade 2008-03-04 06:14:46 EST
Created attachment 296723 [details]
sinhala-testcase-incorrect-rendering.png

incorrect rendering with sinhala keymaps when started gtk application without 
GTK_IM_MODULE=scim
Comment 5 Parag Nemade 2008-03-04 06:17:29 EST
Created attachment 296724 [details]
sinhala-testcase-correct-rendering.png

correct rendering with sinhala keymaps when started gtk application with
GTK_IM_MODULE=scim
Comment 6 Parag Nemade 2008-03-05 22:16:28 EST
Phuang,
 sorry for step1 in comment#2 it should be
1)mv /usr/share/m17n/si-wijesekera-preedit.mim  /usr/share/m17n/si-wijesekera.mim
Comment 7 Parag Nemade 2008-03-05 22:20:08 EST
Created attachment 296988 [details]
modified si-wijesekera-preedit.mim
Comment 8 Parag Nemade 2008-03-05 22:20:55 EST
Created attachment 296989 [details]
modified si-wijesekera.mim
Comment 9 Jens Petersen 2008-03-25 04:47:28 EDT
And this used to work for some older versions of scim-bridge, is that right?
Comment 10 Bug Zapper 2008-05-14 01:45:20 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Brennan Ashton 2008-06-07 22:24:27 EDT
Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Comment 12 Jens Petersen 2008-06-29 19:59:41 EDT
Ping Parag
Comment 13 Jens Petersen 2008-07-16 21:23:31 EDT
Parag?
Comment 14 Tony Fu 2008-09-09 23:15:46 EDT
requested by Jens Petersen (#27995)
Comment 15 Bug Zapper 2009-06-09 19:40:10 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Jens Petersen 2009-06-24 00:04:30 EDT
scim-bridge and ibus do not support surrounding-text.  We should probably clone a bug for ibus.
Comment 17 Jens Petersen 2009-07-14 20:35:18 EDT
Hash, could you give some explicit examples/testcases to better understand the problem, please?
Comment 18 Harshula Jayasuriya 2009-07-20 20:45:46 EDT
Hi Jens,

Sinhala input using the Wijesekera keyboard layout involves typing in decomposed form and storing in composed form. Typing A, B, C, D would be stored as B, E where E is the composed form of A, C, D. When editing the document, after the buffer has been committed, backspace should delete the letters in reverse decomposed order. i.e. D, C, B, A.

Example A:
1) <f><l><d><a> should output කෝ.
2) Press the space bar to commit the buffer.
3) Press the backspace key 4 times. 
4) The remaining output should be ෙ .

Example B:
1) <f><l><d><a> should output කෝ.
2) Press the space bar to commit the buffer.
3) Press the backspace key 3 times
4) Prease <a>
5) The remaining output should be කේ.

cya,
#
Comment 19 Pravin Satpute 2009-07-21 10:31:56 EDT
my comments on bug summary

> Additional info:
> Test cases
> a)Select m17n si-wijesekera (non-preedit):
>  1)TYPE: fkda (incorrect): ෙනා්

I tested in both scim as well in ibus

This is happening since si-wijesekera (non-preedit) doesnt have any intelligence inbuild. It is not doing any reordering (like it is happening w-preedit version, i think its pushback method pushing k first)

therefore si-wijesekera (non-preedit) giving fkda as it is for rendering.
fkda = U+0dd9 U+0db1 U+0dcf U+0dca

and it is providing above result as U+0dd9 is matra and should be after consonant

> > a)Select m17n si-wijesekera (preedit):
>  2)TYPE: fkda (correct): නෝ

here preedit one doing reordering before giving ip to renderer,
so fkda is getting converted into 
fkda = U+0dd9 U+0db1 U+0dcf U+0dca

is converted into

kfda = U+0dd9 U+0ddd  and giving correct o/p


one can verify same by giving 
fkda or kfda to w-preedit it will give same o/p

while giving both to w-non-preedit will give different o/p since no reordering is happening there

so IMHO whatever is happening is correct and working as per rules written in mim file, there is nothing to do with surrounding text.
Comment 20 Pravin Satpute 2009-07-21 10:46:28 EDT
(In reply to comment #18)
> Hi Jens,
> 
> Sinhala input using the Wijesekera keyboard layout involves typing in
> decomposed form and storing in composed form. Typing A, B, C, D would be stored
> as B, E where E is the composed form of A, C, D. When editing the document,
> after the buffer has been committed, backspace should delete the letters in
> reverse decomposed order. i.e. D, C, B, A.

yeah, as you written

here input method is intelligent and reordering input given by user as per required by rendered (sometime its bit easy to writing for user )
so ABCD is getting converted into BACD  (ACD = E)
so its BE

so here actual we see after preedit commit is BE
and while back spacing, since backspace is working on committed thing i.e

BE decomposed BACD , its first deleting D then C then A, and we are getting remaining thing is B same in example its consonant U+0d9a

so whatever happening is right

if input method give i/p as it is to renderer then it will produce wrong o/p.
Comment 21 Jens Petersen 2009-07-21 22:33:00 EDT
Reassigning to Hash who are volunteered to work on this in his spare cycles. :)
Comment 22 ntakahas 2009-07-23 23:37:34 EDT
(In reply to comment #19)

Hello, this is the upstream.

> I tested in both scim as well in ibus

> This is happening since si-wijesekera (non-preedit) doesnt have any
> intelligence inbuild. It is not doing any reordering (like it is happening
> w-preedit version, i think its pushback method pushing k first)

I assure you, Jens.  si-wijesekera (non-preedit) DOES reordering using surrounding text.  Try to use scim-gtk, which supports surrounding text, instead of scim-bridge, which doesn't.
Comment 23 Pravin Satpute 2009-07-24 00:02:20 EDT
I think there is need to improve bug summary

xx combinatoin working in scim with surrounding text and same not working in ibus i.e (if possible screen shot)
Comment 24 Jens Petersen 2009-08-20 02:15:45 EDT
> I assure you, Jens.  si-wijesekera (non-preedit) DOES reordering using
> surrounding text.  Try to use scim-gtk, which supports surrounding text,
> instead of scim-bridge, which doesn't.  

Yep :)

Takahashi-san, is there any way that si-wijesekera.mim and si-wijesekera-preedit.mim could be merged?
Comment 25 ntakahas 2009-08-20 04:51:03 EDT
> Takahashi-san, is there any way that si-wijesekera.mim and
> si-wijesekera-preedit.mim could be merged?  

I think I can do it.  I am rather busy now, so I will put it on my todo list.  Give me some time.
Comment 26 ntakahas 2009-09-04 09:11:53 EDT
(In reply to comment #25)
I have merged si-wijesekera.mim and si-wijesekera-preedit.mim.  The new si-wijesekera.mim checks whether surrounding text is supported or not.
Please check the CVS version in various environments.

Note that some applications may answer "yes" to the above-mentioned check although they do not support surrounding text.  For this reason, surrounding text support is disabled in ta-lk-renganathan.mim although it works both in preedit mode and in surrounding text mode.
Comment 27 Harshula Jayasuriya 2009-09-06 21:49:26 EDT
Hi Takahashi,

What are the applications that claim to support surrounding text even when they do not?

cya,
#
Comment 28 ntakahas 2009-09-07 00:45:21 EDT
(In reply to comment #27)

> What are the applications that claim to support surrounding text even when they
> do not?

Iceweasel 3.0.12 is one of them.  Qt applications and Evolution were also reported to return a false answer, at least in 2008.  Openoffice and GTK applications seem to work fine.
Comment 29 Jens Petersen 2009-09-07 05:35:39 EDT
(In reply to comment #26)
> I have merged si-wijesekera.mim and si-wijesekera-preedit.mim.  The new
> si-wijesekera.mim checks whether surrounding text is supported or not.

Thank you very much that is great news! :)
Comment 30 Harshula Jayasuriya 2009-09-15 04:49:53 EDT
I did a quick test of the merged wijesekera file using scim-gtk (up-to-date F11) and typed the keys "fkda":

gedit (GTK): detected
lyx (QT): detected
oowriter: detected
firefox: not detected
evolution (TO/SUBJECT): detected
evolution (message pane): not detected (strange/unpredictable behaviour)

* "detected" means that the input string was displayed correctly. i.e. The input string should trigger surrounding text support.
* "not detected" means that the input string was displayed incorrectly. i.e. The application presumably claimed to support surrounding text but actually did not.
Comment 31 Harshula Jayasuriya 2009-10-30 09:29:50 EDT
(In reply to comment #26)

Hi Takahashi,

> Note that some applications may answer "yes" to the above-mentioned check
> although they do not support surrounding text.  For this reason, surrounding
> text support is disabled in ta-lk-renganathan.mim although it works both in
> preedit mode and in surrounding text mode.  

Thanks for merging the two MIM files into one, it will make it easier for the end users. I've given this some thought, could you please disable surrounding text support for the merged Wijesekera MIM too? Otherwise it will cause too much confusion when the displayed output on some applications are unpredictable. We can re-enable it when surrounding text support is advertised correctly. Also, you may want to delete the preedit version. Having only one Wijesekera MIM will make it easier for the end users.

Thanks,
#
Comment 32 ntakahas 2009-11-02 01:37:34 EST
(In reply to comment #31)

> Thanks for merging the two MIM files into one, it will make it easier for the
> end users. I've given this some thought, could you please disable surrounding
> text support for the merged Wijesekera MIM too?

> Also, you may want to delete the preedit version. 

Both done.
Comment 33 Bug Zapper 2009-11-16 03:02:20 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 34 Parag Nemade 2010-05-04 00:27:19 EDT
I guess this was already fixed in upstream right?
Closing as CURRENTRELEASE
Comment 35 Parag Nemade 2010-05-04 00:48:30 EDT
oops I thought its still asking for scim.
Let me re-open this.
Comment 36 Parag Nemade 2010-05-04 00:49:30 EDT
Can we have again what things need to be fixed here?
Comment 37 Harshula Jayasuriya 2010-05-04 00:53:33 EDT
The current status is that si-wijesekera.mim has been modified by Takahashi to
not require surrounding text support. Which addresses this particular bug.
AFAIK, IBus still does not support surrounding text.
Comment 38 Jens Petersen 2010-06-30 01:21:52 EDT
Assigning to Ueno-san who has been doing some work on this I believe.
Comment 39 Harshula Jayasuriya 2010-06-30 01:39:13 EDT
That's good news! I'll be happy to test surrounding text support once it is in IBus.
Comment 40 Daiki Ueno 2010-06-30 02:03:46 EDT
FYI, I recently posted patches for ibus & ibus-m17n to:

http://code.google.com/p/ibus/issues/detail?id=778
Comment 41 Daiki Ueno 2010-07-09 04:15:21 EDT
Harshula and Takahashi-san, could you test these patches when you have time?  I'm not familiar with languages in which surrounding-text is worth supporting.  If they are usable, I'll ask ibus & ibus-m17n upstream to include them in the future releases.
Comment 42 Harshula Jayasuriya 2010-07-30 01:41:18 EDT
Hi, Any chance you could build some test RPMs that include your patches?
Comment 43 Daiki Ueno 2010-07-30 04:05:07 EDT
OK, just put the RPMs:

http://ueno.fedorapeople.org/ibus-surrounding-text/
Comment 44 Fedora Admin XMLRPC Client 2010-08-02 02:09:18 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 45 fujiwara 2010-08-02 02:42:03 EDT
It seems there is a patch.
Transferring to the engineer.
Comment 46 Harshula Jayasuriya 2010-08-10 02:56:13 EDT
Hi, I tested the ibus & ibus-m17n RPMs with gedit and oowriter using the si-wijesekera.mim layout (first enabling the surrounding text check in the MIM file). The quick test showed that surrounding text support was active and seemed to be working well.
Comment 47 fujiwara 2010-08-23 02:22:14 EDT
I talked this problem with the maintainers.
The suggestion is to use preedit instead of surrounding.
Currently CJK input method engines uses preedit. If other engines could move to preedit feature, it would reduce the significant developments/maintenance costs.

There are some concerns to support the surrounding feature.
 - like xim, and some widgets may not support surrounding text
 - It is difficult to sync the surrounding text between application and engine
As you know, in ibus, many messages are async

All the fix could be resolved in each engine with this suggestion.
Comment 48 Daiki Ueno 2010-08-23 03:12:03 EDT
I would like to know if the preedit approach is acceptable for native speakers of languages in which surrounding-text is desired, including Sinhala, Thai, Korean, and Vietnamese.

I guess Vietnamese users are fine with the preedit approach since in that language each word is seperated by spaces and that can be used as a trigger of preedit commit.

However, Sinhala/Thai/Korean have no such rule (i.e. they are agglutinative languages) and users need to type extra Return to commit the preedit.

Harshula and Takahashi-san, any thoughts?
Comment 49 Harshula Jayasuriya 2010-08-23 03:50:01 EDT
Hi,

I appreciate that Input Method design and implementation is CJK centric for various reasons. Pre-edit is a viable workaround till surround text support can be enabled. In my view, surrounding text support MUST be enabled eventually. A Wijesekera keyboard layout using pre-edit can result in unexpected encoding errors when editing an existing text in a document. A non-technical user will be very confused by such errors.

I suggest surrounding text support be a tick-box option in IBus/engine preferences which is turned-off by default till the infrastructure components improve.

BTW, in modern Sinhala, words are also separated by a space. The problem is once the buffer has been committed and a user goes to edit a syllable. e.g. a syllable "koo" might need to be changed to "kee" and should require only two backspaces and al-lakuna key presses. But without surrounding text support you need 4 backspaces followed by 3 more key presses. The worst case scenario is if the user does the logical set of steps (2 backspaces and 1 al-lakuna) it will result in an encoding error.

Regards,
Harshula
Comment 50 ntakahas 2010-08-23 04:58:13 EDT
I also believe surrounding text shall be supported eventually.

Some input methods lets you type characters in the order "as you handwrite"; those input methods reorder the input characters when they are committed to satisfy the Unicode character order specification.

If you use such input methods with preedit, you may need to behave differently to change the same string, depending on whether it has already been committed or not.  This is an confusing situation.
Comment 51 fujiwara 2010-08-23 06:03:22 EDT
Thanks for the comments.

(In reply to comment #49)
> BTW, in modern Sinhala, words are also separated by a space. The problem is
> once the buffer has been committed and a user goes to edit a syllable. e.g. a
> syllable "koo" might need to be changed to "kee" and should require only two
> backspaces and al-lakuna key presses. But without surrounding text support you
> need 4 backspaces followed by 3 more key presses. The worst case scenario is if
> the user does the logical set of steps (2 backspaces and 1 al-lakuna) it will
> result in an encoding error.

In preedit, I would expect not to use any backspace keys if you need to change "koo" to "kee". I feel it would be one space and enter key.
It would be great if you could explain why it's important to support the already committed text since I don't identify the usage to the actual hand-writing.

In the preedit mode, I mean preedit buffer would be similar to the writing mode. Once the text is committed in preedit mode, using backspace keys on computer could be similar to using an eraser on paper.
So if you try to modify the already committed text in surrounding mode, it would be similar to using an eraser on paper to me.

(In reply to comment #50)
> If you use such input methods with preedit, you may need to behave differently
> to change the same string, depending on whether it has already been committed
> or not.  This is an confusing situation.

The previous suggestion means to support the previous chars belonged to a word without supporting already committed text.
It would be great if you could explain why it's important to support the already committed text since I don't identify the usage to the actual hand-writing.
Comment 52 Theppitak Karoonboonyanan 2010-08-23 10:01:28 EDT
Hi,

I was pointed to this bug where surrounding text support is being discussed. I'd say the most natural Thai input method needs surrounding text support. Other existing approaches appear not smooth to Thai users, such as preediting in some recent scim-m17n, or plain table lookup in scim-table.

Thai input method may be less complicated than that of Indic scripts because Thai is not encoded in the so-called 'logical order', but it requires sequence validation. When editing already committed text, the new input character must be validated with the current text whether it's composible.

Note that while Thai encoding scheme is closer to Latin than Indic, its combining characters are never composed into pre-composed forms. They are encoded in separation from the base characters. And only limited number and order of combining characters are allowed. Some rules have been defined as described in [1]. So, the committed text is still open for editing just like when it's in preedit stage. No difference. And thus surrounding text support is required to determine the validity of the input character, or even to modify the surrounding text to let it in in some implementations.

[1] http://linux.thai.net/~thep/th-xim/
Comment 53 ntakahas 2010-08-23 21:17:48 EDT
(In reply to comment #51)
> In preedit, I would expect not to use any backspace keys if you need to change
> "koo" to "kee". I feel it would be one space and enter key.

I do not see how "one space and enter key" changes "koo" into "kee".

If you are using si-wijesekera in the preedit mode, you type "flda" to get the "koo" syllable in the preedit buffer.  To change this "koo" into "kee" before committing it, you type BS, BS, "a".  The first BS changes "koo" into "ko" and the second BS changes "ko" into "ke".  Then the "a" key changes "ke" into "kee".

On the other hand, when you change an already committed "koo" into "kee", you first move the cursor after the "koo" and type BS, BS, "fla".  The first BS changes "koo" into "k" and the second BS removes the syllable entirely.  Then the key sequence "fl" inserts a new "ke" and the final "a" changes that "ke" into "kee".

I recommend you to type the above sequences in gedit to see how "koo", "kee", etc. are represented in Sinhala.

> The previous suggestion means to support the previous chars belonged to a word
> without supporting already committed text.

Sorry, I do not understand this sentence.

> It would be great if you could explain why it's important to support the
> already committed text since I don't identify the usage to the actual
> hand-writing.

As I described above, the key sequence to change "koo" into "kee" is different for the preedit buffer and for committed text.  Don't you think it is confusing?
Comment 54 Harshula Jayasuriya 2010-08-23 21:34:01 EDT
(In reply to comment #51)

> In preedit, I would expect not to use any backspace keys if you need to change
> "koo" to "kee". I feel it would be one space and enter key.
> It would be great if you could explain why it's important to support the
> already committed text since I don't identify the usage to the actual
> hand-writing.

I already explained this 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=435880#c18
Comment 55 fujiwara 2010-08-23 21:49:49 EDT
(In reply to comment #53)
> (In reply to comment #51)
> > In preedit, I would expect not to use any backspace keys if you need to change
> > "koo" to "kee". I feel it would be one space and enter key.
> 
> I do not see how "one space and enter key" changes "koo" into "kee".
> 
> If you are using si-wijesekera in the preedit mode, you type "flda" to get the
> "koo" syllable in the preedit buffer.  To change this "koo" into "kee" before
> committing it, you type BS, BS, "a".  The first BS changes "koo" into "ko" and
> the second BS changes "ko" into "ke".  Then the "a" key changes "ke" into
> "kee".
> 
> On the other hand, when you change an already committed "koo" into "kee", you
> first move the cursor after the "koo" and type BS, BS, "fla".  The first BS
> changes "koo" into "k" and the second BS removes the syllable entirely.  Then
> the key sequence "fl" inserts a new "ke" and the final "a" changes that "ke"
> into "kee".

Thanks for that practice.
Actually I also would think that usage but I could not explain the key type
because I don't know that key sequence itself. The my point was that it might
be possible to cover the surrounding feature with preedit or something.
I.e. an engine could remember the previous key sequences 'flda' and if you type
BS, BS, 'a', the engine could output the right word for 'fla'.

The point was, if you need two BS keys and al-lakuna key with surrounding, it
would be replaced with the same way with preedit or something.

> 
> I recommend you to type the above sequences in gedit to see how "koo", "kee",
> etc. are represented in Sinhala.
> 
> > The previous suggestion means to support the previous chars belonged to a word
> > without supporting already committed text.
> 
> Sorry, I do not understand this sentence.

I mean to support the word sequences only before you commit the word but not
support to modify the already committed sentence.
E.g. above preedit feature could be applied to the modifying the text before
the text is committed. But it's not applied to already committed text.
But I would think a reconvert feature with preedit also could convert the
already committed text.

Hope somebody could reply my question.
> > It would be great if you could explain why it's important to support the
> > already committed text since I don't identify the usage to the actual
> > hand-writing.
>
Comment 56 ntakahas 2010-08-23 23:21:35 EDT
(In reply to comment #55)

> I.e. an engine could remember the previous key sequences 'flda' and if you type
> BS, BS, 'a', the engine could output the right word for 'fla'.

Imagine the following situation.  You write a message in Sinhala that contains "koo" and send it to me by email.  I read it want to change the "koo" to "kee".  How can my IM understand the the existance of the "koo" syllable without surrounding text support?
Comment 57 Jens Petersen 2010-08-23 23:30:11 EDT
(In reply to comment #55)
> The point was, if you need two BS keys and al-lakuna key with surrounding, it
> would be replaced with the same way with preedit or something.

I think the current BS behaviour under Wijesekera is considered
optimal for users and the same behaviour is desired when editing
committed text and that could be provided by surrounding text.

> But I would think a reconvert feature with preedit also could convert the
> already committed text.

Interesting idea - that might help, but probably users prefer not
to leave the keyboard just to edit committed text.

> Hope somebody could reply my question.
> > > It would be great if you could explain why it's important to support the
> > > already committed text since I don't identify the usage to the actual
> > > hand-writing.

I think some came up earlier: avoiding illegal text sequences from
partial deletion of text, consistency of BS and input behaviour and
avoiding the need for preedit, I think.
Comment 58 fujiwara 2010-08-24 00:02:35 EDT
(In reply to comment #56)
> > I.e. an engine could remember the previous key sequences 'flda' and if you type
> > BS, BS, 'a', the engine could output the right word for 'fla'.
> 
> Imagine the following situation.  You write a message in Sinhala that contains
> "koo" and send it to me by email.  I read it want to change the "koo" to "kee".
>  How can my IM understand the the existance of the "koo" syllable without
> surrounding text support?

I would expect it's same with Japanese. You erase the words and type "kee" again.
In CJK, Once you committed a string on computer, modifying the string would mean to erase some chars with BS and type a new word.
In CJK, Once you write a string on paper, modifying the string would mean to erase some chars with an eraser and type a new word.
They are same behavior between computer and paper in CJK. I would guess it's also true in Indic.
Why do you need the different behavior using surrounding on computer in Indic?
In CJK, users would not feel a stress without covering that case.

Or I would think a reconvert feature with preedit to satisfy that usage.
I would think it might be a kind of workaround but that's why I ask the reason:
Hope somebody could reply my question.
> > It would be great if you could explain why it's important to support the
> > already committed text since I don't identify the usage to the actual
> > hand-writing.

(In reply to comment #57)
> > The point was, if you need two BS keys and al-lakuna key with surrounding, it
> > would be replaced with the same way with preedit or something.
> 
> I think the current BS behaviour under Wijesekera is considered
> optimal for users and the same behaviour is desired when editing
> committed text and that could be provided by surrounding text.

Hmm.., I would expect the input way is same between preedit(or something) and surrounding in this case.
In this case, I don't suppose the already committed text.
I don't think the current implementation of m17n and probably would need furthermore developments but would not effect ibus.

> I think some came up earlier: avoiding illegal text sequences from
> partial deletion of text, consistency of BS and input behaviour and
> avoiding the need for preedit, I think.

Yes, I also would think those cases however my question means why that usages are important?
In CJK, if a string is committed, we use BS to erase chars and general users don't feel stress without surrounding because that way would be similar to the hand-writing on paper.
Comment 59 ntakahas 2010-08-24 03:06:46 EDT
(In reply to comment #58)
> In CJK, Once you committed a string on computer, modifying the string would
> mean to erase some chars with BS and type a new word.
> In CJK, Once you write a string on paper, modifying the string would mean to
> erase some chars with an eraser and type a new word.
> They are same behavior between computer and paper in CJK. I would guess it's
> also true in Indic.
> Why do you need the different behavior using surrounding on computer in Indic?

Because Sinhala users requested that.  So did Tamil users.

> Or I would think a reconvert feature with preedit to satisfy that usage.

Would you elaborate on that point?

> Hmm.., I would expect the input way is same between preedit(or something) and
> surrounding in this case.

Exactly.

> > I think some came up earlier: avoiding illegal text sequences from
> > partial deletion of text, consistency of BS and input behaviour and
> > avoiding the need for preedit, I think.

> Yes, I also would think those cases however my question means why that usages
> are important?

Only Sinhala users can answer that question.  Unfortunately, I am not.
Comment 60 fujiwara 2010-08-24 04:02:39 EDT
OK, thanks for the discussion. Probably we could get a bunch of opinions.
I'll return to this bug again after I talk with upstream maintainers again (maybe today or tomorrow).

It may be good to know other platforms, e.g. MS-Windows.
Comment 61 fujiwara 2010-09-12 22:41:25 EDT
Created attachment 446824 [details]
Patch for ibus-m17n engine.c

http://github.com/fujiwarat/ibus/commit/ddc1242bf37ac525faaec57bd8c22214044ec5ab

Revised the patches:
 - ibus surrounding-text is enabled when only when ibus_engine_retrieve_surrounding_text() is called.
 - Moved internal struct members from ibus to ibus-m17n
Comment 62 fujiwara 2010-09-12 23:02:24 EDT
As we discussed last week, The IBus maintainer agreed with having surrounding-text feature in IBus.

Now probably it's good to have the ability in f14.
I'm thinking which patch is better for Fedora feature patches as we would think the current patch could be enhanced in the future.
The above patch would be a suggestion from mine.
Comment 63 fujiwara 2010-09-12 23:41:43 EDT
Added the scratch build for ibus:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2463589
Comment 64 fujiwara 2010-09-13 06:16:15 EDT
Today I had a chance to talk about my patch.
My patch would have a potential problem when the machine resources are tight since it would depend on the async functions as I don't see any actual problems in my test.

If we will fix my concerns, probably the use of ibus capability would be a solution.
Probably it could be enhanced later so currently I'm thinking to integrate Ueno-san's patch.
Comment 65 fujiwara 2010-09-13 22:45:37 EDT
Integrated the ibus patch into f14:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2465882

Currently I won't integrate it into f13 until va_list issue is fixed.
http://koji.fedoraproject.org/koji/taskinfo?taskID=2465786
Comment 67 Fedora Update System 2010-09-16 00:03:15 EDT
ibus-m17n-1.3.1-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ibus-m17n-1.3.1-2.fc14
Comment 68 Fedora Update System 2010-09-17 00:03:43 EDT
ibus-m17n-1.3.1-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ibus-m17n'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ibus-m17n-1.3.1-2.fc14
Comment 69 Fedora Update System 2010-10-01 05:45:43 EDT
ibus-m17n-1.3.1-3.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ibus-m17n-1.3.1-3.fc14
Comment 70 Fedora Update System 2010-10-04 23:40:13 EDT
ibus-m17n-1.3.1-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ibus-m17n-1.3.1-4.fc14
Comment 71 Fedora Update System 2010-10-06 16:44:59 EDT
ibus-m17n-1.3.1-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.