Bug 107184 - Furigana (ruby) character selection system very clunky, produces unexpected/unpreventable/undesired output
Summary: Furigana (ruby) character selection system very clunky, produces unexpected/u...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Ruby CJK-Japanese
  Show dependency treegraph
Reported: 2017-04-15 15:19 UTC by y3kcjd5
Modified: 2022-08-29 06:42 UTC (History)
3 users (show)

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

Demomstration document with instructions for reproducing the problem(s) (7.26 MB, application/vnd.oasis.opendocument.text)
2017-05-16 10:52 UTC, y3kcjd5

Note You need to log in before you can comment on or make changes to this bug.
Description y3kcjd5 2017-04-15 15:19:53 UTC
As far as I can tell, the furigana menu (Alt,O,I,Enter) always automatically selects and divvies up the characters for which furigana are produced. This can be controlled to some extent by selecting characters, but causes a lot of problems if the automatic behavior isn't what's desired:
a. AFAIK it's impossible to insert a set of new characters (with furigana) in existing text; even if the cursor is placed between characters (instead of selecting some), the system automatically enters surrounding text into the furigana menu for editing.
b. It is impossible to control how a selection is split up into editing entries. Sometimes Japanese text will contain somewhat unorthodox combinations of, say, 3~4 kanji that the system decides to split up; if this happens, trying to put furigana over all of them together as one set is a massive pain (and involves much repeated pressing of buttons and copious use of Backspace).

Steps to Reproduce:
1. Produce a document with aforementioned uncommon combinations of characters; something like "叩五月雨" or "二連想" are good examples
2. Try to accomplish a. above without deleting desired characters or b. above without having to get rid of tons of extraneous output

Actual Results:  
for a., stuff gets deleted. For b., creating the furigana fails the first few times producing lots of extraneous kanji instead.

Expected Results:
For a., just don't automatically select surrounding text, and for b., always treat contiguous selections as complete editing entries (Note: it is almost never the case that multiple strings requiring furigana appear immediately adjacent each other). That way I could actually use Ctrl-select to fix multiple entries at once!

Reproducible: Always

User Profile Reset: No

Additional Info:
I'm making a couple other requests/reports regarding the furigana system; hopefully they can get cleaned up together.

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Comment 1 JO3EMC 2017-05-05 12:03:37 UTC
It seems to be a little strange situation for the "Ruby" or "Asian Phonetic Guide" function in LibreOffice, surely.
It might get worse than previous version.
I also feel some problem on this matter.

But this report is too complex to interpret for me.

This report includes multiple pbobrems, isn't it?
In your expression, "a." and "b.".
It maybe better to split them to different report, I think.
For easier handling.

"Steps to Reproduce" seems to be lack of explanation.
Now, I can't reproduce your probrem.
"Step" is wanted to be so simple, subdevided.

If you'd like, we may have some communication in Japanese with e-mail etc...
You can also participate to Mailing-list of Japanese Community.
Comment 2 y3kcjd5 2017-05-16 10:52:43 UTC
Created attachment 133357 [details]
Demomstration document with instructions for reproducing the problem(s)

This report concerns only one problem: the furigana menu automatically selects and divides text into the base text fields; it shouldn't. However, it manifests as different symptoms in different situations (A and B).

I've created and attached a demo document with step-by-step instructions and screenshots to better describe the symptoms.

I'm not familiar with mailing lists, is there some way to sign up without actually sending an email to it?
Comment 3 JO3EMC 2017-06-04 15:40:56 UTC
Sorry for the late reply.

I saw your demo document.
OK. Generally I understood. I would like to confirm this report.
Actually, I am also suffering from these problems.

However, as I told.
This report seems to include multiple phenomena that are strongly related, but the causes are not necessarily identical, I think.
I think that the contents of the demo document can be broken down into at least 4 events.

(1) Undesirable division of Base text, when the function of "Asian Phonetic Guide" is called with some characters selected in advance.

(2) When we modify the division of the base text in the "Asian Phonetic Guide" dialog box, the original string grows illegally.
    (It seems to be reproduced when there are multiple lines of Base text.)

(3) When we call the function of "Asian Phonetic Guide" with no character selection, the next character after cursor position is set to Base text, unexpectedly.

(4) When we move the Base text of one line to another line in "Asian Phonetic Guide" dialog box, that character disappears in the body.
    (Didn't reproduced in my environment. Blank lines are locked, and I can't input any characters.)

As you say, (1) and (3), (2) and (4) may be the same problem respectively.
But I do not know the truth.

I don't know the way to sign up to mailing lists without sending an e-mail.
Is there any problem to send an e-mail?
Since it is a "mailing list", I think that it is natural that registration acceptance is by e-mail.
The way to register is explained on the following page.
There are several MLs, such as bug fixes are treated in "discuss".

Or for the time being, you can send me a mail directly.
The address is linked to the handle name.

Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: ja-JP (ja_JP); Calc: group
Comment 4 QA Administrators 2019-11-16 03:41:31 UTC Comment hidden (obsolete)
Comment 5 y3kcjd5 2020-03-10 02:46:53 UTC
Reproduced in version (x64), Build ID: 4d224e95b98b138af42a64d84056446d09082932.

The demo document is slightly outdated; in example B, the "で" can no longer be moved out of the way as shown and must instead be replaced, because all entry fields unoccupied when the furigana window is opened are no longer editable. However, the behavior being shown is still present, and the end result (incorrect deletion of "で" due to its erroneous presence in the furigana window) is the same.
Comment 6 QA Administrators 2022-08-29 06:42:42 UTC
Dear y3kcjd5,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team