Problem description: Steps to reproduce: 1. fresh install of libreoffice, language dutch, keyboard settings in KDE set to Belgian default. 2. create new document 3. try to type ruïnes Current behavior: results in runes or ru nes Expected behavior: ruïnes Conclusion: dead keys not working, tested in other applications, they all work, so keyboard settings are correct, only not for libreoffice. Operating System: Linux (Other) Version: 4.1.2.3 release
Does it work with US-International layout? Does it work with a sane DE?
try upgrading to 4.1.3 as well.
Running KDE 4.11.2 Workaround found: uninstall libreoffice-kde integration. The core of the issue should then be found in the libreoffice-kde package.
This is possibly a duplicate of Bug 39407.
I can reproduce this problem with LibreOffice 4.1.4.2 (KDE 4.12.1, openSUSE 13.1). This must have started after a fairly recent upgrade, as I use dead keys in LibreOffice all the time but only noticed the problem now. Uninstalling the libreoffice-kde4 package as suggested in Comment #3 doesn't work around the problem for me. The problem has also been reported repeatedly on Ask LibreOffice: http://ask.libreoffice.org/en/question/14956/dead-keys-wont-work/ http://ask.libreoffice.org/en/question/19326/no-dead-keys-in-libreoffice-but-ok-in-other-apps/ As with Bug 39407 I suspect this problem has something to do with IBUS. There are reports lately that many other applications (Skype, etc.) stop responding to dead keys according to the presence or absence of certain IBUS packages. The following bug reports may be relevant: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/335732 https://code.google.com/p/ibus/issues/detail?id=526
I can verify this problem, with the spanish language; dead keys stop working, and you cannot enter accented characters. From information gleaned elsewhere, the solution is invoking LibreOffice as follows: unset XMODIFIERS && libreoffice4.2 &
The workaround from Comment 6 works for me too. Thanks!
Oh, I should add that before unsetting XMODIFIERS its value on my system was "@im=ibus", which seems to support my suspicions in Comment 5 that this problem is something to do with IBUS.
*** Bug 82787 has been marked as a duplicate of this bug. ***
Why is this unconfirmed if a second user has reproduced the problem and a third user has opend a second bug now marked duplicate? Setting to NEW. Everybody running into this, please re-test with 4.3.3.2 and see if this is still happening.
LibreOffice 4.3.3.2 isn't yet packaged by my distribution. However, I did retest with LibreOffice 4.3.2.2 (KDE 4.14.2, openSUSE 13.1) and was no longer able to reproduce the problem. So for me dead keys are working again, even with XMODIFIERS set to @im=ibus.
Actually, I should clarify that dead keys work *in general* – there are still some problems with specific combinations which lead to incorrect compositions. For example, AltGr+' c produces ç instead of ć as expected. This has been reported on the bug trackers of various GNU/Linux distributions (see for example <https://bugzilla.novell.com/show_bug.cgi?id=869133> and <https://bugzilla.redhat.com/show_bug.cgi?id=917130>. Is this something I should file a new bug for here, maybe in the xorg package? The problem is that I'm not sure whether it's X.Org or some other component which is causing the problem.
Ok let's label this as RESOLVED WORKSFORME feel free to report that bug in the xorg bugzilla
I confirm this bug on Ubuntu 14.04 and I the confirm workaround from Federico Kereki to work. From the comments it doesn't seem clear who should fix this bug. Are we sure about which component is failing? If nothing is lost from using unset XMODIFIERS should libreoffice ship with this on the startup script? If this is fixed on 4.3.3.x, how did it get fixed? Did libreoffice fix it or will it be broken again once it is packaged by the distributions? I'm reopening this since it is a serious issue that needs to be clarified. Reference: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1396637
Just tested with the new backport update (from today) for kubuntu, e.g. LibreOffice 4.2.7.2 buildID 420m0(Build:2) The problem is still there, though pay attention that typing with dead keys works initially, but stops working after a couple of minutes. I am using a US-international keyboard and try typing German umlauts with it. It seems that it shifts to a different keyboard layout after a minute or two. It is still possible to type the Umlauts, but they are now accessible with the "AltGr" key and are located near (not on) the corresponding a,o,u keys. I am amazed to get a backport update without this fixed. After all, if you need to type German (or many other languages) with a US keyboard you probably want to use the US international layout and LibreOffice is pretty much useless if this does not work.
this is still happening with version 4.3.3.2 As Comment 15 says, at starting it works fine you can enter accents and letter ñ (in my case Spanish) then after some time they didn't work at all. I am able to switch to Chromium right away and type dead keys. I am running on lubuntu 14.10.
I confirm this bug. I use Kubuntu with KDE version 4.13.3 Dead keys are not working in the standard installation of Kubuntu. It took me a while to come up with the thought that the KDE integration package might be the source of the problems,since more problems have been reported with it. After de-installing that package, the dead keys worked fine again. The magic line for this is: sudo apt-get remove libreoffice-kde [ After that you can probably install another integration package that does the job a bit better (like libreoffice-gtk).]
Character modifiers include overlining simple, double, ondulated, etc. most of the remnant useless. In maths we use caret ^ over a variety of letters, for instance M^ . It should not be rejected : A^ does work and yields Â.
I have been having this problem since installing Ubuntu 14.10 with unity and ibus and with language packs for Czech and French. I often write documents in Czech, French and English and have been particularly having problems with key combinations on a Czech keyboard for characters like Ď, ó, ň, etc. After a while they simply stop working. I found that if I opened a second document simply for testing dead keys, I could get them to work properly for a few strokes when I switched back to the main document I was working on. But then after a hundred or more strokes the dead keys no longer functioned and once again I would have to switch to the spare document to try them once and again they would work for a few more keystrokes. WORK AROUND Following on Frederico Kereki's comment #6 and Tristan Miller's I looked into unity configuration settings and found ibus can be disabled with Language Support > Keyboard input method system switch from IBus to NONE. After a reboot and reopening libreoffice writer from the launcher I've been working for a couple of hours without this issue showing up again. No need to open the terminal and start libreoffice from the command line. SYSTEM INFO ii ibus 1.5.8-2ubuntu2 amd64 Intelligent Input Bus - core ii libreoffice-core 1:4.3.3-0ubuntu1 amd64 office productivity suite -- arch-dependent files
I can reproduce this bug on a fresh Kubuntu 15.04 installation: 1) install Kubuntu 15.04 2) select keyboard 'English (US, international with dead keys) 3) dead keys work in all applications I tested (incl. Firefox, Thunderbird, Kate, Konsole, Vi) but NOT in Libreoffice
Kubuntu 15.04 here, language English, keyboard Belgian, with ppa kubuntu-backports latest KDE plasma. Dead keys only work in libreoffice if I uninstall libreoffice-kde and install libreoffice-gtk. ibus is NOT installed. im-config (or KDE launcher>Applications>Settings>Input Method): active configuration: missing normal automatic choice: none Add this to Most Annoying Bugs (or set priority to Highest) please. This bug is already 5 years old.
Same on Arch Linux, Plasma 5.5.4 and libreoffice-still 5.0.4-2. Neither libreoffice-kde nor ibus installed. Portuguese keyboard.
Hello, I have here simular probem on Gentoo: I am unable to input accented letters into app-office/libreoffice-5.1.4.2 running on kde-plasma/plasma-meta-5.7.5 using czech (cs_CZ) keyboard and locale. Accented letters which are "natural" to keymap are input OK (eg. key 5 - on us keyboard - is mapped to ř key on cz), on keymap) I would usually use <Shift>+<´>(mapped as <=> on us) and then <n> key combination to compose "ň". This works everywhere else (as I know), but libreoffice, this key combination results into "n". Reproducible: Always Steps to Reproduce: 1.Switch input keymap to cz (default variant) 2.Open lowriter 3.Press <Shift>+<=> and then <n> (or <Shift>+<´> and then <n>) Actual Results: Character "n" input into document. Expected Results: Character "ň" input into document. NO ibus here and no XMODIFIERS in env...
I have also problem with writing characters with hooks and acute accents and also fails opening files where are czech characters in the filename. I rebuild libreoffice with flags -kde -gtk +gtk3 as a workaround. May be this is a kdelibs or Qt lib problem.
Hello Everybody. At this dead keys problem, I stumble upon now. Ever since a few weeks, I work at a fresh install of Kubuntu 16.04 - along with KDE Plasma 5.6.5, installed via the Kubuntu ppa backports. Dead keys work in all applications except LibreOffice - version 5.1.4.2. I am using the keyboard "USA International". A character like ä is no problem in most of the applications. They same applies for e.g. the double quotation mark (") - the key that needs to be pressed first in order to get ä. However, in Libreoffice in my configuration as summarised here, signs like " and ä do not show up. I have similar problems with characters like à, é, ë, ñ. č, etc. Also signs like `, ~ or ' do not show up in Writer or any other Libreoffice application. It does not matter whether I work in Dutch, English, Italian, French, German or whatever - the problem remains the same - however, as I said, just in LibreOffice. The only workaround I have found so far is editing a text in another application (Kate, BlueFish or whatever) and copy-pasting it into LibreOffice. The workaround mentioned in comment 6 does not work here. I DO manage to invoke libreoffice from the command line - "libreoffice" does end up in the following sequence: ======================================== bas@Viaconsensus-transit:~$ unset XMODIFIERS && libreoffice & [1] 5908 bas@Viaconsensus-transit:~$ W: Unknown node under /registry/extlang: deprecated W: Unknown node under /registry/grandfathered: comments W: Unknown node under /registry/grandfathered: comments X Error: BadMatch (invalid parameter attributes) 8 Major opcode: 42 (X_SetInputFocus) Resource id: 0x7c02342 ======================================== However, the problem is not being fixed like this. Variants like "libreoffice4.2" or "libreoffice5" do not produce any result. On the other hand - the simple command line command "libreoffice", without anything else, is already enough to invoke that application. During my main working session of today, Tuesday 20 December 2016, I have done so by purpose. Here is the report I get from this working session. ======================================= bas@Viaconsensus-transit:~$ libreoffice W: Unknown node under /registry/extlang: deprecated W: Unknown node under /registry/grandfathered: comments W: Unknown node under /registry/grandfathered: comments X Error: BadMatch (invalid parameter attributes) 8 Major opcode: 42 (X_SetInputFocus) Resource id: 0x7404614 X Error: BadMatch (invalid parameter attributes) 8 Major opcode: 42 (X_SetInputFocus) Resource id: 0x7406fbd X Error: BadMatch (invalid parameter attributes) 8 Major opcode: 42 (X_SetInputFocus) Resource id: 0x74079cf Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. kbuildsycoca4 running... LibreOffice(2110) KSambaSharePrivate::findSmbConf: KSambaShare: Could not find smb.conf! X Error: BadMatch (invalid parameter attributes) 8 Major opcode: 42 (X_SetInputFocus) Resource id: 0x741bbd6 bas@Viaconsensus-transit:~$ libreoffice W: Unknown node under /registry/extlang: deprecated W: Unknown node under /registry/grandfathered: comments W: Unknown node under /registry/grandfathered: comments LibreOffice(3111) KSambaSharePrivate::findSmbConf: KSambaShare: Could not find smb.conf! bas@Viaconsensus-transit:~$ ========================================= Does someone know any other fix or effective workaround, apart from copy-paste? Yours. Bas G. Roufs.
please do not mess with bug status. NEEDINFO is not the correct thing. please read this to learn what the single status label mean in this bug tracker. http://bit.ly/2hpCkTh hence I revert status to NEW
I can almost certainly confirm linkage with some component of plasma desktop (Qt toolkit). I have seen working instance on Arch with Gnome 3 and rebuilding libreoffice on gentoo as suggested in https://bugs.documentfoundation.org/show_bug.cgi?id=71437#c24 also works (effectively dropping kde/plasma support from package)... Should we report this somewhere in Qt wrold?
Is this issue still reproducible with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version.
The bug still happens with libreoffice 6.0.2 on Arch using: - Plasma 5.12.3 - KDE frameworks 5.44 - Qt 5.10.1 Every application, including firefox, xterm and gimp works fine, libreoffice ignores dead keys. Setting SAL_ALTGR_COMPOSE does nothing.
Hello, Confirmed here with libreoffice 6.1 downloaded from the libreoffice website and running libreoffice from the KDE Menu. However, if I run libreoffice from the command line then dead keys will work. I have retrieved the environement variables from /proc/$pid/environement of each process and pasted them here (after doing a sort to ease comparison with diff tools) : https://www.diffchecker.com/e4gWwqBZ What caught my attention was the difference in the language variables LC_ALL, LANGUAGE and LANG. Values like en_DZ.UTF-8 seemed false (I presume this should read "algerian english", which doesn't make sense ?) What I did is fix the langauge strings in .kde/env/setlocale.sh and restart my KDE session. Dead keys work again in libreoffice. KDE 4.13.2 Libreoffice 6.1.4.2 Linux Mint 17 Qiana
Any chance to test this issue in LibreOffice 6.2.1.2 from https://www.libreoffice.org/download/download/ ? it now uses KDE5 and this issue might be fixed...
Everything still works fine for me with LibreOffice 6.2.3.2 (running on KDE Plasma 5.15.4, KDE Frameworks 5.57.0, Qt 5.12.2, openSUSE Tumbleweed), whether or not XMODIFIERS is set.
I was having this problem on KDE Neon (a Ubuntu/Debian derivative) on Plasma 5.16.3 and Libreoffice 6.0.7.3. I am using e_CA.UTF-8 and fr_CA.UTF-8 locales, and the Canadian multilingual keyboard. Launching Libreoffice from the command line gave me these warnings: I18N: Operating system doesn't support locale "" I18N: Operating system doesn't support locale "en_US" I don't have any idea what the en_US locale has to do with accented characters, but building the en_US ISO-8859-1 locale fixed the problem for me (I had only built en_US.UTF-8). To do this on a debian or ubuntu based distro, run dpkg-reconfigure locales and select en_US ISO-8859-1 as well as any other locales you are using.
i've had this problem on gentoo for months, if not years. Currently using libreoffice 6.2.4.2 under plasma 5.16
Confirming still having this problem with: Version: 7.2.2.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.utf8); UI: en-US Ubuntu package version: 1:7.2.2~rc2-0ubuntu0.20.04.1~lo1 Calc: threaded OS: Linux Ubuntu 20.04 LTS. However, in the main windows the dead keys are working. It is on some side widgets they are not. For instance: - In writer, dead keys work when typing in the main text area. However, they do not work in comment boxes. - In Calc, dead keys work when typing in the cell. If typing in the upper formula bar, they do not work. Tried 'unset XMODIFIERS' to no vail.
I confirm the symptoms from comment 35. After the upgrade to 7.2.2.2 (Ubuntu 21.10), dead keys stopped working on Writer comments (they still work fine in the main text and other areas of the program, as well as any other application). Solutions offered in this thread, such as unset XMODIFIERS do not work.
*** Bug 144969 has been marked as a duplicate of this bug. ***
Same thing, accents not working, on comment boxes only, on my Linux Mint Debian Edition 4. LMDE 4 Debbie. Kernel: 4.19.0-18-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Cinnamon 5.0.7 wm: muffin dm: LightDM Distro: LMDE 4 Debbie base: Debian 10.2 buster LibreOffice Version: 7.2.5.2.0+ / LibreOffice Community Build ID: 711f8d38e9451cd2fd39b6963d2a3fc166f04cb1 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded However, version 6.1.5.2 in the same computer works correctly Versión: 6.1.5.2 Id. de compilación: 1:6.1.5-3+deb10u7 Subprocs. CPU: 4; SO: Linux 4.19; Repres. IU: predet.; VCL: gtk3; Configuración regional: es-ES (es_ES.UTF-8); Calc: group threaded
I'm experiencing a similar problem that might be related to this one. Typing a dead key at the very end of a paragraph will send the cursor to the beginning of the next paragraph. The first character typed after the dead key will be "eaten" and not displayed at all. The following characters will be placed in the beginning of the paragraph after the one where the dead key was typed. I'm unable to type any accented characters at the end of a paragraph, unless I add some blank spaces before the paragraph end marker and type my text before them. Then dead keys will work as they should. Dead keys are working fine in other applications and also work ok in LibreOffice if there are no paragraphs after the one being typed, or if I'm typing anywhere in a paragraph other than at its very end. Running Kubuntu 21.10 and LibreOffice 7.3.2.2, pt-BR language.
Sorry, forgot to say that my last comment reffers to LibreOffice Writer. I've just tested it in Impress and the problem can't be reproduced there.
This is an oldie but there were some fixes in bug 145580 from LO 7.2.7 and in bug from 7.4.0. I think it deserves NeedInfo, for a retest. Please try Lo 7.2.7 or 7.3 and not if it works now for you. If it doesn't, please first test 7.4 from https://dev-builds.libreoffice.org/daily/master/current.html.
(In reply to Timur from comment #41) > This is an oldie but there were some fixes in bug 145580 from LO 7.2.7 and > in bug from 7.4.0. I think it deserves NeedInfo, for a retest. > Please try Lo 7.2.7 or 7.3 and not if it works now for you. If it doesn't, > please first test 7.4 from > https://dev-builds.libreoffice.org/daily/master/current.html. Seems resolved for me in 7.3.3.2 (Ubuntu build)
(In reply to Marcelo from comment #39) > I'm experiencing a similar problem that might be related to this one. Typing > a dead key at the very end of a paragraph will send the cursor to the > beginning of the next paragraph. The first character typed after the dead > key will be "eaten" and not displayed at all. The following characters will > be placed in the beginning of the paragraph after the one where the dead key > was typed. This problem affects LibreOffice 7.2.5.1, which is distributed with the current version (15.4) of openSUSE Leap. I have posted a bug report requesting that the Leap packagers upgrade or backport a patch: https://bugzilla.opensuse.org/show_bug.cgi?id=1202295
I tested and confirm that the dead keys now seam to work everywhere: - In writer, dead keys work when typing in the main text area and in comment boxes. - In Calc, dead keys work when typing in the cell and in the upper formula bar. Tested on: Version: 7.3.5.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.utf8); UI: en-US Ubuntu package version: 1:7.3.5~rc2-0ubuntu0.20.04.1~lo1 Calc: threaded Who is on authority here to mark this bug as RESOLVED?
Marking RESOLVED WFM based on Comment 42 and Comment 44.
Sorry to disappoint, I am still having this problem. My keyboard is pt-BR when I try to type an accent a quote is generated and my cursor is sent to a new paragraph. None of the workarounds mentioned here worked for me. My OS is OpenSuse 15.4: Version: 7.4.3.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded
(In reply to gweberbh from comment #46) > Sorry to disappoint, I am still having this problem. My keyboard is pt-BR > when I try to type an accent a quote is generated and my cursor is sent to a > new paragraph. Does the problem occur only when you type a dead key at the end of a paragraph, or does it also occur when typing a dead key in the middle of a paragraph?
LibreOffice 7.4.3.2, OpenSuse Leap 15.4, KDE Plasma 5.24.4: Typing a character with acute, e.g. é, a) at the end of a paragraph or table cell: ´ is written, the character beneath it is swallowed. b) at some position preceding the end of paragraph, including in a table cell: works as expected. Typing a character with any other diacritic, e.g. è, ê: works as expected.
Before finding the discussion starting at comment 39 I filed an new bug (156913) for what seems to be the same problem as described there. The workaround I found is to uninstall libreoffice-qt5. libreoffice-gtk3 can be installed for a similar, altough not as well integrated, interface.