[Libreoffice-bugs] [Bug 139577] New: Korean/hangul input has issues for Libreoffice

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Wed Jan 13 06:07:19 UTC 2021


https://bugs.documentfoundation.org/show_bug.cgi?id=139577

            Bug ID: 139577
           Summary: Korean/hangul input has issues  for Libreoffice
           Product: LibreOffice
           Version: 7.0.3.1 release
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: LibreOffice
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: Potassium1 at protonmail.com

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210113/cd3916a2/attachment-0001.htm>


More information about the Libreoffice-bugs mailing list