Description: When I am typing Chinese characters in a Writer paragraph or a Calc cell, the characters will sometimes crowd together, making the words misaligned and impossible to read. Steps to Reproduce: 1. Open the attached test document. Note that the characters displays well. The document uses “Noto Serif CJK SC” font, so you may need to install the fonts to reproduce. On Fedora linux, the font package is named "google-noto-serif-cjk-fonts.noarch" in the official repo. 2. Insert a space after the character "的" in the middle of the 2nd line. --> The characters will mess up misaligned. Ctrl+Z to undo does not bring it back to normal. Inserting more spaces will make more characters to mess up. Actual Results: The characters will mess up misaligned at step 2. Expected Results: The characters should align properly with every character appear at its own position. Reproducible: Sometimes User Profile Reset: Yes Additional Info: # System Details Report --- ## Report details - **Date generated:** 2025-04-12 20:08:33 ## Hardware Information: - **Hardware Model:** Lenovo ThinkPad X1 Carbon Gen 8 - **Memory:** 16.0 GiB - **Processor:** Intel® Core™ i5-10210U × 8 - **Graphics:** Intel® UHD Graphics (CML GT2) - **Disk Capacity:** 512.1 GB ## Software Information: - **Firmware Version:** N2WET43W (1.33 ) - **OS Name:** Fedora Linux 41 (Workstation Edition) - **OS Build:** (null) - **OS Type:** 64-bit - **GNOME Version:** 47 - **Windowing System:** Wayland - **Kernel Version:** Linux 6.13.10-200.fc41.x86_64 Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 8; OS: Linux 6.13; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Calc: threaded
Created attachment 200318 [details] test.odt Test Writer document.
Created attachment 200319 [details] screenshots.pdf screenshots showing the problem. The same issue does not happen in earlier versions. Need bibisecting.
Also reproducible on current master. They problem will disappear when turn "Tools - Options - Languages and Locales - Asian Layout - Character spacing" to "No compression" (it defaults to "Compress only punctuation"). So something may be wrong in the character spacing compression code. May be somewhere in: https://cgit.freedesktop.org/libreoffice/core/log/editeng/source/editeng/impedit3.cxx
I cannot reproduce this issue. Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
Sorry, I can reproduced. A bisection where 123456 is added after '的', and then 123456 is deleted. commit 73a96633d672f344f6415f050405b19174031f37 author Jonathan Clark <jonathan@libreoffice.org> Tue Dec 10 02:25:31 2024 -0700 tdf#66791 sw: Treat weak punctuation as Asian in Asian paragraphs This change modifies script detection to treat certain weak punctuation marks, particularly left- and right- quotation marks, as Asian script in paragraphs containing Chinese and Japanese characters, but no Complex characters. This change improves our script detection compatibility with other programs. As part of this change, duplicated script detection code has been extracted from Writer and Edit Engine, and consolidated. ** Jonathan, would you please have a look at this?
Also reproducible on Windows. Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: CL threaded It seems, for me on Windows at least, this is a temporary issue, as saving, closing, and reopening the document after adding characters would show correct, non-overlapping layout.
Created attachment 200332 [details] Another screenshot Here is my screenshot, I used Source Han Serif SC, but I can't reproduce. Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: CL threaded
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0f097aee61abc5a8244fb51796f0dd2f9bae22c7 tdf#166152 sw: Fix for SwScriptInfo corruption on incremental update It will be available in 25.8.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.
This commit fixes the compression bug in Writer. The Calc (Edit Engine) compression bug mentioned in the original report is unrelated. I'm filing a separate bug for that issue.
(In reply to Jonathan Clark from comment #9) Thanks for the quick fix. The same issue exists on Impress, is that a different issue as well?
(In reply to Kevin Suo from comment #10) > (In reply to Jonathan Clark from comment #9) > Thanks for the quick fix. The same issue exists on Impress, is that a > different issue as well? That's an instance of bug 166194. It will also happen in Draw and Writer text boxes, because these share the same code.