Bug 147647 - Compose key creates a dot and not the desired character
Summary: Compose key creates a dot and not the desired character
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Shortcuts-Accelerators Shortcuts-AltGR
  Show dependency treegraph
Reported: 2022-02-24 23:27 UTC by Jackson Sul
Modified: 2022-03-11 23:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

LibreOffice compose key attempt (1.56 KB, image/png)
2022-02-24 23:28 UTC, Jackson Sul

Note You need to log in before you can comment on or make changes to this bug.
Description Jackson Sul 2022-02-24 23:27:12 UTC
When the compose key is activated in order to produce special characters, an underlined middle dot character (·) and a blank space next to it are shown. In LibreOffice Writer, if the compose key is invoked at the end of a line with other lines below it, after the key sequence is entered the cursor just ends up on the next line and the · remains, while the character the user tried to enter does not appear. 

Steps to Reproduce:
1. Open LibreOffice Writer
2. Hit Enter a few times to create some lines
3. Click on any line besides the last one
4. Invoke the compose key to make a special character

Actual Results:
A · will appear and stay there, while the cursor moves down to the next line.

Expected Results:
The special character the user wanted to make using the compose key should appear.

Reproducible: Always

User Profile Reset: Yes

Additional Info:
If the compose key is invoked at the end of the final line of a document or the middle of a line, the character still does appear properly: it's at the end of a line when there are more below where the problem always occurs. This makes editing very frustrating.

This seems to be a Writer-only bug: Calc (in a cell), Impress, and Draw at least all properly make the desired character when the compose key invoked at the end of a line with others below it.

This also does not affect any non-LibreOffice application that I can find, such as other text editors.

LibreOffice Version: / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.2.5-0ubuntu0.21.10.1
Calc: threaded
OS: Kubuntu 21.10
KDE Plasma Version: 5.22.5
Comment 1 Jackson Sul 2022-02-24 23:28:20 UTC
Created attachment 178526 [details]
LibreOffice compose key attempt

The compose key was invoked on the third line to make an "é"; instead the dot remains and the cursor moved down a line.
Comment 2 V Stuart Foote 2022-03-09 17:11:15 UTC
Not clear misbehavior of "Dead keys", or <AltGr> composition including some notional "compose key" depending os/DE implementation is OUR BUG.

Cross platform we provide the very functional <Alt>+X direct conversion of Unicode (for bug 73691); as well as the chart based character picker in LibreOffice's Special Character dialog, where a split-key pick list provides "favorites" and "recents" for efficient input.

Likewise we don't support native macOS "PressAndHold" (see also bug 42437) nor any of the many os/DE extensions supporting special character input.

I'd throw any mishandling of an os/DE "Compose key" into the same pot with the <AltGr> mishandling of special character composition on Windows.
Comment 3 Jackson Sul 2022-03-11 23:02:50 UTC
I think you are correct: on further testing I now don't believe it is a LibreOffice bug, but something involving KDE since on older versions there the newest versions of LibreOffice work fine.

For the record, the Linux compose key has worked just fine in LibreOffice since its inception (and on OpenOffice before it). Much easier and quicker than needing to select a character using a graphical interface or an obscure alt keycode string, especially useful for us who need to write in more than one language.