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)
Version:
(earliest affected)
5.3.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Ruby CJK-Japanese
  Show dependency tree / graph
 
Reported: 2017-04-15 15:19 UTC by y3kcjd5
Modified: 2023-11-27 11:52 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Demomstration document with instructions for reproducing the problem(s) (7.26 MB, application/vnd.oasis.opendocument.text)
2017-05-16 10:52 UTC, y3kcjd5 		Details
Rendering in the pxrubrica way (10.97 KB, image/png)
2023-11-27 11:52 UTC, Ben.Engbers@Be-Logical.nl 		Details
View All Add an attachment (proposed patch, testcase, etc.)

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 
Description:
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.

First.
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.

Second.
"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.
<discuss@ja.libreoffice.org>
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.
https://wiki.documentfoundation.org/JA/WhatsMailingList
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.

Version: 5.3.3.2
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  6.4.1.2 (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 Comment hidden (obsolete)
Comment 7 Ben.Engbers@Be-Logical.nl 2023-11-27 11:51:51 UTC 
After I closed my bug (https://bugs.documentfoundation.org/show_bug.cgi?id=157366) I encountered the same problem in Latex.
In the texlive package pxrubrica this was solved in a nice way. Essentially, placing a `|` determines how the Ruby blocks are placed above the Kanji.
The word 自動販売機 is split into 2 Kanji blocks in the Asiatic Phonetic guide. 
The first block contains the Kanji 自動 with hiragana じどう. The second block contains the Kanji 販売機 with hiragana はんばいき.
In the example, this corresponds to the top view....
In pxrubrica, by placing a | you can change the mode of rendering. 
\ruby[j]{自動販売機}{じ｜どう｜はん｜ばい｜き} results in the bottom rendering.

Is it a suggestion to implement something similar in the Phonetic guide as well? Use of a | should then result in splitting the Ruby block.
Comment 8 Ben.Engbers@Be-Logical.nl 2023-11-27 11:52:37 UTC 
Created attachment 191060 [details]
Rendering in the pxrubrica way