In Word (Office 365) a character inserted through a
rota group extinguishes the previous character.
In Libre Office it works correctly!
In my case it is a chandrabindu in my devanagari keyboard eating the e.
k+e+M+M should give केँ
In Word it removes the e and the result is कँ
I extracted a part of the code, so that you can test it.
group(main) using keys
store(vowAnUD) 'ऋऌ' 'ं'
store(vowelsDoUD) 'ॠॡ' "ँ"
store(diphtongmAtrAHD) 'े' 'ो' c e,o
+ any(consonantsL) > index(consonantsLD,1) U+094D
U+094D + any(diphtongmAtrAH) > index(diphtongmAtrAHD,2)
+ any(vowAnU) > index(vowAnUD,1) use(rota) c R,L,M
any(vowAnUD) index(vowAnUD,1) > index(vowelsDoUD,1)
Can you provide additional details of what versions of Windows and Keyman you’re using?
I’ve just tested this in Word in Office 365 1910 12310.20410 (64-bit) and Keyman 13.0.34 on Windows 10 1903 and was not able to reproduce the issue – it worked as expected on my machine. Can you give some more detail as @darcy requests?
I am using Windows 10 Pro 1903 / Keyman 13.0.32 / Word in Office 365 Version 1910 (Build 12130.20390 Microsoft Store).
Seems to be quite similar to your system
Given the similarity, I wonder if we have something else going on. Have you tested that the error occurs with the minimal keyboard that you shared here?
If it does, then perhaps you could send a debug log (via direct message) following the steps at https://help.keyman.com/knowledge-base/76 (these instructions need updating; in particular, don’t press Pause to finish the log; instead exit Keyman). The log files are found in %LocalAppData%\Keyman\Diag and will be named system*.etl.
I’ve returned home now (was travelling for last two weeks) and am investigating this further. Unfortunately, the log file you sent did not appear to contain the necessary data to check this. One other thing to try is to disable “Deep TSF Integration” following the steps at https://help.keyman.com/knowledge-base/94 and see if that makes any difference.
We already disabled it in my OneNote problem ( Keyman with OneNote) and I still have it disabled.
And there we go – this happens when TSF integration is switched off. I’ve reproduced this here now. In this situation, Word is blocking the two diacritics which appear momentarily when you type the second
M which triggers the
rota group. (A future version of Keyman may optimise this output so that Word never sees this intermediate state.)
The good news is that we can implement a workaround. If you remove the rota group and the
+ any(vowAnU) rule you had, and instead implement the rota with these two rules, we avoid the intermediate state that worries Word and the rota works beautifully:
any(vowAnUD) + any(vowAnU) > index(vowelsDoUD,1)
+ any(vowAnU) > index(vowAnUD,1)
That helped! I deleted the TSF integration deactivation and it now works correctly in Word! As the TSF integration deactivation was no solution to the OneNote issue it’s anyhow of no use for me. (I still hope you will find a solution for OneNote too!)
The workaround proposal would ignore the corresponding dependence.
Only k+e+M+M should result in केँ
but: k+e+M+L would result in केँ too.
and: k+e+M+R would result in केँ too.
So for the input of doubling the same letter while using stores the
rota was used.
I hope I didn’t misunderstand your idea.
Yes, my bad. My workaround suggestion does break the rota model… Sorry! I cannot see any other good alternative without separating the M/L/R rules into 3 separate rules.
We’ll continue to research options for the OneNote issue (can you use the version of OneNote included with Office rather than the Windows Store one?)
Yes, I just got OneNote from office365 which seems to be OneNote 2016 and doesn’t automatically install, but it works correct! So I will give it a try.