Bug 129808 - FILEOPEN DOC/X: Line spacing narrower than Word due to special handling of font code page range bits
Summary: FILEOPEN DOC/X: Line spacing narrower than Word due to special handling of fo...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3 all versions
Hardware: All All
: medium normal
Assignee: Jonathan Clark
URL:
Whiteboard: target:26.2.0
Keywords: filter:doc
: 134540 167748 (view as bug list)
Depends on:
Blocks: CJK DOCX-Paragraph DOC-Paragraph
  Show dependency treegraph
 
Reported: 2020-01-05 14:04 UTC by Volga
Modified: 2025-09-10 21:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample DOC document (13.50 KB, application/msword)
2020-01-05 14:16 UTC, Volga
Details
Figure 1. Sample DOC opened with LibreOffice Writer (122.28 KB, image/png)
2020-01-05 14:20 UTC, Volga
Details
Figure 2. Sample DOC opened with MS Word (151.94 KB, image/png)
2020-01-05 14:31 UTC, Volga
Details
129808_LO6.2.png: Sample document in LO 6.2 on Ubuntu 20.04 (186.40 KB, image/png)
2021-04-07 18:30 UTC, Justin L
Details
Typeface used to reproduce other than Windows (6.35 MB, application/x-7z-compressed)
2021-10-02 15:33 UTC, Volga
Details
forum-mso-en3-8021.doc: another example where LO text is more tightly spaced (56.50 KB, application/msword)
2025-07-21 15:22 UTC, Justin L
Details
Screenshot table showing line height anomaly (59.57 KB, image/png)
2025-08-25 13:10 UTC, Jonathan Clark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2020-01-05 14:04:59 UTC
Description:
While I opening this document with LibreOffice Writer, the line height looks extremely narrow, however, if I open this document with Microsoft Word, the line height looks wide.

Steps to Reproduce:
1. Open attached DOC file 

Actual Results:
See my screenshots

Expected Results:
The line height of text should be the same between LibreOffice Writer and Microsoft Word.


Reproducible: Always


User Profile Reset: No



Additional Info:
版本: 6.4.0.1 (x64)
Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f
CPU 线程: 4; 操作系统: Windows 10.0 Build 18363; UI 渲染: 默认; VCL: win; 
区域语言: zh-CN (zh_CN); UI 语言: zh-CN
Calc: threaded
Comment 1 Volga 2020-01-05 14:16:50 UTC
Created attachment 156940 [details]
Sample DOC document
Comment 2 Volga 2020-01-05 14:20:54 UTC
Created attachment 156942 [details]
Figure 1. Sample DOC opened with LibreOffice Writer
Comment 3 Volga 2020-01-05 14:31:09 UTC
Created attachment 156944 [details]
Figure 2. Sample DOC opened with MS Word
Comment 4 Durgapriyanka 2020-01-06 16:48:18 UTC
Thank you for reporting the bug. I can confirm the bug present in

Version: 6.4.0.0.alpha1+ (x86)
Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
	

and in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 5 Kevin Suo 2020-01-18 02:50:34 UTC
Set platform to all as I also reproduce on Ubuntu 18.04 LTS with 6.4.1.0.0+
Build ID: 598ea01b91a1b4e96c24e70089a63dcd35b29f1b.
Comment 6 Justin L 2021-04-07 18:30:23 UTC
Created attachment 171016 [details]
129808_LO6.2.png: Sample document in LO 6.2 on Ubuntu 20.04

I could not reproduce this - not even in 5.1.
Comment 7 Volga 2021-10-02 04:27:59 UTC
This is still reproduced with

Version: 7.2.2.1 (x64) / LibreOffice Community
Build ID: 0e408af0b27894d652a87aa5f21fe17bf058124c
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: zh-CN
Calc: threaded
Comment 8 Volga 2021-10-02 15:33:33 UTC
Created attachment 175460 [details]
Typeface used to reproduce other than Windows

Justin L, can you install this font reproduce? This is the interface typeface distributed with the Simplified Chinese version of Windows 10.
Comment 9 Volga 2022-07-27 18:18:13 UTC
This is still reproduced with

Version: 7.3.5.2 (x86) / LibreOffice Community
Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: zh-CN
Calc: threaded

And not reproduced with WPS Office.
Comment 10 QA Administrators 2024-07-28 03:15:02 UTC Comment hidden (obsolete)
Comment 11 Roman Kuznetsov 2024-07-28 16:57:24 UTC
still repro 

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ccc3996cfcbebe14e9d5f3511906cfc64ddf3452
CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL threaded
Comment 12 Jonathan Clark 2024-09-19 21:22:53 UTC
The root cause for this bug is slightly incorrect handling of the fNoExtLeading doc compatibility flag.

