Description: In the new 24.2.0.3 version, I found new bugs at FILEOPEN on the existing FORMATTING : - the new version can completely ruin the cell sizes (row height) of the existing table. (xlsx table) - Unwanted change in the character colors in the existing table - on green background the black chars changed when oened the file to white char on the green backgroud! (xlsx table) The above problem massively occurs when use the "*.xlsx " file formats, especially the changing of the cell sizes (height) every time when the file opened. The .xlsx file was created many versions ago, an last time it was used without any problem with the installed verion 7.6.4 ( Hungarian language) on Windows 10 Home and Windows 11 professional. Operating systems with the regular updates. After installing (update) the Libreoffice 24.2.0.3 version (64 bit) We found with the file above mentioned bugs after opening the file, it made the mentioned bug on all the existing pages (Rows height changed to a nonses high, the characters that originally was black char on green backround changet to a nonsense white colored char on green backround). This bug occurs on both win11 pro and win 10 home. If you correct manually the format to the old xls format, it's ok, but if you save it on any xlsx format at the next open bugs happen again. I also found the same bugs, especially the unwanted changing of the rows height, in a new xlsx file created newly from scratch and after I put 4 or 5 pages and just copy-pasted the content from an xls format file, after saving the new xlsx file and reopen it. Steps to Reproduce: 1. conditional format in some cell area, first 3 row freeze,etc 2. save xlsx format 3.reload xlsx file Actual Results: on formatted pages, the rows height randomly and unwantedly increased insome caseses black chars on green background changed to white chars Expected Results: not changing presetted row heights, remain the previous as it saved also the character colors Reproducible: Always User Profile Reset: No Additional Info: If it helps I can send a - not public - xlsx example just for the developer to help We tried it on different windows versions (10, 11, home professional) and different machines with the same result.
Created attachment 192413 [details] example of unwanted changes
Please attach a sample file, reduce the size as much as possible without private information, and paste the information in Menu/Help/About LibreOffice, there is a copy icon.
Created attachment 192422 [details] Exampe file - xls contains good formatting
Created attachment 192423 [details] Example file - wrong row height randomly changed in the same file just in xlsx format
Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded I also enclose 2 sample: The file: Example_bug_202402_Good file.xls contains the sample data in xls format and on the pages you can see the height of the rows The file: Example_bug_202402_Wrong file.xlsx is the same file saved as xlsx format, and when you open it in version 24.2.0.3 - you can see on the pages, that most of the rows height changed for some unknown reason, just because it is in the xlsx format. On the earlier versions there was no such a problem. One more interesting thing, is that not every file is affected consequently, but the sample files did the bug consequently. The sample file are made from scratch as the original problematic xlsx file, and contains similar cell, character, and conditional formatting, etc. BR
(In reply to laszlo.mraz from comment #5) > I also enclose 2 sample: > The file: Example_bug_202402_Good file.xls contains the sample data in xls > format and on the pages you can see the height of the rows > > The file: Example_bug_202402_Wrong file.xlsx is the same file saved as xlsx > format, and when you open it in version 24.2.0.3 - you can see on the pages, > that most of the rows height changed for some unknown reason, just because > it is in the xlsx format. Please specify which exact spreadsheet (name) we should be looking at for the problem, and in that spreadsheet, which cell/row/column would have the problem.
At opening both files looks similar but after an Optimal row height, on the open xlsx the height on the screen are seen less than in xls, even parameters and zoom for that are the same. Saving the xls as xlsx, the file behaves the same as the xlsx sample file. I think something about that was done time ago, but I can't find it.
Created attachment 192434 [details] One more example picture of the BUG - shows side by side the good and wrong row height The wrong XLSX file marked red on the picture, with the BUG row height
Just compare the pages side by side on the good (xls) and the wrong (xlsx file) Especially easy to see the difference on pages "202402", watch the height of the rows. The same difference on 202403 page, and on "Új_minta page Otherwise you can see row height differences in rows of 202401 I enclosed a side by side screenshot from the page 202402. Clearly can be seen the difference. You can see the difference clearly on the other pages. Sorry to say, but it is not a "feature" For me it is clearly a "bug". I know it can be hard to find the reason of it, but this problem exists, and exists on different laptops, on different windows versions, if Libreoffice version is 2024.2.0.3 See Libreoffice 24_2__bug_sample_side_by_side.png file BR
So, the answer to my question in comment 6 is much simpler: In attachment 192422 [details] vs attachment 192423 [details], in both cases compare row height in spreadsheet "202402" cell "AM9" (as example). STR: 1. Starting with attachment 192422 [details] (xls) 2. Save as (some other name) XLSX with a recent 24.8 alpha. 3. Close file. 4. Open the newly created file (in step 2). For me: * Worksheet "202402" cell "AM9" in the original attachment 192422 [details] (xls) is 5.17 mm. * Worksheet "202402" cell "AM9" in the newly saved_and_reloaded xlsx is 6.79 mm. IDK whether the difference is related to some new default font spacing, default font (replacement?), or how the save/export of row heights is treated now for XLS and XLSX respectively. Perhaps some "automatic optimal row height" was disabled (maybe for performance issues?). Manually applying "Optimal Height" on the "new" cell seems to reduce the difference (almost completely), at least for the specific mentioned cell.
To complete my test from comment 10, I repeated the same STR using LO 7.6.3.2 and the height of the same cell is not modified. So, repro in recent 24.8; not repro in 7.6.3.2.
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Justin Luth ; Could you possibly take a look at this one? Thanks b3c14523e3d622babc44ea6b0bc7e5c24eb14c00 is the first bad commit commit b3c14523e3d622babc44ea6b0bc7e5c24eb14c00 Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Jul 11 19:46:40 2023 +0200 source d15c4caabaa21e0efe3a08ffbe145390e802bab9 140260: tdf#123026 xlsx import: recalc optimal row height on import | https://gerrit.libreoffice.org/c/core/+/140260
Created attachment 192442 [details] 159581_optimalHeight.ods: minimal example Fortunately my change just exposed an existing problem with the optimalRowHeight routine. https://gerrit.libreoffice.org/c/core/+/163066
Using my example, ScColumn::GetOptimalHeight was using the RowHeightContext as a cache to compare the current row height against: Sheet1 row[0] if nHeight[1149[ > CxtHeight[255] row[3] if nHeight[925[ > CxtHeight[255] Sheet2 row[0] if nHeight[253[ > CxtHeight[1149] row[1] if nHeight[253[ > CxtHeight[255] row[2] if nHeight[253[ > CxtHeight[255] row[3] if nHeight[253[ > CxtHeight[925] row[4] if nHeight[253[ > CxtHeight[255] row[5] if nHeight[253[ > CxtHeight[255] row[6] if nHeight[253[ > CxtHeight[255]
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/648c7c0f17125fd77d29be3c0611e1ab92f36b7f tdf#159581 sc: fix multi-sheet ScDocRowHeightUpdater It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/c723758d0540bdb4846eefb4b50b4bde212f1985 tdf#159581 sc: fix multi-sheet ScDocRowHeightUpdater It will be available in 24.2.1. 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.