Created attachment 142382 [details]
File in which problem happens

File that reproduces the problem.

Created attachment 142383 [details]
How the file is displayed on MSO 2007

PDF of file rendereb by MSO word 2007.

Created attachment 142384 [details]
How the file is rendered by Libreoffice 6.0

File rendered by LO 6.0.4.2.

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

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.

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?

NOt sure, but maybe this is a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=115944 . Can anyone confirm?

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 .

*** Bug 118050 has been marked as a duplicate of this bug. ***

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.

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.

Created attachment 142605 [details]
How the file is rendered by LO 5.2.7.2

How Libreoffice 5.2.7.2 renders the file.

(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 .

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.

It looks like MSWORD adds a 20% bigger line spacing on bullet list items than LibO.

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.

Created attachment 142716 [details]
Patch that fixes the bug.

It looks like 15% is better.

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.

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.

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?

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?

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.

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.

Actually Office16, not MSO 2016.

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).

Dear Marco Diego Aurélio Mesquita,

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