Description: Before saving the .ods, line 5, the column is C2, C4, C5, C6, C7, C8, C9, C11, C12, C13, C14. The text C2 to C13 is at the 1st line and C14 at the 2nd line of the cell. After reload, only appear (and printed) C14 But, in the same column, but line 24 the same case with R9, R12, R14, R15, R16, R21, R23, R27, R32, R34 and no problem after reload, the 2 line of the column are visibles and printable. Alignement of the cells is in French: Renvoi à la ligne et coupure des mots. Actual Results: A 7.7Cm width column and text is C2, C4, C5, C6, C7, C8, C9, C11, C12, C13, C14 Save the sheet quit programm, reload the sheet, only C14 is visible and printable Expected Results: C2, C4, C5, C6, C7, C8, C9, C11, C12, C13, C14 In the same cell Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 157616 [details] See line 5 only C14 is visible, but contain others valus not printable Line 5 is KO but, the line 24 is OK.. Why ? it is the same case ?
I can't repro. Version: 6.4.0.3 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU threads: 4; OS: Windows 10.0 Build 19555; UI render: GL; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: CL
Ok, so looking at cell F5, it only displays "C14" when viewed on Linux, but on Windows it displays the actual contents "C2, C4, C5, C6, C7, C8, C9, C11, C12, C13, C14" Weird that the bug was reported against Windows, though. This is not yet seen with latest commit of Linux 50max bibisect repo. Already seen with oldest of 6.3 repo.
Created attachment 160301 [details] Bibisect log Bisected to 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. https://cgit.freedesktop.org/libreoffice/core/commit/?id=1e55a47e89a9d9d6cf9cb3993484022aaf2c097b
Adding cc to: Vasily Melenchuk
Not a regression. The issue can be reproduced if recalculation on File Load for ODF files is set to Always Recalculate in Tools/Options.../LibreOffice Calc/Formula
In this case, if the user change that setting everything would be fine. Philgood, could you try that?...See comment 6: Open Calc - Tools - Options - LibreOffice Calc - Formula - and change under Recalculation on File Load - instead of Never recalculate to Always recalculate. Please test and tell us if this worked for you.
Repro in 7.3+ Win and Lin as: Open ODS and see F5 showing just 1 line "C14" (formula bar shows the full content) Set Optimal row height on row 5, or add some space, content is OK. Save and reload, see again 1 line (just "C14"). I confirm regression, saving an reopening OK before commit from Comment 4. Note: Never recalculate should not be changed to Always recalculate for perf sake. Just in testing it can be set to Prompt. It's not about Calc/Formula/Recalculate (no formula here), it's about row height.
I don't see why this is OK only on filesave with pre-commit LO. I compared ODS and I didn't notice a difference. So not clear why pre-commit LO 6.2 has the same issue on fileopen before save.
Created attachment 178926 [details] Simple spreadsheet demonstating the issue I am trying to resolve a similar issue at my organization. I've seen lots of bugs reported on this and related topics, but none seem to provide me a solution. I can confirm that this happens under Linux and Windows and with OpenOffice and LibreOffice. So, clearly, it is not a new issue. The attached spreadsheet has two cells (C2:H2 & C3:H3) with wrapped values that always open with little red overflow triangles, no matter how many times I set their height to optimal and save them. I have experimented and found that it is, at a minimum, dependent on what the font size is, what the viewing zoom level is, and what the content length is. Changing these values does not fix the issue, but depending on their precise values it may mask the issue. As you can see from the attached spreadsheet, the cells in rows 1 and 4 seem to have an appropriate cell height, but that is most likely a quirk of the combination of factors. Changing the factors will likely result in some row heights being correct and others not.
I filed #148151 which appears to be a duplicate of this bug and #132354. I found disabling Options->Calc->Defaults->Enable very large spreadsheets resolved the problem though at the expense of not supporting very large spreadsheets, which is obviously a suboptimal workaround. If this is the same bug, I'd expect the same results. I tested with your examples and got the same problems you report and these were resolved with the VLS feature disabled on my system.
I'm not exactly sure what you are seeing, but I didn't have the "Enable very large spreadsheets" selected. For that matter, it didn't even appear in my options unless I first enabled "Experimental Features" under the "Advanced" settings. So, it does not seem to be exactly the same issue.
I took a screengrab of your demo spreadsheet when I opened it with "enable very large spreadsheets" enabled and it looked like this: https://bug-attachments.documentfoundation.org/attachment.cgi?id=179081 It returned to normal after disabling that option with row heights correct. I suppose there might be some other configuration option that triggers the bug I do not have set and you do, happy to exchange configs for a diff check to see if something pops out.
Created attachment 179169 [details] Screenshot of misbehaving spreadsheet Your screenshot when very large spreadsheets enabled looks like what I experienced when enabling that feature too. In that case, it was really messed up. However, my attached screenshot shows that even with this disabled I am getting the small red overflow triangles (even after saving the spreadsheet with optimal row heights). So, you don't see that? I'd be happy to switch config files, just let me know what you need. Thanks.
*** Bug 148151 has been marked as a duplicate of this bug. ***
attachment 178926 [details] was bug 134552, that's fixed in 7.4+. I obsolete that discussion. This bug remains.
Is there a pre-release of 7.4 that I could download and test?
(In reply to heavy from comment #17) > Is there a pre-release of 7.4 that I could download and test? https://dev-builds.libreoffice.org/daily/master/current.html On Linux, you can also roll your own appimage: https://wiki.documentfoundation.org/Installing_in_parallel/Linux#Automated_installation
Created attachment 179255 [details] Screencast demonstrating issue The attached screencast demonstrates the issue for me under Fedora 35 using the latest 7.4 alpha. I still see the same issue. I also tried it with and without enabling support for very large spreadsheets. The issue was present in either case.
*** Bug 151031 has been marked as a duplicate of this bug. ***
I can't reproduce this since 7.6 commit: https://git.libreoffice.org/core/+/b1393fd5ce847f40abab49f57c67929bb0087fae author Maxim Monastirsky <momonasmon@gmail.com> Fri Mar 17 14:54:30 2023 +0200 committer Maxim Monastirsky <momonasmon@gmail.com> Thu Mar 23 08:54:06 2023 +0000 sc drawstyles: ODF import and export