[XLSX] view html renders phonetic guide text as additional cell content

[ueno-koki]

Environment

• OfficeCLI: 1.0.144
• Command: officecli view sample.xlsx html

Summary

Excel phonetic guide information stored in OOXML rPh elements is rendered as ordinary cell text.

In the affected workbook, the rPh content is written in Katakana. OfficeCLI appends this Katakana text to the visible cell value, causing text that is not part of the ordinary cell value to appear inside the cell.

The relevant OOXML structure is similar to:

<rPh sb="0" eb="2">
  <t>カタカナ</t>
</rPh>

Steps to reproduce

1. Create an XLSX cell containing Japanese text.
2. Add or retain phonetic guide information for the cell in Microsoft Excel.
3. Run:

officecli view sample.xlsx html

4. Inspect the rendered cell in the generated HTML.

Expected behavior

The phonetic guide should either:

• Be rendered as a phonetic annotation associated with the original text; or
• Be omitted from the ordinary cell text if phonetic annotations are not supported.

The visible cell value should not be modified by the phonetic guide.

Actual behavior

The Katakana text stored in the rPh element is appended to the ordinary cell value and rendered as additional cell content.

This behavior is present in the unmodified HTML produced directly by OfficeCLI.

[goworm]

Thanks for the report. I tried to reproduce this but could not on current main: I built xlsx cells whose shared string carries a phonetic guide in both faithful shapes — <si><r><t>漢字</t></r><rPh sb="0" eb="2"><t>カンジ</t></rPh><phoneticPr/></si> and the bare-<t> variant — and in each case view html (and get/view text) render only the base text (漢字); the rPh katakana is not appended. So on the current build the phonetic guide is already excluded from the cell value.

Could you attach the sample.xlsx (or a minimal cut of it) where the katakana leaks into the cell? With the actual file I can render it, compare against Excel, and pin the exact rPh structure that triggers it. It may be a phonetic layout I have not matched, or already fixed since 1.0.144.

[ueno-koki]

Thank you for testing both phonetic-run structures on the current main.

I have attached:

sample.xlsx

The workbook contains one shared string:

<si>
  <t>項目</t>
  <rPh sb="0" eb="2">
    <t>コウモク</t>
  </rPh>
  <phoneticPr fontId="1"/>
</si>

I generated the screenshot by running OfficeCLI 1.0.144 directly.

officecli view sample.xlsx html

The raw HTML contains:

<td data-path="/Sheet1/A1">項目コウモク</td>

Preview:

[goworm]

Correction to my earlier comment — you were right, and I was wrong.

I previously said this did not reproduce. That conclusion was bad: my synthetic fixture never actually wired the cell to the shared string, so the reader was not exercising the path you hit. Rebuilt it properly, dumping the on-disk XML alongside the output, and it reproduces exactly as you described:

on disk: <si><r><t>項目</t></r><rPh sb="0" eb="2"><t>コウモク</t></rPh></si>
get:     text = "項目コウモク"
view:    A1=項目コウモク

Root cause: the cell-text readers used CT_Rst.InnerText, which concatenates the <rPh> guide with the base text. Sorry for the noise — thanks for filing it clearly enough that it held up.

Fixed on main. #348 (thanks @y4ho0) corrected the shared-string reader; reviewing it I found the same InnerText call in three more places, now all fixed together (b730b4dd):

• the inline-string branch (<is> cells hit it too)
• the chart-cache reader, which fed the furigana into chart series caches
• the rich-text conversion, which folded the guide into the run it preserves when turning a plain cell into runs — that one actually corrupted stored content

All four now share one rule: take the direct <t>, else concatenate the <r><t> runs, never InnerText. Multi-run rich text is unaffected, and the guide remains available separately as format.phonetic.

Leaving this open until you confirm on your workbook.