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>

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?

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

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.

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.

Created attachment 191060 [details]
Rendering in the pxrubrica way

*** Bug 157366 has been marked as a duplicate of this bug. ***

*** Bug 154724 has been marked as a duplicate of this bug. ***

While the info on Latex is interesting, it’s not really useful for a GUI program like LO.  What happens when the delimiter is part of the text?

The simplest solution would be for LO to do NO second-guessing about what is a word or what isn’t a word.  You can’t know all possible user contexts.  The selection should be accepted as a word or sequence that you want to add one set of ruby text to.

As it is, the dialogue is very useful if you’re adding phonetics to continuous text in a language that uses spaces (or maybe where the syllable is predictable), but this feature is most used for Japanese where it’s used more for the occasional unusual or lesser-know pronunciation, not for long stretches of text.

The educational use for Chinese might still do that though.

Maybe it actually needs two modes?

From reading the above, and following the instructions in the example document, I believe most of the identified issues were due to bug 141466. Editing base text is much less painful now than it used to be. Given that, I think it would be helpful to update this bug to reflect the current state of Writer.


Currently, Writer automatically splits Japanese text into multiple base text runs using a dictionary. This can be helpful in some cases, but can require excessive base text editing in situations where the user generally wants to treat entire selections as a single run of base text. Writer should handle this use case better.

Note that this is closely related to the mono case (bug 156543, bug 113189). It's possible that both cases can be addressed simultaneously.

A mode (mono) switch would probably go a long way towards a solution.

The problem is how the non-mono mode would work.  What’s really needed is a dialog that allows the user to select a whole sentence and arrange it as necessary, grouping or ungrouping characters/words as they see fit, in a clear and straightforward way.

Asian language users certainly *can* do everything now, but going in an out of the dialog many times is very tedious and slow.

The way I use it is undoubtedly a minority use: adding phonetics to non-Asian languages.  This can be extremely painful at times due to LO’s assumptions about words.  For example it’s common practice to hyphenate Gaulish or Ogham words to highlight their components, but even if you use a non-breaking hyphen, LO will assume that all the parts are separate words, e.g. CUNA‑MAGLI → CUNA | ‑ | MAGLI.  Attempting to edit the text in the dialog corrupts the document text, so there are only non-obvious solutions (select a single word & edit it later, select nothing and type the word in the dialog).  See bug 154724 for a worse case with a Proto-Indo-European word like *h₁ek̑u̯os.

It would all be a lot more understandable if LO didn’t second guess what you were trying to do.  Even its second guessing is wrong though, as a non-breaking hyphen should not break a word.

(In reply to Seán Ó Séaghdha from comment #13)
> For example it’s common practice to hyphenate Gaulish or Ogham words to
> highlight their components, but even if you use a non-breaking hyphen,
> LO will assume that all the parts are separate words, e.g.
> CUNA‑MAGLI → CUNA | ‑ | MAGLI. Attempting to edit the text in the dialog
> corrupts the document text, so there are only non-obvious solutions

Fortunately, document text corruption shouldn't happen anymore now that bug 141466 is fixed. It will be safe to edit base text in versions from 24.8.1 onward.

If most of the remaining inconvenience can be resolved by adding a mode switch/button to treat the entire selection as a single run, I'm inclined to start with that change. We can revisit base text grouping in the future, if needed.

Jonathan Clark committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3d9b8701cb1751e4139ffa24f72bb836eb877fd1

tdf#107184 sw: Added base text group feature to Asian Phonetic Guide

It will be available in 25.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

At first glance, this looks like a good improvement. After I have more experience here I will let you know if necessary.

Ben

Created attachment 196987 [details]
Screen dump

I have used the improved version for some time now. In furigana, the placement of the hiragana characters compared to the Kanji has improved considerably. However, I still see some areas for improvement.
1).
A sequence of Kanji is usually well divided into separate pieces that also take into account the difference between onyomi and kunyomi. However, a word like '卯の花' is not divided into 3 pieces (as should be).
2).
Splitting the sequence of kanji goes reasonably well until one of the yakumono punctuation marks is found. After such a punctuation mark, the sequence is not split further.

Ben