Bug 106111 - Display, PDF, print and print preview broken for all spreadsheets with line breaks (5.3 regression) (steps in comment 40)
Summary: Display, PDF, print and print preview broken for all spreadsheets with line b...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering Universal-Line-Spacing
  Show dependency treegraph
 
Reported: 2017-02-20 18:49 UTC by OfficeUser
Modified: 2017-10-02 17:43 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
issue.ods (21.77 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-02-20 18:51 UTC, OfficeUser
Details
issue.pdf (39.97 KB, application/pdf)
2017-02-20 18:51 UTC, OfficeUser
Details
LibreOffice Calc at 100 percent zoom level.png (2.96 KB, image/png)
2017-02-20 18:51 UTC, OfficeUser
Details
PDF.png (33.14 KB, image/png)
2017-02-20 18:52 UTC, OfficeUser
Details
screenshots_comparison_of_display_rendering.png (95.69 KB, image/png)
2017-03-07 19:50 UTC, OfficeUser
Details
Comparison before and after caolán's commit (107.79 KB, image/png)
2017-09-07 09:51 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description OfficeUser 2017-02-20 18:49:35 UTC
Text is cut in cells with line breaks in PDF export and printer output although automatic column height (double-click) has been applied

Attached you find two screenshots. One of Calc at 100 % zoom level after automatic column height has bee applied and another screenshot of the exported PDF. You can see that in calc the text is not (but nearly) overlapping while it is in the exported PDF (as well as when printed to paper).

Interesting is that when increasing the zoom level in the attached spreadsheet in calc to 120 or 140 % the text begins to overlap, too.

The overlapping printer and PDF output although auto height has been applied seems to be a regression that I haven't seen before using 5.3 builds (whereas the issue with cells and its text contents not zooming equally is an old issue).

Might be related to Bug 105860.



Bug found with
Version: 5.3.0.3
Build-ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU-Threads: 8; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE); Calc: CL
Comment 1 OfficeUser 2017-02-20 18:51:02 UTC
Created attachment 131368 [details]
issue.ods
Comment 2 OfficeUser 2017-02-20 18:51:19 UTC
Created attachment 131369 [details]
issue.pdf
Comment 3 OfficeUser 2017-02-20 18:51:42 UTC
Created attachment 131370 [details]
LibreOffice Calc at 100 percent zoom level.png
Comment 4 OfficeUser 2017-02-20 18:52:02 UTC
Created attachment 131371 [details]
PDF.png
Comment 5 OfficeUser 2017-02-20 19:22:30 UTC
Correction: column -> row
Comment 6 OfficeUser 2017-02-20 19:36:16 UTC
I added this one to Bug 103729.
Comment 7 OfficeUser 2017-02-20 19:37:14 UTC
The reason is very likely the new layout engine.
Comment 8 Khaled Hosny 2017-02-20 19:39:06 UTC
Can you try disabling the new layout engine (e.g. by setting SAL_NO_COMMON_LAYOUT env variable)?
Comment 9 OfficeUser 2017-02-20 20:00:00 UTC
I tried the old layout engine by the following instruction:
"Tools - Options - Advanced: Expert config. Paste in the search box and search for: TextLayoutEngine Then click Edit and change it to old. Then restart LibreOffice"

The exported PDF was overlapping the same way. So I am not sure if this is related with the new layout engine.
Comment 10 m.a.riosv 2017-02-20 22:06:14 UTC
With the option:
Menu/Tools/LibreOffice calc/General - >Use printer metrics for text formatting.
produce a right pdf.

