Description: After I re-open a Calc document, old, blank entries with the "Wrap Text Automatically" checkbox selected stay wrapped, but new entries do not wrap. This only occurs when I apply the property after I click the column header and right-click to apply the property to the entire column, then save and re-open. When I select a subset of the column (like F0 to F200) that includes blank entries, the "Wrap Text Automatically" will stay applied down to that row even after multiple saves and reopens. Steps to Reproduce: 1. Select column header. 2. Right-click, go to properties, and check "Wrap Text Automatically" 3. Save and re-open. Actual Results: The blank cells in the column revert to not wrapping text automatically. Expected Results: The blank cells in the column should retain the "Wrap Text Automatically" setting. Reproducible: Always User Profile Reset: Yes Additional Info: Using a portable installation. Saving/editing XLXS
Known issue. There are so many reports (both old and recent, regressions and inherited) about Wrap Text (with ODS, XLSX, and/or XLS) that I don't even know which of those should be pointed to as original of this dupe.
Thanks, ady. *** This bug has been marked as a duplicate of bug 97106 ***
Bug 97106 (inherited) is not the same as this bug 162668, although both are related to Wrap Text. Following the STR from comment 0, this is a regression introduced in LO 24.2. In LO 7.6 the Wrap Text property is saved to XLSX and read correctly when re-opened. As mentioned, there are several possible original reports that could be pointed-to from this dupe, but bug 97106 is not one of those.
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks d4aef228e1d95b02f52b95c8ada1c28c86aa3462 is the first bad commit commit d4aef228e1d95b02f52b95c8ada1c28c86aa3462 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Aug 28 17:19:42 2023 +0200 source b7d5b8cee77e4cfd931cdbd6f4ba8673c6bbe490 156186: Related: tdf#156611 move long explanation string into tooltip | https://gerrit.libreoffice.org/c/core/+/156186
seems an odd bisect result because that commit should only change the label of the checkbutton (and move the excess text into a label)
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Paris Oplopoios ; Could you possibly take a look at this one? Thanks 0fd3d8fa5041781bea37aeda264bda71a66c6152 is the first bad commit commit 0fd3d8fa5041781bea37aeda264bda71a66c6152 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Aug 28 10:38:53 2023 +0200 source 1760ee4d328cfb6ba22a5b3c84016625b12adb25 155970: sc: Fix wrapText not being applied correctly on export | https://gerrit.libreoffice.org/c/core/+/155970
Please allow me to point out, once again – I'm not counting them anymore – that Paris is not likely to reply to any of the several regressions in a timely manner. Someone else (perhaps also from collabora) should rather take a look at these regressions. Part of the regressions were already patched in some way or another in some of the other regression-reports, but clearly not all the regressions are corrected ATM – searching according to "Regression By" limited to Calc module might help. Some of the original causes (but reverting them might no longer be possible, giving the additional commits to patch these): <https://gerrit.libreoffice.org/c/core/+/155970> <https://gerrit.libreoffice.org/c/core/+/158702> <https://gerrit.libreoffice.org/c/core/+/159758>
Some regression reports were already fixed. ATM, we still have (at least) bugs 160900, 161453, bug 159690 comment 17, and this tdf#162668 (plus respective dupes).