Cell.Value is corrupted with furigana about nanoxlsx HOT 11 CLOSED

Sample data attached.
I hope this will be useful to you.

furigana.xlsx

from nanoxlsx.

Thanks for fixing it.
The new version works correctly.
If I find any problems, I will report them.

from nanoxlsx.

My guess is that we can just ignore the rPH tag.

from nanoxlsx.

こんいちは

Thank you for the report.

So, have I understood the issue correct:
The Furigana part above the Kana should never be visible in Excel. But it should be preserved when you copy the value of a cell to a program that handle Furigana?
I am asking because, when we ignore, rPh, the Furigana signs will be lost.

I will have a look into the formatting in the shared string table. This (inline formatting) is on top of my backlog as ToDo.

Thank you in advance for clarification.

from nanoxlsx.

Yes, Excel does not display the furigana part.

I have been using files containing Japanese for over 10 years and have never needed furigana.
Even when I edit files in Excel for the web, the furigana is lost.

Therefore, my conclusion is that there is no problem with lost furigana.

For a program to preserve the furigana, you generally need a different object model than a single value.
VBA provides Characters.PhoneticCharacters.

from nanoxlsx.

OK, thank you.

When I implemented the shared string table, I decided to remove all paragraphs and to keep all enclosed text, to preserve any content. However, since Furigana is only a Kanji transcription, it's presence breaks the sentence / word structure ,as you already stated.

Let me look for the best solution to preserve formatted text and to remove transcriptions. I have analyze the rPH (and possible others) tag a little bit. Maybe it can always be ignored or there will be an import option, if there are use cases, where rPH content is meaningful.

Please give me some time to do this. Currently, I am working on a big refactoring (dev branch) and I have to adapt any change on several braches and projects.

どうもありがとうございました。

from nanoxlsx.

I have some good news.
The rPH tag seems to be designated only for transcriptions (as Furigana is) of Han-originated characters. So it can be removed from the original text without side-effects.
I will do this by default with an opt-in import-option to keep the transcriptions, enclosed in brackets, if wished.
Please give me some days to implement and test this feature.

from nanoxlsx.

Hello
Technically, I already have a solution.
However. I have insufficient test data. And it looks like my western Office refuses to carry Furigana at all. I tried to copy-paste from a web browser and Word, but Excel never created a rPH tag.

Could you provide me with some additional samples, where Kanji characters are transcribed by Furigana? I would suggest something like that:

• お元気ですか --> Two connected Kanji surrounded by Hiragana
• この所は賑やかです。--> Two disconnected Kanji, surrounded by Hiragana
• 金 --> One single Kanji
• 富士山は高いです。--> Several Kanji at the beginning of the text and Hiragana at the end
• この儘--> Hiragana with Kanji at the end of the text

If you could provide me an Excel file with these (or similar) use cases, I could test my patch properly. Currently, I cannot predict the right tag structure.

Thank you very much in advance.

from nanoxlsx.

Thank you for your quick response.

We will gladly provide sample data. Please wait a moment.

from nanoxlsx.

ただいま
Thank you for the samples. They helped me a lot.
I just released v1.8.6. The Nuget packet will be available in some minutes.
by default, Furigana will now be discarded. If the transcription is wished, there is an import option "EnforcePhoneticCharacterImport", that can be set to true. In this case, Furigana will be appended to the Kanji characters:

Please let me know if something is not working as expected.
また、レポートありがとうございました。

from nanoxlsx.

I will close this issue for now. If you try out the fix and find something that is not as you would expecting, please do not hesitate to re-open or file a new issue.
Thank you

from nanoxlsx.