Bug 68375 - PRINTING: Optimal row height not working correctly (now OK in Win, still NOK in Lin)
Summary: PRINTING: Optimal row height not working correctly (now OK in Win, still NOK ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other Linux (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Print-Preview
  Show dependency treegraph
 
Reported: 2013-08-21 11:09 UTC by pavelz
Modified: 2019-02-19 16:08 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample file with optimal row heights (16.61 KB, application/vnd.oasis.opendocument.text)
2013-08-21 11:09 UTC, pavelz
Details
bug 68375 example (7.50 KB, application/vnd.ms-excel)
2015-01-19 13:04 UTC, Beuf
Details
sample for LO 5.3 (12.00 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-07-25 15:40 UTC, pavelz
Details
bug 68375 example Linux 6.1 (63.16 KB, image/jpeg)
2018-02-02 09:51 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pavelz 2013-08-21 11:09:16 UTC
Created attachment 84385 [details]
Sample file with optimal row heights

Setting optimal row height does not work for printing or print preview. Cell content in some cases is cropped or overlaps another rows. See print preview of attached file.

I did not notice such problem before 4.1.
Comment 1 retired 2013-08-21 16:07:01 UTC
With LO 4.2 master build from 2013-08-20 when opening the document, I see a cut off field. As soon as I select cell B2 (only field with content) the field gets displayed with correct size and no longer cut-off.

On OS X 10.8.4 and LO 4.2 masterbuild printing preview and saving as PDF does work fine ONLY AFTER I once clicked into the B2 cell. If I don't click into cell B2 printing preview and pdf do display a cutoff cell as described by Pavelz.

Setting to NEW.
Comment 2 Beuf 2015-01-19 13:04:47 UTC
Created attachment 112464 [details]
bug 68375 example

Another instance of the bug.
Comment 3 Beuf 2015-01-19 13:05:48 UTC
I also ran into this bug/was able to reproduce it in LibreOffice 3.5.7.2 
Build ID: 350m1(Build:2).

See attached file in print-preview mode.
Comment 4 QA Administrators 2016-02-21 08:34:15 UTC Comment hidden (obsolete)
Comment 5 pavelz 2016-02-21 10:18:58 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2017-03-06 14:52:26 UTC Comment hidden (obsolete)
Comment 7 pavelz 2017-03-06 18:12:05 UTC Comment hidden (obsolete)
Comment 8 pavelz 2017-07-25 15:40:48 UTC
Created attachment 134841 [details]
sample for LO 5.3

Still reproducible in 5.3.4

Verze: 5.3.4.2
ID sestavení: 5.3.4.2-4.fc26
Vlákna CPU: 2; Verze OS: Linux 4.11; Vykreslování UI: výchozí; VCL: gtk3; Knihovna pro rozvržení: nová; 
Národní prostředí: cs-CZ (cs_CZ.UTF-8); Calc: group
Comment 9 Timur 2018-02-01 14:57:48 UTC
This is either Linux-only or I can't reproduce. 
And I'm not sure what to reproduce, looks OK in Windows.
Please attach a screenshot of wrong and right preview (current and old LO).
Comment 10 Timur 2018-02-01 15:15:27 UTC Comment hidden (obsolete)
Comment 11 Timur 2018-02-02 09:51:05 UTC
Created attachment 139523 [details]
bug 68375 example Linux 6.1

Reproducible in Windows with 5.0.6 but not with 5.4 and master 61+.
Reproducible in Linux with 5.4. and 61+ alpha only with attachment 112464 [details] ("bug 68375 example") when optimal row height is set on row 5 and row 11.
Comment 12 Timur 2019-02-19 16:08:47 UTC
Repro in Lin with LibreOfficeDev-6.3.0.0.alpha0_2019-02-10-x86_64