The sample doc has the fNoExtLeading compatibility flag set. When Microsoft Word calculates line height for text grid alignment, it includes the font external leading even with this flag set. Writer, on the other hand, excludes it. As a result of this difference, each line of text requires two grid rows in Word, but only one row in Writer, despite the font size being less than the grid pitch.

This change could affect layout of existing documents, so I propose adding a new compatibility flag to enable Word-style text grid height calculation. This flag would be enabled on doc import, but would be disabled otherwise.
Comment 13 Commit Notification 2024-09-20 08:44:11 UTC
Jonathan Clark committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2155684c819dcdc52968c59276046fb0cad83561

tdf#129808 sw: Use ext leading for text grid spacing on DOC import

It will be available in 25.2.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 14 Jonathan Clark 2025-01-27 17:54:55 UTC
Reopening due to bug 164803. More research is needed.
Comment 15 Justin L 2025-07-21 15:22:14 UTC
Created attachment 201924 [details]
forum-mso-en3-8021.doc: another example where LO text is more tightly spaced
Comment 16 Jonathan Clark 2025-08-22 15:03:30 UTC
*** Bug 167748 has been marked as a duplicate of this bug. ***
Comment 17 Jonathan Clark 2025-08-22 15:04:52 UTC
*** Bug 134540 has been marked as a duplicate of this bug. ***
Comment 18 Jonathan Clark 2025-08-22 15:20:15 UTC
This bug is best demonstrated by attachment 162676 [details] from bug 134540.

When distributing lines on the text grid, Word treats text as requiring slightly more vertical space than Writer does. As a result, certain lines in Word are given an extra grid row, while in Writer the text looks more compact.

This behavior doesn't seem to be affected by any compatibility option, or by any font metrics other than ascent and descent, at least as far as I've been able to tell so far.
Comment 19 Jonathan Clark 2025-08-25 13:10:33 UTC
Created attachment 202500 [details]
Screenshot table showing line height anomaly

2x2 table showing line height anomaly in Word vs Writer for fonts that advertise CP932 support and those that do not.
Comment 20 Jonathan Clark 2025-08-25 13:22:51 UTC
OpenType fonts contain an OS/2 table which specifies metrics and other common parameters. One field in the OS/2 table is uCodePageRange*, a bitset which fonts can use to indicate whether the font covers a particular code page. When bit 17 is set (indicating CP932 coverage), Microsoft Word may automatically extend the line height using an unknown algorithm.

Based on manual testing, I believe this extra line height is roughly equivalent to 136% proportional spacing in Writer.

This behavior affects any font that has the CP932 bit set, regardless of metrics, whether it is used for Asian text, whether the text contains CJK characters, whether the font actually contains CJK characters, or whether the document grid is in use. In my experiments, simply setting this bit on a font and loading an existing document that uses it is enough to reproduce this behavior.
Comment 21 Jonathan Clark 2025-08-26 08:29:57 UTC
This behavior is used if any of the following ulCodePageRange* bits are set:

- 17 (CP932 JIS/Japan)
- 18 (CP936 Simplified Chinese)
- 19 (CP949 Korean Wansung encoding)
- 20 (CP950 Traditional Chinese)

No other bits trigger this behavior. Notably, bit 21 (CP1361 Korean Johab encoding) doesn't trigger it.

This behavior is not affected by any compatibility flag exposed via the Word 365 user interface.

If anyone else tries poking this, something to note is that Word doesn't correctly reload the font if these specific bits are flipped while Word is running. You have to close all open documents and completely restart Word between tests.
Comment 22 Commit Notification 2025-08-28 09:46:57 UTC
Jonathan Clark committed a patch related to this issue.
It has been pushed to "master":

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

tdf#129808 sw: Extend leading for CJK fonts in DOC/DOCX files

It will be available in 26.2.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 23 Jonathan Clark 2025-08-28 10:02:57 UTC
This implementation isn't a pixel-perfect recreation of Word's. Additional tuning may be desired once more is known about Word's CJK line spacing arithmetic, but it should be much closer now.
Comment 24 Volga 2025-09-04 08:43:49 UTC
Is it possible to back port to 25.8 release channel?
Comment 25 Volga 2025-09-08 07:49:07 UTC
(In reply to Jonathan Clark from comment #20)
> Based on manual testing, I believe this extra line height is roughly
> equivalent to 136% proportional spacing in Writer.
Maybe 137.5%?
Comment 26 Jonathan Clark 2025-09-10 21:11:43 UTC
(In reply to Volga from comment #25)
> (In reply to Jonathan Clark from comment #20)
> > Based on manual testing, I believe this extra line height is roughly
> > equivalent to 136% proportional spacing in Writer.
> Maybe 137.5%?

Unfortunately, it's not a simple constant. My best guess right now is that the original calculation includes compounded arithmetic error that causes larger layout differences at small font sizes.