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
Created attachment 156940 [details] Sample DOC document
Created attachment 156942 [details] Figure 1. Sample DOC opened with LibreOffice Writer
Created attachment 156944 [details] Figure 2. Sample DOC opened with MS Word
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
Set platform to all as I also reproduce on Ubuntu 18.04 LTS with 6.4.1.0.0+ Build ID: 598ea01b91a1b4e96c24e70089a63dcd35b29f1b.
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.
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
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.
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.
Dear Volga, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
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.
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.
Reopening due to bug 164803. More research is needed.
Created attachment 201924 [details] forum-mso-en3-8021.doc: another example where LO text is more tightly spaced
*** Bug 167748 has been marked as a duplicate of this bug. ***
*** Bug 134540 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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.
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.
Is it possible to back port to 25.8 release channel?
(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%?
(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.