Comment balloon doesn't allow Latin characters as ã, é, à, ... I am using the LibreOffice Writer 7.2.2 build 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 on Ubuntu 20.04. The OS and LibreOffice installation are default English language, but I have installed the Portuguese language spelling. The document text works fine, recognize spelling Portuguese/English typing and allow me any character of my keyboard or combinations ñ (for Spanish), ã, é, à (large used on Portuguese). The issue is on the comment balloons of revisions tools, it doesn't recognize this characters. Workflow: to type ã, I have to first type ~ and after a on my keyboard. On text works fine but on the balloons only type "a" after this combination.
No issue here.. but there is a similar bug report somewhere
I can reproduce with Czech character ň in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: c13db6e792cc347ffff4585f23866f195651f21f CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo Work in Version: 4.1.0.0.alpha0+ Build ID: fa72fc3eddbfabb82193452a4ba993b11d1584d -> regression
This seems to have begun at the below commit. Adding Cc: to Caolán McNamara; Could you possibly take a look at this one? Thanks 64bb6290805110805ac8c464f9272226504e3fde is the first bad commit commit 64bb6290805110805ac8c464f9272226504e3fde Author: Jenkins Build User <tdf@pollux.tdf> Date: Sat Feb 6 13:27:23 2021 +0100 source 69c546e1e7a697217f273baa7c1729ff823efd76 https://gerrit.libreoffice.org/c/core/+/124485 Resolves: tdf#143443 size of comment box too tall after cut/paste
*** Bug 146344 has been marked as a duplicate of this bug. ***
This applies also to Greek characters in comment balloons AND in the spellchecking dialogue boxes - although it is possible to copy-paste accented characters from another LO window.
Presumably it's an input engine problem, but all the ones I try under a Fedora GNOME install work fine for me. It would probably be sufficient if someone could find a setup which reproduces this in a vm from https://www.osboxes.org/ (or from one of those as a starting point with some fairly minimal extra install steps)
I reproduce in Linux, only with modifier key (right Alt), same as in bug 131620 (where solution doesn't work in my case).
(In reply to Caolán McNamara from comment #6) > Presumably it's an input engine problem, but all the ones I try under a > Fedora GNOME install work fine for me. > > It would probably be sufficient if someone could find a setup which > reproduces this in a vm from https://www.osboxes.org/ (or from one of those > as a starting point with some fairly minimal extra install steps) Hello Caolan, run the X11 system, then I can reproduce: - download Ubuntu at osboxes.org - at start screen change DE to Ubuntu on Xorg
*** Bug 146616 has been marked as a duplicate of this bug. ***
*** Bug 146871 has been marked as a duplicate of this bug. ***
*** Bug 147330 has been marked as a duplicate of this bug. ***
Confirm this bu it in: Version: 7.3.0.3 / LibreOffice Community Build ID: 30(Build:3) CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US 7.3.0-5 Calc: threaded
This first should also attempt https://bugs.documentfoundation.org/show_bug.cgi?id=147604
* This fix...
When using the keyboard layout "US International with dead keys" in Linux (Debian testing, X11), I can enter composite characters except double and single quotes. With this keyboard layout, quotes need to be escaped by entering first the quote character, then space so that they aren't used as accent characters. This works as it should in the main document of Writer, but not in comments.
I think I have it now, I can reproduce with the comment #15 scenario with GDK_BACKEND=x11 and GTK_IM_MODULE=xim Missing calls to gtk_im_context_filter_keypress
*** Bug 147604 has been marked as a duplicate of this bug. ***
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dc99d27f04b47c173de934a19b6d6a3cc572c20a Resolves: tdf#145580 need to use gtk_im_context_filter_keypress It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed in trunk, backports to 7-3 and 7-2 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/8badc2314961e87e0b2cc01164442d97e20f9419 Resolves: tdf#145580 need to use gtk_im_context_filter_keypress It will be available in 7.3.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/e388a4d6d7ab355fc7aa5fca05e06070693847e9 Resolves: tdf#145580 need to use gtk_im_context_filter_keypress It will be available in 7.2.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #21) > Caolán McNamara committed a patch related to this issue. > It has been pushed to "libreoffice-7-2": > > https://git.libreoffice.org/core/commit/ > e388a4d6d7ab355fc7aa5fca05e06070693847e9 > > Resolves: tdf#145580 need to use gtk_im_context_filter_keypress > > It will be available in 7.2.7. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. Unfortunately it didn't work. I install the 2.7.2 by this link https://dev-builds.libreoffice.org/daily/libreoffice-7-2/Linux-rpm_deb-x86_64@86-TDF/2022-03-01_13.42.21/libreoffice-7-2~2022-03-01_13.42.21_LibreOfficeDev_7.2.7.0.0_Linux_x86-64_deb.tar.gz and the bug remains.
(In reply to Caio from comment #22) > Unfortunately it didn't work. I install the 2.7.2 by this link The file name contains the time when the build was made: 2022-03-01_13.42.21 While the time of the commit notification is: 2022-03-02 03:31:39 UTC Please test with a newer daily build.
This bug still on version 7.3.1.3 build https://gerrit.libreoffice.org/gitweb?p=core.git;a=log;h=a69ca51ded25f3eefd52d7bf9a5fad8c90b87951 System tested Ubuntu 20.04.4 LTS GNOME 3.36.8 Installation language: English Keyboard layout: Portuguese Brazilian ABNT2
If it will be present just at 7.3.2 as Caolán McNamara said, please, remark as FIXED.
Yes, you can also find the target versions in the Whiteboard field.
(In reply to Aron Budea from comment #26) > Yes, you can also find the target versions in the Whiteboard field. Also tested in version 7.3.1.3 and the bug is still there. By the way, my keyboard has American layout: English (US, international, with dead keys) As I pres AltGr + N, I get ñ (in text and in the commentaries). The same with AltGr + , = ç. But in the commentaries there's no way to type Shift + ~ and n and get ñ. Neither Shift + ~ and a to get ã ou even ' + a to get á. In the text it works fine. It doesn't in the commentaries.
I think it's clear that target is 7.3.2 so no point in confirming that bug is still there in 7.3.1. You may already take 7.3.2 from https://www.libreoffice.org/download/download/?type=win-x86_64&version=7.3.2&lang=en-US.
I confirm that it is fixed in: Version: 7.3.2.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US 7.3.2-1 Calc: threaded
(In reply to elmau from comment #29) > I confirm that it is fixed in: > > Version: 7.3.2.2 / LibreOffice Community > Build ID: 30(Build:2) > CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > 7.3.2-1 > Calc: threaded Indeed, it's fixed