Garbled Output with Later Versions of LibreOffice in Linux

[davidkitfriedman]

Summary

I found that in Linux with newer version of LibreOffice (e.g. Version: 6.1.5.2) there's a problem with words that need backspace deletions. E.g. "RAL" maps to "ural" and "RAL/HRAOE" maps to "Raleigh", so it needs to delete the initial "u". But for some reason it doesn't work properly and comes out garbled like: "ural Ral".

The problem doesn't exist for me with LibreOffice Version: 5.4.7.2.

I followed the instructions Installing in parallel/Linux on the Document Foundation's wiki, and tried 5.4.7.2 because that's currently the latest within version 5.

It didn't seem to be an issue with AutoCorrect.

Plover Version

Plover 4.0.0.dev8+66.g685bd33

System

• Debian GNU/Linux Buster Alpha 5 with kernel 4.19.0-4-amd64 running OpenBox on this Dell Inspiron 1545.

• Running Plover via AppImage.

• Using Zalman ZM-K600S keyboard.

• The same thing also happened on my Dell Venue 5130 Tablet running Ubuntu with Bionic Beaver, and the same workaround of going with LibreOffice Version 5.4.7.2 resolved the issue (using the same ZM-K600S keyboard). The tablet is a 32-bit machine.

Follow-Up

If any more system data is needed let me know and I'll seek to write back on it in due course.

[SeaLiteral]

It could be a bug in LibreOffice. Try manually typing the keystrokes that Plover would send. Slowly enough to see how it reacts to each of them. Maybe you should report it to LibreOffice as I imagine Plover might not be the only tool it affects.

[davidkitfriedman]

It works fine if Plover isn't running, and one just uses regular typing.

I could add that the keyboard I'm using is the Zalman ZM-K600S.

[SeaLiteral]

I'm thinking it's either an autocomplete issue or an input method issue. Is ibus, xim or fcitx running? I've had issues with both ibus and fcitx, but that was when typing into firefox.

[davidkitfriedman]

I don't see any of ibus, xim, or fcitx when running ps -e.

It doesn't happen when using vi (which is what Mirabi Knight uses as far as I know) or other terminal based editors like nano, emacs, etc.

[benoit-pierre]

If the problem is only with later versions of LibreOffice, I think it's safe to assume it's a bug in LibreOffice.

Does it happen when simulating input with xdotool? Use sleep 5; xdotool type --delay=0 testing in a terminal and quickly focus LibreOffice.

Additionally, you could try with a more recent version of LibreOffice (maybe using the AppImage).

[davidkitfriedman]

I didn't see this till a couple of days ago when I googled my name, and saw it listed on my Github page. I didn't know that there had been a follow-up on it back in July.

Anyway, I tested it with xdotool type (it doesn't seem to me that it matters where Plover is enabled or not as xdotool type isn't affected by that), and it didn't happen with xdotool type.

So xdotool type --delay=0 Raleigh comes out as correctly as "Raleigh" in the LibreOffice window.

I think it has something to do with whether characters need to be deleted or not. For my dictionary RAL maps to "ura" and so then when hitting HRAOE it needs to delete that first "u" in "ura", and it has trouble doing that.

For me it's not really a high priority issue in any way, because the earlier version of LibreOffice is fine. The work around mentioned above is okay.

[user202729]

• The issue does happen with xdotool. Try xdotool key --delay 0 BackSpace a.
• Yes, should be fixed on LibreOffice's side too. (related LibreOffice bug: 104735 – major stuttering: leaves out characters if you type moderately fast, takes 5 seconds for deleted characters to disappear, 99222 – While typing, some characters appear out of order from how they are typed., 136687 – Order of characters typed into comments scrambled)
• You can merge Add config option for sleeping between key presses #1132 and set the delay to 12ms (xdotool's default), the issue doesn't seem to happen with that delay (and larger)
• Unlike the other issue, in this case only the backspaces are processed out of order compared to the other keys, so it's possible to only delay 12ms after send_backspace (and nowhere else) to reduce the delay time to type the content, although this is really application-specific.