Ibus / m17n input newly broken

[Dominik Wujastyk]

Linux Mint 17 Qiana

Typing Sanskrit in Linux Mint/Cinnamon is normally very convenient, using the built-in ibus and m17n systems. You can write देवनागरी or romanisation (devanāgarī) with just a switch of the keyboard input method. The m17n distribution includes many keyboards, including convenient ones for Sanskrit that I've used for several years.

All this has worked until about a month ago. The symptom is that as you type a space, the letters around the cursor jump into the wrong order.

This is a bug that appeared in Ubuntu in October 2011. It was fixed, but the identical problem has now resurfaced here in Linux Mint 17.

I reported on the problem in my blog post:

https://www.blogger.com/blogger.g?blogID=21397721#editor/target=post;postID=9129587542503293084;onPublishedMenu=posts;onClosedMenu=posts;postNum=3;src=postname

Dominik Wujastyk

[Dominik Wujastyk (wujastyk)]

I'm not completely sure yet, but it looks like this input bug only affects typing into text boxes in Google Chrome. On a hunch, I tried Firefox and some simple editors (TeXstudio, Geany, Kate) and everything was fine.

[නයන හෙට්ටිආරච්චි (pituwaco)]

this is a valid statement i have observed this behaviour for the same period, now that i use my native script for publish content and developing software i have done more research. there is few things wrong here

1. over 80% Abugida style writing scripts have totally messed up their unicode specification, unicode specification suppose to include (personal opinion a very strong one based on lot of facts) only the symbols present in keyboard. the rest of the rendering suppose to be a job of the font. unless for some very rare care situation. so the behaviour being observed on google chrome input boxes is that its not obeying the m18n preedits or postedits etc, i think its running inside the sandbox hooking directly at a level lower than m17n for keyboard. this behaviour is not observed in chromium

i don't want to make this a unicode specification discussion post, but i will soon publish my findings, and it's really ashamful

[නයන හෙට්ටිආරච්චි (pituwaco)]

to expand on the above comment here is some examples you may see incorrectly on chrome

 ෙෙ ෙකෙ ෙක ෙකෙ (For linux)
 කාකාකාකාකා කාකාක කා කාක කා ක ාක (for osx)

the specification oversight here is the fact that attachments to left or right of a consonant has been registered with a zwj (they don't need one) keyboard is a input system of registered symbols printed on the keys or have been mapped to a given set of symbols where native synbols keyboard are not available. when i press A key that key should be printed in the order i pressed them. unless the symbol appears exactly on top or bottom of a base where a zwj is required.

there is a difference between symbols (script) and language.

[නයන හෙට්ටිආරච්චි (pituwaco)]

for any other application you had trouble with you can try modifying m17n-db and removing all the transitions and keep only the base bindings to keycodes. this change does not get applied on chrome. because of its sandbox input

[නයන හෙට්ටිආරච්චි (pituwaco)]

just checked on chrome with -no-sandbox the behaviour still remains, so i am bit lost now since chromium works fine, i am just gonna stop spending time on trying to find bugs on commercial code :) and switch to chromium instead + the firefox