Version: 5.3.0.3 (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: es-ES (es_ES); Calc: group
Comment 11 OfficeUser 2017-02-21 07:36:12 UTC
I just tried build 5.2.3.3:

With 5.2.3.3 issue.ods directly exported to PDF without any adjustments leads to the same bad output.

But I notice that build 5.2.3.3 displays only 3 if the 4 rows on screen. If I do a double-click to auto-adjust the row heights, build 5.2.3.3 displays all 4 lines AND will produce a good PDF/printing result.


So the regression bug in 5.3.0.3 release is that the fonts are displayed with other size and that auto-adjust fails to calculate the correct row heights. Interesting is that with zoom level greater than 100 % (for example 120 %) the result is better.
Comment 12 Heiko Tietze 2017-02-21 08:32:17 UTC
It was requested to make this ticket a MAB as it affects many users and breaks the workflow. QA, please take action if you agree.
Comment 13 Xisco Faulí 2017-02-21 17:11:15 UTC
(In reply to Heiko Tietze from comment #12)
> It was requested to make this ticket a MAB as it affects many users and
> breaks the workflow. QA, please take action if you agree.

@Heiko, why is it requested to be a MAB bug? How many is many users?
Comment 14 Buovjaga 2017-02-21 18:49:09 UTC
Heiko: see previous question.
Comment 15 Heiko Tietze 2017-02-21 20:38:34 UTC
(In reply to Xisco Faulí from comment #13)
> @Heiko, why is it requested to be a MAB bug? How many is many users?

Question forwarded to the OP (the discussion runs in the DE telegram channel and I'm not fully aware of all aspects).
Comment 16 OfficeUser 2017-02-22 08:52:12 UTC
>> @Heiko, why is it requested to be a MAB bug? How many is many users?

It affects many users - I expect millions of users - since printing of spreadsheets with automatic adjusted row heights is a very basic and very often used function.
Comment 17 Buovjaga 2017-02-22 09:02:13 UTC
(In reply to OfficeUser from comment #16)
> >> @Heiko, why is it requested to be a MAB bug? How many is many users?
> 
> It affects many users - I expect millions of users - since printing of
> spreadsheets with automatic adjusted row heights is a very basic and very
> often used function.

In comment 10 we have a workaround, so this definitely does not qualify as highest - critical per https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
It could be kept at exactly where it is, but let's raise priority and add the correct keywords.
Comment 18 m.a.riosv 2017-02-22 22:23:43 UTC
> (In reply to OfficeUser from comment #16)
> .........
> In comment 10 we have a workaround, so this definitely does not qualify as
> .........

IMO, not a workaround, but the rigth way, it's how LibreOffice should work and being eliminated as option.
Comment 19 OfficeUser 2017-03-05 15:10:37 UTC
Instructions for bibisecting:

With each build do...

- Open issue.ods (attached to this bug report)

- Click the top-left between row 1 and column A to select the whole spreadsheet

- On the left side double-click the line between the buttons for row 1 and row 2 to auto-adjust the height of all rows

- Export as PDF file

- Open the PDF file in a PDF viewer and check if the result is bad or good (see attached PDF.png for a bad reference)
Comment 20 Xisco Faulí 2017-03-05 20:35:14 UTC
I can reproduce it in

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)
Comment 21 Xisco Faulí 2017-03-05 21:46:38 UTC
Regression introduced by:

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

Adding Cc: to Khaled Hosny
Comment 22 Xisco Faulí 2017-03-05 21:47:59 UTC Comment hidden (obsolete)
Comment 23 Khaled Hosny 2017-03-05 22:03:50 UTC
No idea what is going on, why calculating correct line height would affect PDF/printing differently than the rendering on screen?
Comment 24 Xisco Faulí 2017-03-05 22:08:54 UTC Comment hidden (obsolete)
Comment 25 OfficeUser 2017-03-05 22:10:22 UTC
@Xisco: Thank you very much for the successful bisect!

This patch makes so much trouble and must be revoked asap with effect for the next  bugfix release. Is it already revoked from the branch?

*** This bug has been marked as a duplicate of bug 105860 ***
Comment 26 OfficeUser 2017-03-05 22:22:55 UTC Comment hidden (no-value)
Comment 27 OfficeUser 2017-03-05 22:23:09 UTC Comment hidden (no-value)
Comment 28 Khaled Hosny 2017-03-05 23:12:02 UTC
So we are calculating different line spacing when printing? This seems seriously broken and probably indicates a bigger problem, can any one reproduce this on other platforms?
Comment 29 Xisco Faulí 2017-03-05 23:19:09 UTC
I can also reproduce it on window 7 with build

Version: 5.4.0.0.alpha0+
Build ID: eb7b03b052ffe8c2c577b2349987653db6c53f76
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-26_22:34:18
Locale: es-ES (es_ES); Calc: group
Comment 30 Khaled Hosny 2017-03-05 23:50:50 UTC
Sorry, I meant platforms other than Windows.
Comment 31 OfficeUser 2017-03-06 07:59:23 UTC
I can reproduce the bug on both Linux and Windows.

("Reproduce" is understated. I suffer from this bug daily.)
Comment 32 Khaled Hosny 2017-03-06 23:53:55 UTC
I can reproduce this on Linux as well, but I have absolutely no idea what is going on and why a change in line height calculation would make any difference between print and non-print output. Furthermore I don’t even know what “Use printer metrics for text formatting” and why it is even an option. This needs input from someone who understands Calc code, and I feel that the line height change is red herring and the real issue lies somewhere else.
Comment 33 Buovjaga 2017-03-07 06:53:29 UTC
(In reply to Khaled Hosny from comment #32)
> This needs input from someone who understands Calc code, and I feel that the
> line height change is red herring and the real issue lies somewhere else.

Eike: can you give input?
Comment 34 OfficeUser 2017-03-07 19:50:34 UTC
Created attachment 131730 [details]
screenshots_comparison_of_display_rendering.png
Comment 35 OfficeUser 2017-03-07 19:55:13 UTC
@khaled please note that your patch not only has destructed the print output. It has negative impact on the display output too!

Please have a look at my attached file
screenshots_comparison_of_display_rendering.png
https://bugs.documentfoundation.org/attachment.cgi?id=131730
Comment 36 OfficeUser 2017-03-07 19:58:15 UTC
Both screenshots have been taken after automatically adjusting the rows heights.
Comment 37 OfficeUser 2017-03-11 14:09:10 UTC Comment hidden (no-value)
Comment 38 OfficeUser 2017-03-19 10:01:12 UTC
Version: 5.3.1.2 is still defect.

Even the print preview is totally distorted!

@Khaled: Is there any progress? Do you need support? If yes, do you get support? If there is no progress or any plan how to proceed we need to revoke these changes.

The patch has broken Calc's print functions for millions of users! The advantages of your patch to achieve more consistent rendering across platforms does not outweigh these tremendous disadvantages.
Comment 39 OfficeUser 2017-03-19 10:07:55 UTC Comment hidden (no-value)
Comment 40 OfficeUser 2017-03-19 10:12:19 UTC
In addition each spreadsheet with line breaks is broken:


Easy steps to reproduce from scratch:

- Open a blank spreadsheet in a 5.3.x build

- I cell A1 enter

THIS IS[CTRL+RETURN]
CELL A1


- I cell A2 enter

THIS IS[CTRL+RETURN]
CELL A2

- Apply a visible border grid to the spreadsheet

- Go to print preview

Result: Border lines go through cell content
Comment 41 Volga 2017-04-07 15:49:20 UTC
What happened if you print with PDFCreator?
Comment 42 OfficeUser 2017-05-23 10:31:55 UTC
*** Bug 106393 has been marked as a duplicate of this bug. ***
Comment 43 OfficeUser 2017-05-23 10:34:18 UTC
Perhaps related with bug 106393.
Comment 44 OfficeUser 2017-05-24 10:59:30 UTC
*** Bug 106393 has been marked as a duplicate of this bug. ***
Comment 45 OfficeUser 2017-05-24 11:02:44 UTC
Why can't we set "Use printer metrics for text formatting" ON by default and remove it as an option? Does this option turned ON have any negative impacts?

Please also refer to Bug 106393#c4.
Comment 46 OfficeUser 2017-05-24 12:00:43 UTC
*** Bug 104570 has been marked as a duplicate of this bug. ***
Comment 47 OfficeUser 2017-05-24 12:04:18 UTC
Bug 47977 might be related.
Comment 48 OfficeUser 2017-05-24 12:08:35 UTC
It looks like the patch that has turned out as regression just makes an old and massive scaling bug of Calc more visible.
Comment 49 OfficeUser 2017-05-24 12:09:07 UTC
There are many related bug reports.
Comment 50 OfficeUser 2017-06-04 13:27:58 UTC
Additional regression introduced by  Khaled's patch:

Bug 107249
Comment 51 OfficeUser 2017-06-04 13:32:00 UTC
The following screenshot from Bug 107249 throws new light onto Khaled's patch. Since the GUI is affected too we cannot consider the regression a Calc-only problem.


https://bug-attachments.documentfoundation.org/attachment.cgi?id=132669
Comment 52 Yousuf Philips (jay) (retired) 2017-06-04 14:02:08 UTC
Lets see if this issue also affects mac users.

@Alex, @Steve, @Telesto: Can either of you guys confirm this?
Comment 53 Buovjaga 2017-06-27 17:23:29 UTC
*** Bug 108638 has been marked as a duplicate of this bug. ***
Comment 54 Alex Thurgood 2017-06-28 15:21:18 UTC
(In reply to Yousuf Philips (jay) from comment #52)
> Lets see if this issue also affects mac users.
> 
> @Alex, @Steve, @Telesto: Can either of you guys confirm this?

No repro for me with 

Version: 5.3.2.2
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
Threads CPU : 8; Version de l'OS :Mac OS X 10.12.5; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Comment 55 OfficeUser 2017-06-29 11:45:46 UTC
(In reply to OfficeUser from comment #45)
> Why can't we set "Use printer metrics for text formatting" ON by default and
> remove it as an option? Does this option turned ON have any negative impacts?
> 
> Please also refer to Bug 106393#c4.

After trying out working with "Use printer metrics for text formatting" turned ON I don't recommend to turn it on by default. The problem is that when entering cell edit mode, the text content is shrinked because it is rendered by the bad patch. When leaving cell edit mode the text content is enlarged again. This is bad user experience.
Comment 56 Dale 2017-07-02 00:27:04 UTC
A similar problem exists in Writer web view. Line spacing changes with zoom, and never matches normal view or the printer output. This problem existed in earlier versions but got massively worse from 5.3. See my bug 108710 for details.
Comment 57 Steve Edmonds 2017-08-21 21:07:24 UTC
This effect also seems font related. If I change the font in a cell of issue.ods from Arial to Andale Sans the problem virtually vanishes for me.
Comment 58 Stefan_Lange_KA@T-Online.de 2017-08-22 19:44:14 UTC
I have made a test with duplicate Bug 108638: The Problem also exists when original font (= Liberation Sans) is replaced by Andale Sans UI.
Comment 59 Steve Edmonds 2017-08-22 21:23:10 UTC
That is interesting as for me the original of that document clips the top of the text. When I change to Andale Sans I get no clipping although the alignment in the cell is not perfect it is quite acceptable. Opensuse Leap 42.3, Version: 5.3.3.2
Build ID: 30m0(Build:2) from Opensuse. My Andale Sans is a TTF may be 10 years old. Nvidia drivers, hardware acceleration, antialiasing, no OpenGL.
Comment 60 Xisco Faulí 2017-09-07 09:51:25 UTC
(In reply to OfficeUser from comment #40)
> In addition each spreadsheet with line breaks is broken:
> 
> 
> Easy steps to reproduce from scratch:
> 
> - Open a blank spreadsheet in a 5.3.x build
> 
> - I cell A1 enter
> 
> THIS IS[CTRL+RETURN]
> CELL A1
> 
> 
> - I cell A2 enter
> 
> THIS IS[CTRL+RETURN]
> CELL A2
> 
> - Apply a visible border grid to the spreadsheet
> 
> - Go to print preview
> 
> Result: Border lines go through cell content

Fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=0c8b749e602b6743857a9bc4efb24b6183690311
Comment 61 Xisco Faulí 2017-09-07 09:51:51 UTC
Created attachment 136091 [details]
Comparison before and after caolán's commit
Comment 62 OfficeUser 2017-09-07 19:51:40 UTC
Can confirm that this bug is fixed in:
Version: 6.0.0.0.alpha0+
Build-ID: 115bed941d7b7ed1b95d6424bfb98456c1d87546

Good work! Thanks!
Comment 63 OfficeUser 2017-09-07 20:33:50 UTC
Additional info:

I have removed the duplicate status from the zooming related bugs because they are  not covered by this patch and because I think they are not related to Khaled's patch.

The zooming bug is now covered in bug 108638 separately again.