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
Created attachment 131368 [details] issue.ods
Created attachment 131369 [details] issue.pdf
Created attachment 131370 [details] LibreOffice Calc at 100 percent zoom level.png
Created attachment 131371 [details] PDF.png
Correction: column -> row
I added this one to Bug 103729.
The reason is very likely the new layout engine.
Can you try disabling the new layout engine (e.g. by setting SAL_NO_COMMON_LAYOUT env variable)?
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.
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
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.
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.
(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?
Heiko: see previous question.
(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).
>> @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 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.
> (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.
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)
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)
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
Same commit as in bug 105860. Closing as RESOLVED DUPLICATED *** This bug has been marked as a duplicate of bug 105860 ***
No idea what is going on, why calculating correct line height would affect PDF/printing differently than the rendering on screen?
I think better to keep it open...
@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 ***
Can set 5.3.1 as target milestone?
Can we set 5.3.1 as target milestone?
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?
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
Sorry, I meant platforms other than Windows.
I can reproduce the bug on both Linux and Windows. ("Reproduce" is understated. I suffer from this bug daily.)
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.
(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?
Created attachment 131730 [details] screenshots_comparison_of_display_rendering.png
@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
Both screenshots have been taken after automatically adjusting the rows heights.
Hi. Any progress?
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.
I am voting for importance "major"! Each machine and platform I try is broken.
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
What happened if you print with PDFCreator?
*** Bug 106393 has been marked as a duplicate of this bug. ***
Perhaps related with bug 106393.
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.
*** Bug 104570 has been marked as a duplicate of this bug. ***
Bug 47977 might be related.
It looks like the patch that has turned out as regression just makes an old and massive scaling bug of Calc more visible.
There are many related bug reports.
Additional regression introduced by Khaled's patch: Bug 107249
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
Lets see if this issue also affects mac users. @Alex, @Steve, @Telesto: Can either of you guys confirm this?
*** Bug 108638 has been marked as a duplicate of this bug. ***
(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
(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.
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.
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.
I have made a test with duplicate Bug 108638: The Problem also exists when original font (= Liberation Sans) is replaced by Andale Sans UI.
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.
(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
Created attachment 136091 [details] Comparison before and after caolán's commit
Can confirm that this bug is fixed in: Version: 6.0.0.0.alpha0+ Build-ID: 115bed941d7b7ed1b95d6424bfb98456c1d87546 Good work! Thanks!
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.