Sign up
View stargazersSign up

[Bug]: Japanese text in .docx renders as boxes in the file viewer (right pane)#28990

opened10d agobyCCmcWakita

Summary

When a .docx file is opened in the right-pane file viewer, Japanese text is rendered as empty boxes (tofu). Latin text renders correctly.

Steps to reproduce

  1. On Windows 11, create a .docx containing Japanese text (table with Japanese headers/body; font set to MS Gothic or Yu Gothic, generated with docx-js).
  2. Open the file from a link in the thread (opens in the right-pane file viewer).
  3. Japanese characters appear as boxes; "SES", "SMTP", "Microsoft Graph API", digits, etc. display fine.

Expected

Japanese text renders (system CJK font fallback, or the font specified in the document).

Actual

All CJK characters render as boxes. Changing the document font from Yu Gothic to MS Gothic did not help.

Notes

  • The same document opens correctly in Microsoft Word on the same machine (1 page, table intact).
  • A PDF exported from Word (fonts embedded) and shown via the preview browser is the workaround.
  • Suspect the docx viewer lacks a CJK font fallback; not confirmed.
  • Related (closed as duplicate): #22039 "View Word, Excel and PowerPoint files in the app".

Environment

Windows 11 Pro 10.0.26300, T3 Code desktop app.

Wwayne37675d ago
Synced from GitHub

Additional report: Simplified Chinese is also affected on macOS, T3 Code desktop 0.1.7. Chinese text is missing in DOCX preview, while Chinese in XLSX preview displays correctly on the same machine.

Read-only inspection of the installed official app found:

  • assets/fonts-cjk-95TDYhcP.js exports an empty mapping: const e=void 0;export{e as CJK_FONT_ASSET_URLS};
  • The packaged assets contain neither NotoSansSC-Regular.otf nor NotoSerifSC-Regular.otf, although both are declared in the document worker's font catalog.
  • In assets/document.worker-BJ3XBWBI.js, the script filter is function mh(e){return!e.startsWith(cjk-)}. Both face selection and script fallback use this filter, so adding font files alone would not enable the Chinese fallback in this build.
  • The local running server serves the same document worker as the installed package.
  • By comparison, spreadsheet.worker-AXWWY4sf.js draws text with Canvas fillText() and a sans-serif fallback. This is consistent with XLSX Chinese working through browser/system font fallback while DOCX does not.

The installed application passes codesign --verify --deep --strict. No app changes were made for this inspection. These are package/runtime-asset findings accompanying the user's observed symptom; a fresh visual reproduction was not performed during this inspection.

Please include Simplified Chinese DOCX coverage in the upstream fix and check both font asset inclusion and the CJK selection/fallback gate. A useful regression case would contain Chinese headings, paragraphs and table cells alongside Latin text and digits, checked for visible glyphs and sensible layout in the released desktop build. Shipping this through the normal signed release would avoid users patching app bundles and having to reapply changes after updates.

Thanks for tracking the CJK fix here.

Lleonclab1d ago
Synced from GitHub

Confirmed still reproducible on T3 Code Nightly 0.1.8-nightly.20261105.4218 (macOS 27.0.1, Apple Silicon).

  • Simplified Chinese DOCX: Chinese headings, paragraphs, and table cells render as tofu boxes; Latin text and digits render normally.
  • The same file renders correctly in Microsoft Word, Pages, and macOS Quick Look.
  • This matches the existing package findings: the bundled Office viewer has no CJK font pack, so Chinese is affected as well as Japanese.
  • User workaround: open in Word/Quick Look, or export a PDF and preview that instead.

The open PRs #29051 and #26230 appear to target this. Please keep both parts in the fix: bundle the CJK faces and allow the document worker's font selection/fallback to use them. A regression DOCX containing Chinese, Latin text, digits, and a table would cover it.

No sensitive document is attached; this is a generic confirmation.