Description: Moving from 7.0.4 to 7.2RC2, I have lost the ability to insert unicode symbols in Writer comments under Linux. I normally do this using the standard shift+ctrl+u shortcut, then the code for the symbol. This continues to work fine in the document area, but in shortcuts it now either does nothing (using the GTK3 interface) or just gives a "u" (using the X11 interface). Steps to Reproduce: 1. Create new writer document. 2. Create new comment. 3. Try to add unicode symbol using keyboard. Actual Results: Nothing happens or get a "u" Expected Results: Expect system to accept next few characters as a unicode character code. Reproducible: Always User Profile Reset: No Additional Info: Not interfere with my system shortcut.
What linux distro do you use? Did you update it? I mean you have LO 7.2 now. Did you get it after your linux distro update or you just installed 7.2 into your OS?
(In reply to Roman Kuznetsov from comment #1) > What linux distro do you use? Did you update it? I mean you have LO 7.2 now. > Did you get it after your linux distro update or you just installed 7.2 into > your OS? Current Debian testing (so effectively the new stable release), with a couple of packages like Libreoffice pulled from Experimental. I just tested stock versions from Libreoffice.org of 7.0.6, 7.1.5, and 7.2rc3, all using a new profile. Only 7.2 has this problem.
please provide an info from LibreOffice's Help->About dialog
Version: 7.2.0.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Debian package version: 1:7.2.0~rc2-4 Calc: threaded
I cannot replicate on Ubuntu 20.04/cinnamon desktop in 7.1 (from Ubuntu stable PPA), 7.2 (bibisect-linux-64-7.2, or 7.3 (compiled master) In a writer comment, I get the underlined u (Ctrl-shift-U) and it all converts into the expected Unicode character after hitting space (using A78C).
I continue to have the problem with 7.2.1.2 (Debian), but not with any version prior to 7.2. One change since 7.2.0.2 is that without the GTK3 package installed, I do get the underlined u as long as I press ctrl+shift+u, but as soon as I release a key it converts to a normal u character instead of waiting for the rest of the input for the unicode symbol. The cursor does not move at this point, so the u ends up after the cursor. With the GTK3 interace active, nothing at all visibly happens with ctrl+shift+u (as started with 7.2.0.2). I get exactly the same behavior with stock 7.2.2.1 with a fresh profile, including the GTK/Gnome integration difference.
I reproduce the bug exactly as described by bchemnet. Version: 7.3.0.3 / LibreOffice Community Build ID: 30(Build:3) CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 1:7.3.0~rc3-0ubuntu0.20.04.1~lo1 Calc: threaded
Confirm for LibreOffice Writer shipped with Ubuntu 20.10: Version: 7.4.2.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Ubuntu package version: 1:7.4.2~rc3-0ubuntu1 Calc: threaded
It does not only fail in comments but in text boxes and shapes in Writer too. And fails in Calc too. It works in frames in Writer. It fails in comments in Draw/Impress, but works in text boxes and shapes in Draw/Impress. tested with Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 17dfc9a9da009cc23d2222e3fb4e2cef9c97d581 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL threaded
This report should have had the keywords regression, bibisectRequest. Now due to this omission, the report languished without analysis for three years. Bibisected with linux-64-7.2 to 69c546e1e7a697217f273baa7c1729ff823efd76 weld annotation window With gtk3, in the normal Writer canvas, you can release Ctrl and Shift and type the code. When focusing in a comment, you have to keep Ctrl and Shift pressed when typing the code. Shift seems to uppercase the inserted character, so it's not a good workaround. Note that with the gen backend, keeping Ctrl and Shift pressed is the requirement even in the normal canvas! For some reason, KDE and Windows don't do anything at all with Ctrl+Shift+U, so I could not test them.
This sort of thing is likely an input engine issue, but it seems to work fine for me in gtk3, so I'm unsure now if the problem still exists?
Created attachment 197023 [details] how it looks for me, no need to hold anything once ctrl+shift+u pressed
Seems to have been fixed by now. Version: 24.2.6.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 4:24.2.6-0ubuntu0.24.04.1 Calc: threaded
Still not working for me in Writer comments, Calc formula bar, or Impress comments. It does as expected everywhere else that I have tried, including the main canvas, text boxes, shapes, individual Calc cells, and comments in Calc. Holding ctrl+shift does allow entry of the unicode in the Writer/Impress comments and Calc formula bar, as described in comment 10. Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 480(Build:1) CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Debian package version: 4:24.8.2-1 Calc: threaded
[Automated Action] NeedInfo-To-Unconfirmed
I tried like this: press Ctrl+Shift and type u, then release all of them, type 188 and press a space, and it works in text document, but also in the comment. Tested with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4924a9f73fae17c14cc445e2804d4025a17acd30 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Aslo with Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Cloph had a tip about using ibus, so I installed it. I changed in KDE's system settings "Input Devices" -> "Virtual Keyboard" to "IBus Wayland" and ran LibreOffice with SAL_USE_VCLPLUGIN=gtk3 QT_IM_MODULES=ibus and this made the inputting work even in a comment.
(In reply to Buovjaga from comment #17) > Cloph had a tip about using ibus, so I installed it. I changed in KDE's > system settings > "Input Devices" -> "Virtual Keyboard" to "IBus Wayland" and ran LibreOffice > with > > SAL_USE_VCLPLUGIN=gtk3 QT_IM_MODULES=ibus > > and this made the inputting work even in a comment. Oh, forgot to say I launched the ibus daemon with: ibus-daemon
So (in the gtk3 case where it still doesn't work) what distro (and version) is it happening in? I'm guessing it is a particular Input Method that causes the problem, and not one I (Fedora) have by default, so trying with the specific distro would likely help me see what the IM is to test with that one instead.
(In reply to Caolán McNamara from comment #19) > So (in the gtk3 case where it still doesn't work) what distro (and version) > is it happening in? > > I'm guessing it is a particular Input Method that causes the problem, and > not one I (Fedora) have by default, so trying with the specific distro would > likely help me see what the IM is to test with that one instead. If you are interested in my original non-working state, you can install EndeavourOS KDE edition (basically an easy to install Arch Linux): https://endeavouros.com/
I am using Devuan/XFCE. Per comment 18, I installed ibus and launched it. While ibus is running, I am able to add unicode to comments and the formula bar as expected (without holding ctrl+shift after the initial u). I blocked ibus several years ago because running it added unnecessary complexity and broke something at the time. Ideally a solution could be found that does not depend on ibus, but if most distros are installing ibus by default then perhaps recommending it as a dependency is the solution.