Bug 71437 - Dead keys not working
Summary: Dead keys not working
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
: 82787 144969 (view as bug list)
Depends on:
Blocks: Languages
  Show dependency treegraph
Reported: 2013-11-09 21:13 UTC by Bart Deruyter
Modified: 2022-04-29 11:07 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Bart Deruyter 2013-11-09 21:13:16 UTC
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: release
Comment 1 Urmas 2013-11-09 23:12:10 UTC
Does it work with US-International layout?
Does it work with a sane DE?
Comment 2 tommy27 2013-11-10 05:46:28 UTC
try upgrading to 4.1.3 as well.
Comment 3 Bart Deruyter 2013-11-10 06:52:36 UTC
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.
Comment 4 Tristan Miller 2014-02-07 16:50:52 UTC
This is possibly a duplicate of Bug 39407.
Comment 5 Tristan Miller 2014-02-07 17:02:54 UTC
I can reproduce this problem with LibreOffice (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:

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:

Comment 6 Federico Kereki 2014-06-16 00:46:50 UTC
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 &
Comment 7 Tristan Miller 2014-06-16 08:33:23 UTC
The workaround from Comment 6 works for me too.  Thanks!
Comment 8 Tristan Miller 2014-06-16 08:35:48 UTC
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.
Comment 9 Urmas 2014-08-21 11:54:36 UTC
*** Bug 82787 has been marked as a duplicate of this bug. ***
Comment 10 retired 2014-10-30 19:42:15 UTC
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 and see if this is still happening.
Comment 11 Tristan Miller 2014-10-31 08:35:30 UTC
LibreOffice isn't yet packaged by my distribution.  However, I did retest with LibreOffice (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.
Comment 12 Tristan Miller 2014-10-31 08:42:04 UTC
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.
Comment 13 tommy27 2014-10-31 09:53:52 UTC
Ok let's label this as RESOLVED WORKSFORME
feel free to report that bug in the xorg bugzilla
Comment 14 gustavo 2014-11-26 15:14:38 UTC
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 


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.

Comment 15 Josef 2014-12-12 10:59:22 UTC
Just tested with the new backport update (from today) for kubuntu, e.g. LibreOffice 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.
Comment 16 albondi2014 2015-02-15 22:08:32 UTC
this is still happening with version 

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.
Comment 17 peter 2015-03-25 13:59:11 UTC
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).]
Comment 18 Raoult 2015-04-01 13:00:30 UTC
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 
Comment 19 karel.k.rehor 2015-04-26 11:03:15 UTC
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. 


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.  


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
Comment 20 Chris Vanden Berghe 2015-05-28 08:28:40 UTC
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
Comment 21 vatbier 2015-07-16 20:37:28 UTC
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.
Comment 22 joaoboia 2016-02-12 16:37:28 UTC
Same on Arch Linux, Plasma 5.5.4 and libreoffice-still 5.0.4-2. 

Neither libreoffice-kde nor ibus installed. 

Portuguese keyboard.
Comment 23 samuraiii 2016-11-15 06:01:56 UTC
I have here simular probem on Gentoo:
I am unable to input accented letters into app-office/libreoffice- 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...
Comment 24 MarSarK 2016-12-19 10:24:15 UTC
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.
Comment 25 Bas Roufs 2016-12-20 20:37:31 UTC
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 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! 


Does someone know any other fix or effective workaround, apart from copy-paste?


Bas G. Roufs.
Comment 26 tommy27 2016-12-21 06:24:00 UTC
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.

hence I revert status to NEW
Comment 27 samuraiii 2016-12-21 16:52:43 UTC
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?
Comment 28 Xisco Faulí 2017-11-08 07:59:28 UTC
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.
Comment 29 Bart 2018-03-25 19:32:49 UTC
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.
Comment 30 Yassine Chaouche 2019-02-26 14:01:01 UTC

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
Linux Mint 17 Qiana
Comment 31 Xisco Faulí 2019-03-12 17:24:05 UTC
Any chance to test this issue in LibreOffice from https://www.libreoffice.org/download/download/ ? it now uses KDE5 and this issue might be fixed...
Comment 32 Tristan Miller 2019-04-30 05:29:31 UTC
Everything still works fine for me with LibreOffice (running on KDE Plasma 5.15.4, KDE Frameworks 5.57.0, Qt 5.12.2, openSUSE Tumbleweed), whether or not XMODIFIERS is set.
Comment 33 Brad 2019-08-06 17:11:27 UTC
I was having this problem on KDE Neon (a Ubuntu/Debian derivative) on Plasma 5.16.3 and Libreoffice

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.
Comment 34 Thomas Capricelli 2019-08-19 12:52:49 UTC
i've had this problem on gentoo for months, if not years. Currently using libreoffice under plasma 5.16
Comment 35 Hans Deragon 2021-10-31 19:45:57 UTC
Confirming still having this problem with:

Version: / 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.
Comment 36 Ivan 2021-11-09 14:07:08 UTC
I confirm the symptoms from comment 35. After the upgrade to (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.
Comment 37 Dieter 2021-12-16 15:54:45 UTC
*** Bug 144969 has been marked as a duplicate of this bug. ***
Comment 38 Sergio Daroca 2022-02-28 03:26:28 UTC
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

Version: / 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 in the same computer works correctly
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
Comment 39 Marcelo 2022-04-29 11:02:41 UTC
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, pt-BR language.
Comment 40 Marcelo 2022-04-29 11:07:30 UTC
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.