Bug 121040 - Different row height calculation in Linux and Windows in specific ODS
Summary: Different row height calculation in Linux and Windows in specific ODS
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.1.3.2 release
Hardware: All Linux (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard: target:6.3.0 target:6.2.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2018-10-29 17:42 UTC by Xisco Faulí
Modified: 2019-03-14 15:39 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
How it looks before the commit (37.97 KB, application/pdf)
2018-10-29 17:42 UTC, Xisco Faulí
Details
how it looks after the commit (38.93 KB, application/pdf)
2018-10-29 17:43 UTC, Xisco Faulí
Details
How it looks after the commit on Windows (correct) (54.15 KB, application/pdf)
2019-01-29 09:21 UTC, Serge Krot (CIB)
Details
Example file compared Win Lin (622.30 KB, image/jpeg)
2019-01-29 15:32 UTC, Timur
Details
Screenshot of MS Excel and LibO Calc side-by-side (672.79 KB, image/png)
2019-02-08 12:11 UTC, Katarina Behrens (CIB)
Details
Comparison Linux and Windows ( master ) (283.99 KB, image/png)
2019-03-13 16:35 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2018-10-29 17:42:43 UTC
Created attachment 146146 [details]
How it looks before the commit

Steps to Reproduce:
1. Open attachment 144217 [details]
2. select cells A114:G132
3. Ctrl + P - print
4. select option 'selected cells'

-> Observed behaviour: 2 pages will be printed instead of 1. You can check it in the print preview or printing to PDF

Reproduced in

Version: 6.2.0.0.alpha1+
Build ID: 19a0698079fbba36646a2d06eaec3a7fde60b2f5
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Comment 1 Xisco Faulí 2018-10-29 17:43:04 UTC
Created attachment 146147 [details]
how it looks after the commit
Comment 2 Xisco Faulí 2018-10-29 17:44:46 UTC
Regression introduced by:

author	Vasily Melenchuk <Vasily.Melenchuk@cib.de>	2018-04-06 20:19:10 +0300
committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2018-06-08 00:47:06 +0200
commit	1e55a47e89a9d9d6cf9cb3993484022aaf2c097b (patch)
tree	3a3372525645775c32721e59ce8c205c8f474ffd
parent	2a7f74900fb646235b74d4c9bd4690e44edc3ed4 (diff)
tdf#62268: allow row height recalculation on document load
During document load rows with style:use-optimal-row-height="true"
should recalculate it's height.

Bisected with: bibisect-linux64-6.2

Adding Cc: to Vasily Melenchuk
Comment 3 Vasily Melenchuk (CIB) 2018-11-02 13:42:09 UTC
Can NOT reproduce this bug with:

not with my dbgutil version:
Version: 6.2.0.0.alpha0+ (x64)
Build ID: f96e284fbbf32db2b7a87c96a9defeaee93e3feb
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-US (C); Calc: threaded

not with nightly build:
Version: 6.2.0.0.alpha1+ (x64)
Build ID: 1239dce2595877ad64fd8c8fd927ea4285d69abe
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-02_02:10:12
Locale: en-US (C); Calc: threaded


Not reproducible in Windows?
Comment 4 Oliver Brinzing 2018-11-02 14:17:43 UTC
me too, no repro with:

Version: 6.2.0.0.alpha1+ (x64)
Build ID: cd472d1d8489f30797f47d3f6dafede28c1feb90
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: de-DE (de_DE); Calc: threaded
Comment 5 Timur 2018-11-02 17:02:14 UTC
No repro 6.2+ in Windows. 
Repro 6.2+ in Mint 18.3 with PDF printer. So I mark "Linux".
Comment 6 Xisco Faulí 2018-11-02 17:32:38 UTC
Indeed. Reproduced in

Version: 6.2.0.0.alpha1+
Build ID: 5929d8ea469a971aa77371ed4b841c90a36e7da5
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

but not in

Version: 6.2.0.0.alpha0+
Build ID: 3f9c477929c261a8862411c00153e4c7d0d0ae7c
CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: en-GB (en_GB); Calc: threaded
Comment 7 Serge Krot (CIB) 2019-01-29 09:21:55 UTC
Created attachment 148724 [details]
How it looks after the commit on Windows (correct)
Comment 8 Serge Krot (CIB) 2019-01-29 09:52:53 UTC
Status:

1. Before commit#1e55a47e89a9d9d6cf9cb3993484022aaf2c097b
- In attachment#144217 [details] cells were overlapped which cause an error in output, see the same issue inside tdf#62268.
This is easy to see: 4th row is overlapped with 5th row in attachment#146146 [details] printing to PDF.

2. After commit#1e55a47e89a9d9d6cf9cb3993484022aaf2c097b
- On Windows: attachment#144217 [details] produces only 1 page without cells overlapping. Row distances look the same as in Calc window.
- On Linux: attachment#144217 [details] produces 2 pages with much bigger cell spacing (which is obviously error). Of course different rows height is result of the row auto-height recalculation. But itself triggering of this functionality is correct, which was done in commit#1e55a47e89a9d9d6cf9cb3993484022aaf2c097b.

Result:
- In this document we have something that leads to different row height calculation on different platforms: windows and linux.
Comment 9 Timur 2019-01-29 15:32:20 UTC
Created attachment 148738 [details]
Example file compared Win Lin

I wouldn't say it's correct in Windows. Note row 132 is missing in Win print preview but is present in Lin. 

With this font "TH SarabunPSK" (I can't say what it's replaced with) there's large difference in Page Break view: in Win page 5 starts on row 132 (so missing last page) while in Lin page 5 starts already on row 119 (where print break is). So selected cells on 2 pages is a consequence. 

So this sends us back at Bug 119189 where this attachment comes from. I'd say this bug may be redundant, just another duplicate of Bug 120161.
I'll close this one. Feel free to feel offended and explain why this is YABTRO (yet another bug to remain open).
Comment 10 Timur 2019-01-29 15:36:17 UTC
Or maybe better: let's discard "print preview" issue and keep this bug for different row height calculation and Page Break in Linux and Windows in ODS attachment.
Comment 11 Serge Krot (CIB) 2019-02-01 09:13:37 UTC
When visually number in cell is bigger than width of the cell: LO writes in this cell "###". In this case we see much bigger height of the cell comparing to the same cell with smaller number. It looks like that actually cell height is taken from formatted real big number but not according to height of the "###".

If we modify our test case:

Under Linux we have: For the value "-39170" which is displayed as "-39.170,00":
- It is shown with bigger height with "-39.170,00" value.
- If you add "any" digits in it (for example "-139.170,00") the cell height will be the same (bigger) with value "###".
- If you remove "any" digits in it (for example "-3.917,00") the cell height will be smaller (normal) with value "-3.170,00".

Under Windows we have: For the value "-39170" which is displayed as "-39.170,00":
- It is shown with smaller (normal) height with "-39.170,00" value.
- If you add "any" digits in it (for example "-139.170,00") the cell height will be bigger with value "###".
- If you remove "any" digits in it (for example "-3.917,00") the cell height will be smaller (normal) with value "-3.170,00".
Comment 12 Katarina Behrens (CIB) 2019-02-08 11:39:21 UTC
There are differences across platforms in calculating how much width and height a particular text takes, even when all factors are the same (font type, font size, the text itself). Those are hard to explain and hard to eliminate entirely, this is why some unit tests do only fuzzy comparison and some unit tests are disabled entirely (on Windows or Mac)

It is unfortunate that in this particular document those differences accumulate to such an extreme extent. However, the previous behaviour (optimal row height not applied) was a bug. Current behaviour (optimal row height applied, if set) is not a bug.

There is something else though that amplifies those cross-platform differences, I'll describe it in the next comment
Comment 13 Katarina Behrens (CIB) 2019-02-08 12:01:03 UTC
I did the following experiment with both LibO Calc (6.1) and MS Excel (2013)

1. in a blank document, set optimal row height to rows 1,2 and 3 
2. format cells A1, A2, A3 in such a way that they wrap text automatically (Format cells > Alignment > Wrap text automatically)
3. Insert some large number into A1, give it Number > General format
4. Copy A1 to A2, but give it Number > any format with at least 2 decimal places
5. insert today's date into A3, give it Date > sufficiently verbose date format
6. Now shrink column 1 in such a way that A1 is still fully visible (no ###), but A2 no longer is (watch out tho, if you shrink too much, the number in A1 might get re-formatted to e.g. engineering notation, shrink only so much that it stays in its original form)

What happens in LibO now is that as long as 'wrap text automatically' is set in LibO, row height grows (to accomodate the content + inserted line breaks). 

EXCEPT FOR cell A1, which has 'General' number format. This format is flexible and can e.g. reduce number of decimal places or switch to engineering notation to make the content fit the width of the cell

What happens in Excel is that NONE of the row heights grow. Excel seemingly ignores 'wrap text automatically' for ALL numeric (value) cells, even for those with very verbose date formats 

So the proposal is to make Calc behave in compatible way w/ MS Excel 

(as it used to before https://cgit.freedesktop.org/libreoffice/core/commit/?h=aoo/trunk&id=de8ad25e0efc05f6ebc083349fc53f99563de6bd happened ... but since the issue comes from an internal Oracle bug tracker, nobody's ever going to find out what the issue was)
Comment 14 Katarina Behrens (CIB) 2019-02-08 12:11:35 UTC
Created attachment 149024 [details]
Screenshot of MS Excel and LibO Calc side-by-side

The content of spreadsheets and the formatting of the cells (optimal row height, automatic line wrap, individual number formats) is the same in MS Excel and LibO Calc. The difference in rendering is huge
Comment 15 Commit Notification 2019-02-12 10:30:48 UTC
Serge Krot committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/20f6e0babf3cb0dd66a2dfcfa7a15cb2d9f2592b%5E%21

tdf#121040 sc: cell with ### has too big height

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Commit Notification 2019-02-14 14:34:03 UTC
Serge Krot committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/367a2fe4880e7187092a38267d56193dcd54bc6c%5E%21

tdf#121040 sc: cell with ### has too big height

It will be available in 6.2.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Thorsten Behrens (CIB) 2019-02-14 23:59:46 UTC
This is fixed as much as possible.
Comment 18 Commit Notification 2019-03-04 13:16:27 UTC
Serge Krot committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/1b4cfd79240f153703a02d63639b3895ab7c1d1b%5E%21

tdf#121040 sc: use pixel-per-twips in X for horizontal value conversion

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Xisco Faulí 2019-03-13 16:35:48 UTC
Created attachment 149941 [details]
Comparison Linux and Windows ( master )

it looks much better now, specially after 
https://git.libreoffice.org/core/+/1b4cfd79240f153703a02d63639b3895ab7c1d1b%5E%21 ( that's why I've cherry-picked it to 6-2 and 6-2-2 )
However, the output is still different comparing Linux and Windows -> See attached screenshot
Comment 20 Commit Notification 2019-03-13 17:09:46 UTC
Serge Krot committed a patch related to this issue.
It has been pushed to "libreoffice-6-2-2":

https://git.libreoffice.org/core/+/8fb5909a4ea71f0122c4b57a4312f7b1b3ecae2f%5E%21

tdf#121040 sc: use pixel-per-twips in X for horizontal value conversion

It will be available in 6.2.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Commit Notification 2019-03-13 19:09:31 UTC
Serge Krot committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/90752744ec69241c41140db9f21bb0c9aabea957%5E%21

tdf#121040 sc: use pixel-per-twips in X for horizontal value conversion

It will be available in 6.2.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.