Description: In the vertical writing mode, the 3-point reader turns sideways and moves to the top to overwrite. Steps to Reproduce: 1. Open new Writer. 2. Chage Text direction to Right-to-left (vertical). 3. Insert text "３点…" or Paste "３点…" Actual Results: 4. "…" turns horizontal and moves to the top, overlapping "３". Expected Results: 4. The entries are displayed vertically in the order you enter them. Reproducible: Always User Profile Reset: No Additional Info: Not reproduced with [2025-06-27] Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 04bd455e36b054001e08a0a3256d508a009ffef3 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Reproducible with [2025_07_23] Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Not reproduced with [2025_08_23] Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 764799befcb927f68f78e904213e3db7195554cb CPU threads: 2; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
Created attachment 202468 [details] sample png
Created attachment 202469 [details] sample Writer file Try open with latest 26.2 version.
Created attachment 202470 [details] sample png Sample of 3-point reader placed sparsely.
Created attachment 202471 [details] sample Witer file
confirmed win64-26.2(b83dc4af23e163fb785f57038c6c3f3adefd5088) Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 23a1559e5a75a73671245f76a3a52d3619c9ef39 CPU threads: 12; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL threaded bibisected first bad commit ce1c352327ca52459c45c194051a777701051f72 source 027c65e72e49c1c5dae9d6b5f8151cd2d27442a7 commit 027c65e72e49c1c5dae9d6b5f8151cd2d27442a7 author Xisco Fauli <xiscofauli@libreoffice.org> Wed Jul 02 14:31:20 2025 +0200 skia: upgrade to m139 File created following the steps in external/skia/README Change-Id: I562687354075ab7d19afbe108bfd575db034b7c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187288
I upgrade skia m139 to a more recent commit in commit 035c55e954c227fb7bf689e558b7fff07a061f04 [log] author Xisco Fauli <xiscofauli@libreoffice.org> Mon Aug 25 16:57:11 2025 +0200 committer Xisco Fauli <xiscofauli@libreoffice.org> Tue Aug 26 11:11:06 2025 +0200 tree 5e4152c065369a93a8be8747c8e5f287fc594342 parent ba462658d955b6d7909f9ffbdfd341f18aff2028 [diff] skia: upgrade m139 to the latest commit but it didn't fix the issue
Created attachment 202703 [details] sample png Calc Example --- Vertical text in cells Text with spaces Text Box
Created attachment 202704 [details] sample file
Today I upgraded skia to m140 in commit 9d656704c791e8301d04b2e2caa6be13b564ce98 [log] author Xisco Fauli <xiscofauli@libreoffice.org> Tue Sep 30 12:42:36 2025 +0200 committer Xisco Fauli <xiscofauli@libreoffice.org> Tue Sep 30 14:10:38 2025 +0200 tree 98311f4b3b6d9c7632eeda54629a01e639f9e24c parent c5d16f0409e02d6e8bafb8ad58add5a115d13fb7 [diff] skia: upgrade to m140 but the issue is still reproducible... @Noel, @Jonathan, the upgrade to skia m139 introduced this issue, unfortunately I'm not familiar with skia at all. Do you have any idea where the issue might be? Do you think it's an issue in skia or is it an issue on our side?
> > @Noel, @Jonathan, the upgrade to skia m139 introduced this issue, > unfortunately I'm not familiar with skia at all. > Do you have any idea where the issue might be? Do you think it's an issue in > skia or is it an issue on our side? You could try posting a question on the skia-discuss google group, they are quite helpful. Maybe one of them will recognise the issue. The issue could be anywhere, but mostly likely on the skia side. Which is not that helpful, because they would want a small standalone test case before they would look at it, and deriving such a test case from our code is essentially impossible.
I haven't done much investigation, but what's going on is strange. Specifically when Skia is used, HarfBuzz overlooks the vertical alternate for U+2026 and marks the glyph as non-vertical. That's the proximate cause. I think there may also be a bug in SkiaSalGraphicsImpl::drawGenericLayout() which is causing the overlapped rendering, but that's just being upset by whatever has changed in Skia that's affecting HarfBuzz. Is it possible we're linking to multiple versions of HarfBuzz or FreeType? I agree that it would be good to ask the Skia devs for advice.