Bug 139577 - Korean/hangul input has issues for Libreoffice
Summary: Korean/hangul input has issues for Libreoffice
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.0.3.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-13 06:07 UTC by Potassium1
Modified: 2021-09-20 09:03 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
This a video using fcitx and LibreOfice to demenstrate the issue (574.02 KB, video/x-matroska)
2021-01-13 06:19 UTC, Potassium1
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Potassium1 2021-01-13 06:07:19 UTC
Description:
I love GNU/open source products, and LibreOffice is one of my favorite examples to present the beauty of these projects. However, a serious bug in LibreOffice is making life difficult of me to present LibreOffice to my friends, since they use Korean. 
The translations are O.K, however when using Korean while writing a document, the highlighted Korean input cursor fails to input when the user selects a different word leaving the current cursor.
I believe the person who is kindly reading this bug report may not be familiar with How Korean input works... So, for some basic knowledge to understand this bug, I will explain how Korean input works.
I use Fcitx for Korean input, but other input frame work such as i-bus will do the same thing. For example, in English, we just type and the characters will just show up on the screen. but in Korean, these 'characters' need to be combined to make sense. 
한 this is a example of a 'combined' readable Korean word
ㅎㅏㄴ  this a the same characters but not combined, notice the 'ㅏ'goes next to 'ㅎ' and 'ㄴ' goes under the 'ㅎ' + 'ㅏ'
The input framework creates a highlighted cursor (I'm not sure if they call this a cursor) and within the cursor, the Korean characters get combined and when the user presses enter or continues to type, the character that is combined (like the example above, '한')appears.
The main bug is when the user moves the cursor to a different location via mouse click, the highlighted text, that contains the last Korean characters the user was inputing is not left behind, but disappears, and sometimes reappears when in the new cursor location, forcing the user to delete the unwanted text.
To be honest, this is not a bug only happening in LibreOffice programs almost every program in GNU/Linux (besides Firefox) has this Korean input issue, but this issue usually gets ignored, because the developers usually think the existence of a  "easy" workaround to fix the issue makes the bug unnecessary to fix. I understand their conclusion, since they have major bugs(crashes, cannot install etc) to work on, and since Korean is not the language they use they feel less importance to fix the issue.
However, I beg you to take this seriously, if this issue continues to live along, normal Korean Document editing maybe possible, but re-writing a Korean Documents is a pain for every character I input since I need to press -> arrow button to make sure the highlighted text gets properly located.

Steps to Reproduce:
1.Get Korean input framework such as Fcitx, or i-bus
2.start typing in Korean(In LibreOffice or others, like Impress presentation)
3.using your mouse cursor, move your cursor location, and say hello to the frustrating disappearing text.

Actual Results:
The highlighted Korean text disappears from the last location where the cursor was, and sometimes reappears to the next location where you just moved your cursor to.

Expected Results:
the highlighted Korean characters should stay where they are when the user changes the cursor's location using the mouse.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.3.1
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 1 Potassium1 2021-01-13 06:19:22 UTC
Created attachment 168844 [details]
This a video using fcitx and LibreOfice to demenstrate the issue
Comment 2 Potassium1 2021-01-13 06:23:42 UTC
The video shows korean input demonstration. The actual issue demonstration starts at 20 (seconds) in the video, please carefully observe this, because I don't think I did a good job explaining this with text.
Comment 3 Potassium1 2021-02-17 09:50:59 UTC
After some juggling around with multiple input managers, I have discovered a input method(Nimf/님프 https://github.com/hamonikr/nimf ) that doesn't create this bug on not only libreoffice, but also other Linux Applications, So I think this bug report can be safely closed.