Description: Allow row to break across pages and columns doesn't appear to work in LibO 7.0 Steps to Reproduce: 1. Open the attached file 2. Table -> Table properties -> Text Flow 3. Toggle Allow row to break across pages and columns on -> Do difference 4. Save & file reload -> to be sure 4. Compare with LibreOffice 6.4.3 Actual Results: No difference in layout Expected Results: Some change or the fix for 7 to be backported to 6.4? Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: b8fb7ecd9cdbe1898c41eaecd9894df8e8f01e25 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc:
Created attachment 160277 [details] Example file
Created attachment 164555 [details] Example, adjusted and saved in 7.0.0 This is what the changed and saved document is like for me, I see no problems with it, please clarify the issue. I only adjusted the "Allow row to break across pages and columns" setting for the one big row, it's a per row setting, alternatively I could've done it for the whole table after selecing it.
(In reply to Aron Budea from comment #2) > Created attachment 164555 [details] > Example, adjusted and saved in 7.0.0 > > This is what the changed and saved document is like for me, I see no > problems with it, please clarify the issue. > I only adjusted the "Allow row to break across pages and columns" setting > for the one big row, it's a per row setting, alternatively I could've done > it for the whole table after selecing it. I was confused myself.. I do notice the file opens differently in 4.4.7.2 and 6.4 compared to 7.1 4 empty table cells on first page; and paragraph starting on the second. So or 7.0/7.1 is proper and it was broken before or 7.0/7.1 is broken..
Lets add a bibisect request.. to see which commit changed the layout.. and if this intended change or some side-effect
Probably bug 123116's fix, and it's not going to be backported to 6.4.
@Justin Assuming this is true (didn't bibisect): probably bug 123116's fix The difference between 6.4 and 7.0 for the example file here is on purpose? The file is lacking a (real life) context to make assessment if this is problematic or not. I assume this to be a WFM; but to be sure...
I didn't notice what you were referring to at first, when I checked it for comment 2, but your sample has the exact same kind of row as the sample in bug 123116, A5 in itself is longer than a page, so b271cc46851c61ddef20dc869bf339c857f76b18 (plus 60a1b40cf363a54b64b84afcfad7fd08bc6ce770) must be in effect. Not sure if this requires more explanation.
(In reply to Aron Budea from comment #7) > I didn't notice what you were referring to at first, when I checked it for > comment 2, but your sample has the exact same kind of row as the sample in > bug 123116, A5 in itself is longer than a page, so > b271cc46851c61ddef20dc869bf339c857f76b18 (plus > 60a1b40cf363a54b64b84afcfad7fd08bc6ce770) must be in effect. Not sure if > this requires more explanation. It's more a yes/no question; no need for a explanation; not a big fan of sudden behavioral /layout changes. But really my 2 cents; especially for my sample file
(In reply to Telesto from comment #8) > It's more a yes/no question; no need for a explanation; not a big fan of > sudden behavioral /layout changes. But really my 2 cents; especially for my > sample file I'd agree with a normal use case involved. However, if the result is that part of the cell content get hidden with the user not noticing, as it happened before the fix, that isn't something I'd call normal use case, but dangerous instead. If you can show a sample where that isn't the case, yet the fix causes a sudden layout change, I'd be interested.
Yes, this change is intentional, for the reasons Aron mentioned. From a user perspective, this would have to be seen as the correct behaviour wouldn't it? You wouldn't want your data hidden off-screen (unless you are trying to send secret messages using a word processor). And if it is going to row-break and flow over to the next page anyway, then no purpose in having a gap in between the prior rows either. Some layout change was necessary for interoperability, and the gap-removal portion was just a sane-response-to-the-situation which makes LO better than MSO.