Bug 117881 - FILEOPEN DOCX: Spacing in Linux is slightly different from Windows for bullet lists with Microsoft fonts
Summary: FILEOPEN DOCX: Spacing in Linux is slightly different from Windows for bullet...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3 all versions
Hardware: All Linux (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, needsDevAdvice, regression
: 118050 (view as bug list)
Depends on:
Blocks: Regressions-Universal-Line-Spacing
  Show dependency treegraph
 
Reported: 2018-05-29 14:50 UTC by Marco Diego Aurélio Mesquita
Modified: 2022-08-22 23:22 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
File in which problem happens (37.47 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-05-29 14:53 UTC, Marco Diego Aurélio Mesquita
Details
How the file is displayed on MSO 2007 (22.63 KB, application/pdf)
2018-05-29 14:54 UTC, Marco Diego Aurélio Mesquita
Details
How the file is rendered by Libreoffice 6.0 (55.25 KB, application/pdf)
2018-05-29 14:56 UTC, Marco Diego Aurélio Mesquita
Details
How the file is rendered by LO 5.2.7.2 (31.51 KB, application/pdf)
2018-06-08 02:12 UTC, Marco Diego Aurélio Mesquita
Details
Patch that fixes the problem (13.33 KB, patch)
2018-06-13 15:05 UTC, Marco Diego Aurélio Mesquita
Details
Patch that fixes the bug (1.03 KB, patch)
2018-06-13 18:34 UTC, Marco Diego Aurélio Mesquita
Details
Patch that fixes the bug. (1.03 KB, patch)
2018-06-13 18:36 UTC, Marco Diego Aurélio Mesquita
Details
LO 6.4.4.2 compatibility "Add spacing betweem paragraphs and tables" and "Use OpenOffice 1.1 line spacing" options enabled (31.73 KB, application/pdf)
2020-07-10 17:36 UTC, Marco Diego Aurélio Mesquita
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Diego Aurélio Mesquita 2018-05-29 14:50:57 UTC
Description:
Libreoffice writer is not showing linefeeds or pagebreaks at the end of the first page in attached document.

Steps to Reproduce:
1. Open attached DOCX file.
2. See end of first page.


Actual Results:  
Session 1.2 is on the same page as session 1.1.

Expected Results:
Session 1.1 and 1.2 should be on different pages.


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/66.0.3359.181 Chrome/66.0.3359.181 Safari/537.36
Comment 1 Marco Diego Aurélio Mesquita 2018-05-29 14:53:07 UTC
Created attachment 142382 [details]
File in which problem happens

File that reproduces the problem.
Comment 2 Marco Diego Aurélio Mesquita 2018-05-29 14:54:22 UTC
Created attachment 142383 [details]
How the file is displayed on MSO 2007

PDF of file rendereb by MSO word 2007.
Comment 3 Marco Diego Aurélio Mesquita 2018-05-29 14:56:04 UTC
Created attachment 142384 [details]
How the file is rendered by Libreoffice 6.0

File rendered by LO 6.0.4.2.
Comment 4 Xisco Faulí 2018-05-29 16:58:47 UTC
Regression introduced by:

author	Khaled Hosny <khaledhosny@eglug.org>	2016-11-09 15:22:43 +0200
committer	Khaled Hosny <khaledhosny@eglug.org>	2016-11-22 15:32:11 +0000
commit 34d7602954d4483b3bc9db700e7df2c15348947a (patch)
tree 8dcfb93fc29815fd89481a7840d64d6c187534db
parent c855aec445628f96d3d32cfde6efd4e51e4489c9 (diff)
tdf#55469 Consistent line spacing across platforms

Bisected with: bibisect-linux-64-5.3

Adding Cc: to Khaled Hosny
Comment 5 Marco Diego Aurélio Mesquita 2018-05-30 22:08:33 UTC
I compiled Libreoffice from source and made some experiments. The following changes seem to fix the bug, but it breaks tests (CppunitTest_sw_ooxmlexport9).

diff --git a/vcl/source/font/fontmetric.cxx b/vcl/source/font/fontmetric.cxx
index b54e41a..142e94e 100644
--- a/vcl/source/font/fontmetric.cxx
+++ b/vcl/source/font/fontmetric.cxx
@@ -457,7 +457,7 @@ void ImplFontMetricData::ImplCalcLineSpacing(const std::vector<uint8_t>& rHheaDa
     {
         fAscent     =  rInfo.ascender  * fScale;
         fDescent    = -rInfo.descender * fScale;
-        fExtLeading =  rInfo.linegap   * fScale;
+        fExtLeading =  rInfo.linegap   * (fScale + 0.5);
     }
 
     // But if OS/2 is present, prefer it.
Comment 6 Marco Diego Aurélio Mesquita 2018-06-06 20:55:56 UTC
I tried fixing this bug by forcing the OS/2, Windows and hhea metrics for "Times New Roman" in a way similar to the fix for tdf#116498. None of the three metrics fix the problem definitively.

I know this bug was bissected, but I'm not sure if font metrics are to blame for this problem. Maybe this should be fixed by changing the way header or footer margins are handled?
Comment 7 Marco Diego Aurélio Mesquita 2018-06-07 00:08:15 UTC
NOt sure, but maybe this is a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=115944 . Can anyone confirm?
Comment 8 Marco Diego Aurélio Mesquita 2018-06-07 12:51:51 UTC
After a bit more of investigation, I think the cause of this bug is the same as https://bugs.documentfoundation.org/show_bug.cgi?id=118050 .
Comment 9 Xisco Faulí 2018-06-07 13:39:48 UTC
*** Bug 118050 has been marked as a duplicate of this bug. ***
Comment 10 Marco Diego Aurélio Mesquita 2018-06-07 13:55:49 UTC
I tried the same fix suggested in https://bugs.documentfoundation.org/show_bug.cgi?id=118050#c5 : selecting the list, pointing to "format -> paragraph" and set "space below paragraph" to 0.05 cm. It does indeed fix the problem.

So, it looks like we a problem with how the spacing between list items is calculated. Everything else in the text seems correct. How does the font metrics influence spacing between list items? That is probably all we have to fix.
Comment 11 Marco Diego Aurélio Mesquita 2018-06-08 01:49:56 UTC
From https://bugs.documentfoundation.org/show_bug.cgi?id=118050 it is possible to see that spacing between items was already broken in LO 5.2. I didn't test the state immediately after 34d7602954d4483b3bc9db700e7df2c15348947a, but in LO6 spacing between list items even smaller. To fix the bug, line spacing between list items should be as big as in MSO.

Now, I think 34d7602954d4483b3bc9db700e7df2c15348947a actually makes thing better. All the text before the list is exactly where it should be. So, I think the problem was there already, changes between LO 5.2 and LO 6 improved most of the text except for the spacing between list items. I'm not sure what may be causing this. Maybe this is caused by the rounding of the "ascent", "descent" or "external leading" font metrics.

I really don't think this is hard to fix, but someone is needed to point where spacing between list items are calculated. This way we can make more experiments and get closer to the cause of this bug, possibly finding a solution in the end.
Comment 12 Marco Diego Aurélio Mesquita 2018-06-08 02:12:38 UTC
Created attachment 142605 [details]
How the file is rendered by LO 5.2.7.2

How Libreoffice 5.2.7.2 renders the file.
Comment 13 Marco Diego Aurélio Mesquita 2018-06-08 12:41:37 UTC
(In reply to Xisco Faulí from comment #4)
> Regression introduced by:
> 
> author	Khaled Hosny <khaledhosny@eglug.org>	2016-11-09 15:22:43 +0200
> committer	Khaled Hosny <khaledhosny@eglug.org>	2016-11-22 15:32:11 +0000
> commit 34d7602954d4483b3bc9db700e7df2c15348947a (patch)
> tree 8dcfb93fc29815fd89481a7840d64d6c187534db
> parent c855aec445628f96d3d32cfde6efd4e51e4489c9 (diff)
> tdf#55469 Consistent line spacing across platforms
> 
> Bisected with: bibisect-linux-64-5.3
> 
> Adding Cc: to Khaled Hosny

Xisco, is this really a regression from that commit? What is really broken here is the spacing between list items and it was already broken before 34d7602954d4483b3bc9db700e7df2c15348947a .
Comment 14 Marco Diego Aurélio Mesquita 2018-06-08 22:11:34 UTC
In method SwTwips SwFlowFrame::CalcUpperSpace if we add 10 to "nUpper" right before returning under the following condition:

    if (pPrevFrame && pPrevFrame->IsTextFrame()) {
        const SwTextFrame *pTextFrame = static_cast< const SwTextFrame * >( pPrevFrame );
        if (pTextFrame) {
            if (pTextFrame->GetTextNode()) {
                if(pTextFrame->GetTextNode()->HasBullet()) {
                    nUpper += 20;
                }
            }   
        }
    }

The problem goes away.

Surely, what we are doing here is to just make an arbitrary addition on nUpper. I did so for testing purposes only. I'll try to think about something based on the font metrics of such text node (probably external leading).

The good thing: this fix solves the problem and doesn't breaks any test! So, I think we are really close to fix now.
Comment 15 Marco Diego Aurélio Mesquita 2018-06-13 15:01:58 UTC
It looks like MSWORD adds a 20% bigger line spacing on bullet list items than LibO.
Comment 16 Marco Diego Aurélio Mesquita 2018-06-13 15:05:52 UTC
Created attachment 142706 [details]
Patch that fixes the problem

Attached patch fixes the problem by increasing line spacing of bullet list items by 20%. It still has some leftovers from previous experiments I tried earlier to fix the bug.

I'll clean it up and rebase it to current master. We'll soon have a proper patch to fix this problem.
Comment 17 Marco Diego Aurélio Mesquita 2018-06-13 18:34:08 UTC Comment hidden (me-too)
Comment 18 Marco Diego Aurélio Mesquita 2018-06-13 18:36:22 UTC
Created attachment 142716 [details]
Patch that fixes the bug.

It looks like 15% is better.
Comment 19 Timur 2018-11-07 11:17:53 UTC
I don't repro this in Windows, but I do in Linux with 6.2+.
This is a slight height mismatch that results in "1.2" on 1st page due to "keep with.."
See Bug 92502. Bug 82168 is not related.
Comment 20 Marco Diego Aurélio Mesquita 2018-11-08 16:00:47 UTC
For the record, the change introduced by 6acf1c7ab7b514a8713ed66b74efbee1a75f029a (commit which regressed Bug 82168 ) lives on https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/outdev/font.cxx line 229.
Comment 21 Marco Diego Aurélio Mesquita 2019-06-17 17:19:46 UTC
Considering comment https://bugs.documentfoundation.org/show_bug.cgi?id=92502#c18 it may be possible that the font in question here has "problematic" metrics.

Maybe it is possible to just specify something like https://cgit.freedesktop.org/libreoffice/core/commit/?id=d71eb1e4476d7abfe25306338527a359cd22ba09&h=libreoffice-6-1 for this problematic font specifically.

Wouldn't that fix this problem?
Comment 22 Marco Diego Aurélio Mesquita 2020-07-10 17:33:27 UTC
I re-tested it on a Ubuntu 18.04 machine. Interesting results: The problem also happens on the flatpack version:

Versão: 6.4.4.2
ID de compilação: 3d775be2011f3886db32dfd395a6a6d1ca2630ff;

Also on (flatpack) ONLYOFFICE Desktop Editors versão 5.5.1.78; And also on abiword 3.0.2
(installed via apt-get). This made me think that the problem was caused by the metrics on the distributed fonts as described by https://bugs.documentfoundation.org/show_bug.cgi?id=92502#c18 . Then I tested it Calligra words (3.0.1 installed via apt-get) and the problem didn't happen...

I then considered https://bugs.documentfoundation.org/show_bug.cgi?id=112558#c21 and check some combinations on tools->options->writer->compatibility. After enabling "Add spacing betweem paragraphs and tables", "Use OpenOffice 1.1 line spacing" and clicking "Apply" the problem was gone.

So, I think the solution maybe just to enable these compatibility options around bullet lists. What do devs think?
Comment 23 Marco Diego Aurélio Mesquita 2020-07-10 17:36:21 UTC
Created attachment 162892 [details]
LO 6.4.4.2 compatibility "Add spacing betweem paragraphs and tables" and "Use OpenOffice 1.1 line spacing" options enabled

Here it is possible to see the effect of "Add spacing betweem paragraphs and tables" and "Use OpenOffice 1.1 line spacing" compatibility options enabled in LO 6.4.4.2.
Comment 24 Marco Diego Aurélio Mesquita 2021-08-17 17:13:59 UTC
I tried it again on Ubuntu 20.04 with libreoffice 7.1.5.2 installed through flatpak. Problem still happens.

A very interesting find: I tried MSO 2016 (office 365) installed with wine and the output was the same as libreoffice.

I then tried with MSO (same version I have on my machine) running on MacOS and it appeared correct there.

This makes me think the problem is related to the metrics of the font. I still suggest a fix that changes the metrics specifically for this font spacing when using a bullet list.
Comment 25 Marco Diego Aurélio Mesquita 2021-08-17 17:19:40 UTC
Actually Office16, not MSO 2016.
Comment 26 Marco Diego Aurélio Mesquita 2021-08-17 17:39:01 UTC
Another strong evidence: after "winetricks corefonts" MSO under wine displayed to file just like its MacOS version. Unfortunately "apt install ttf-mscorefonts-installer" had no effect on libreoffice (the non flatpak version).