Bug 169920 - Glyph positions are incorrect with DFKai-SB in vertical writing
Summary: Glyph positions are incorrect with DFKai-SB in vertical writing
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
24.2.3.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Po-Yen Huang
URL:
Whiteboard: target:26.8.0 target:25.8.5 target:26...
Keywords:
Depends on:
Blocks: CJK-Chinese-Traditional
  Show dependency treegraph
 
Reported: 2025-12-10 04:01 UTC by Po-Yen Huang
Modified: 2026-01-25 14:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Brackets are overlapped with Chinese glyphs (8.93 KB, image/png)
2025-12-10 05:43 UTC, Po-Yen Huang
Details
Correct one (8.97 KB, image/png)
2025-12-10 05:44 UTC, Po-Yen Huang
Details
test document (10.63 KB, application/vnd.oasis.opendocument.text)
2025-12-10 05:46 UTC, Po-Yen Huang
Details
Screencast with different versions (238.42 KB, image/gif)
2025-12-19 11:55 UTC, Mike Kaganski
Details
25.8 daily build (8.15 KB, image/png)
2025-12-22 02:17 UTC, Po-Yen Huang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Po-Yen Huang 2025-12-10 04:01:57 UTC
Description:
From 24.2.3 release (and newer), 標楷體 (DFKai-SB) shows incorrect glyph positions in vertical writing after https://bugs.documentfoundation.org/show_bug.cgi?id=148330 fixed.

Steps to Reproduce:
1. Open the attached document
2. Check the resulted text layout

Actual Results:
Incorrect glyph positions. Chinese glyphs shift upward.

Expected Results:
Glyphs should spread evenly.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 4; OS: Windows 10.0 Build 26200; UI render: Skia/Raster; VCL: win
Locale: zh-TW (zh_TW); UI: zh-TW
Calc: threaded
Comment 1 Po-Yen Huang 2025-12-10 05:43:21 UTC
Created attachment 204551 [details]
Brackets are overlapped with Chinese glyphs
Comment 2 Po-Yen Huang 2025-12-10 05:44:02 UTC
Created attachment 204552 [details]
Correct one
Comment 3 Po-Yen Huang 2025-12-10 05:46:17 UTC
Created attachment 204553 [details]
test document
Comment 4 Po-Yen Huang 2025-12-17 05:59:34 UTC
OK, we found Harfbuzz doesn't fix this issue. And find this commit cause the current issue: https://github.com/LibreOffice/core/commit/6f4a949c07eb06345df08c722f8e59e97888a499#diff-362a49004ff8f7db482832b78a246610baaf9bfbd41903fbbb3060271fb88f9e
Any suggestion for this?
Comment 5 Po-Yen Huang 2025-12-17 06:21:26 UTC
We have tested on GNU/Linux and macOS with DFKai-SB and no issue there, only on Windows.
Comment 6 Commit Notification 2025-12-18 14:05:04 UTC
Jeff Huang committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/005e787efec6c1e352e3cd17231d70508cd18d8e

tdf#169920 Remove hardcoded DFKai-SB fix

It will be available in 26.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.
Comment 7 Commit Notification 2025-12-18 16:06:22 UTC
Jeff Huang committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/1cd303d206a06017fb9378a842beba53f8151c65

tdf#169920 Remove hardcoded DFKai-SB fix

It will be available in 25.8.5.

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.
Comment 8 Mike Kaganski 2025-12-19 11:55:44 UTC
Created attachment 204719 [details]
Screencast with different versions

Testing the document with version 7.3, 7.4, 25.8, and current master (having the font):

1. In 7.3, there was a ~small offset, where cursor would slightly cut the bottom art of the glyph;
2. In 7.4, it became OK, with cursor travelling correctly in the spaces between the glyphs;
3. In 25.8, the glyph offset was huge;
4. In current master towards 26.8, with the patch applied, the situation is very like 7.3.

I suppose, that maybe the change should be reverted, and the correction amount should be reviewed?
Comment 9 Buo-ren Lin (OSSII) 2025-12-22 01:41:32 UTC
(In reply to Mike Kaganski from comment #8)
> 3. In 25.8, the glyph offset was huge;

Is this the 25.8.5 version?
Comment 10 Buo-ren Lin (OSSII) 2025-12-22 01:51:17 UTC
(In reply to Mike Kaganski from comment #8)
> I suppose, that maybe the change should be reverted, and the correction
> amount should be reviewed?

If it causes regression on 25.8 I agree it should be reverted.

We'll look into it.

PS. Thanks for the screencast!
Comment 11 Po-Yen Huang 2025-12-22 02:17:25 UTC
Created attachment 204749 [details]
25.8 daily build

(In reply to Mike Kaganski from comment #8)
> Created attachment 204719 [details]
> Screencast with different versions
> 
> Testing the document with version 7.3, 7.4, 25.8, and current master (having
> the font):
> 
> 1. In 7.3, there was a ~small offset, where cursor would slightly cut the
> bottom art of the glyph;
> 2. In 7.4, it became OK, with cursor travelling correctly in the spaces
> between the glyphs;
> 3. In 25.8, the glyph offset was huge;
> 4. In current master towards 26.8, with the patch applied, the situation is
> very like 7.3.
> 
> I suppose, that maybe the change should be reverted, and the correction
> amount should be reviewed?

For 25.8 daily build, I tested on Traditional Chinese Windows, Glyph and cursor position show same as 26.2. So it may need another fix for cursor position.
Comment 12 Po-Yen Huang 2025-12-22 02:19:10 UTC
(In reply to Po-Yen Huang from comment #11)
> Created attachment 204749 [details]
> 25.8 daily build
> 
> (In reply to Mike Kaganski from comment #8)
> > Created attachment 204719 [details]
> > Screencast with different versions
> > 
> > Testing the document with version 7.3, 7.4, 25.8, and current master (having
> > the font):
> > 
> > 1. In 7.3, there was a ~small offset, where cursor would slightly cut the
> > bottom art of the glyph;
> > 2. In 7.4, it became OK, with cursor travelling correctly in the spaces
> > between the glyphs;
> > 3. In 25.8, the glyph offset was huge;
> > 4. In current master towards 26.8, with the patch applied, the situation is
> > very like 7.3.
> > 
> > I suppose, that maybe the change should be reverted, and the correction
> > amount should be reviewed?
> 
> For 25.8 daily build, I tested on Traditional Chinese Windows, Glyph and
> cursor position show same as 26.2. So it may need another fix for cursor
> position.

Version: 25.8.5.0.0+ (X86_64) / LibreOffice Community
Build ID: 791bdef1573d7f5bb36e41aebb73436ac2ea2e14
CPU threads: 4; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win
Locale: zh-TW (zh_TW); UI: zh-TW
Calc: threaded
Comment 13 Mike Kaganski 2025-12-22 04:48:00 UTC
(In reply to Buo-ren Lin (OSSII) from comment #9)
> Is this the 25.8.5 version?

No, it was the pre-patched 25.8.4. It was there to demonstrate the bug itself (and the effect of the patch in the master).
Comment 14 Commit Notification 2026-01-10 14:08:02 UTC
Jeff Huang committed a patch related to this issue.
It has been pushed to "libreoffice-26-2":

https://git.libreoffice.org/core/commit/c8e4b0e36f9ada94dd0a4ec2d1fe3b4a5199d9f7

tdf#169920 Remove hardcoded DFKai-SB fix

It will be available in 26.2.0.2.

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.