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
Created attachment 146147 [details] how it looks after the commit
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
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?
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
No repro 6.2+ in Windows. Repro 6.2+ in Mint 18.3 with PDF printer. So I mark "Linux".
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
Created attachment 148724 [details] How it looks after the commit on Windows (correct)
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.
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).
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.
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".
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
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)
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
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.
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.
This is fixed as much as possible.
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.
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
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.
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.