Description: Linked Calc cells are cropped to the borders of smaller cells (see screenshot 1, ODF sample document "Test 1.ods". This is the case on page breaks too (see screenshot 2, ODF sample document "Test 2.ods". It would be very heplful to have an option not to crop linked cells if possible. This could be archieved by extending the last smaller cell to the borders of the bigger linked cell for example. For page breaks keeping linked cells on the same page if possible would be enough. Steps to Reproduce: 1. Open sample documents "Test 1.ods" and "Test 2.ods" Actual Results: Linked cells are cropped and text is displayed broken within. Expected Results: Text is displayed completely. Reproducible: Always User Profile Reset: No Additional Info: As this is an enhancement request issue is independet from any releases.
Created attachment 172384 [details] Screenshot 1
Created attachment 172385 [details] ODF sample document 1
Created attachment 172386 [details] Screenshot 2
Created attachment 172387 [details] ODF sample document 2
Sorry, what are the linked cell?, I can't find any formula in spreadsheets. You have merged the cells, then they get the size of every row, no an own height. On the first sample, unmerge B2:B6, and you can see how B2 adapts the row height to their content.
(In reply to m.a.riosv from comment #5) > Sorry, what are the linked cell?, I can't find any formula in spreadsheets. > > You have merged the cells, then they get the size of every row, no an own > height. > On the first sample, unmerge B2:B6, and you can see how B2 adapts the row > height to their content. You are right, "linked" is not the correct wording, enhancement request is concerning merged cells. The cells get the size of every row even when merged cell content exceeds this size. Single cells are resized to fit their content. Having an option to resize merged cells depending on their content too would prevent cropping content and the need to insert extra rows go get the merged cell's content displayed.
But which of the rows in merged range should be resized, all, the first, the last, how to do when a row is inserted/deleted in the range. I think this is why it is not resized, a lot of options to implement for what I see like a corner case.
For sheets containing calculations it is a corner case. When working with sheets containing much text it is not. Resizing the last row of subsequent cells should be enough (from my point of view) as long as the text flow is from top to bottom. Inserting/deleting should trigger a recalculation of cell sizes (as inserting/deleting of text within a cell does too).
If the merged cell B2 needs to be 5cm tall you can a) resize row B making C2 overly large, b) select the number of rows that is covered by the height of B2 (C2:C6) and resize all rows to make the content of B2 fit, c) resize the last row that is covered by the B2 content (6 here) and resize this. Three options, kind of challenge for the UI (optimal sizing is applied to rows and columns not cells). And very hard to calculate I guess. Eike, what do you think? The same would apply to merged columns, btw.
Potential duplicate: * bug 57150: Calc FORMATTING: "Optimal column width" works incorrectly when column includes a merged cell Loosely related: * bug 103959: Merged cell contents do not overflow cell boundaries, but still affect print range calculations * bug 126208: Text not displayed, after hiding first row of merged cell
I don't see a straight forward solution for this. As the content of the merged cell has 6 lines, the only good solution would be to merge it over 6 rows instead of 5, i.e. B2:B7. Not doing so and not manually adjusting height calls for trouble. Any other would have to ask the user what they want, as Heiko lined out in comment 9. And then imagine multiple merged cells with different content height merged over different rows.. Mentioning the dirty word, what does Excel do for this? (In reply to Heiko Tietze from comment #10) > Potential duplicate: > * bug 57150: Calc FORMATTING: "Optimal column width" works incorrectly when > column includes a merged cell Not a duplicate, because that optimal column width behaviour is a result of a combination of merged cell with wrap-text cells interspersed with a not-wrapped cell, see https://bugs.documentfoundation.org/show_bug.cgi?id=57150#c6 about A20.
Created attachment 186875 [details] Screenshot Excel vs. Calc (In reply to Eike Rathke from comment #11) > what does Excel do for this? Exactly the same as we do; but with Excel the issue is shows its relevance since due to the larger spacing it looks like the cell contains only three lines. Could be resolved with a downwards pointing text overflow indicator. Excel calculates the optimal height likewise us per row. And the merged cell is a number of rows so one has to enlarge the last row of the merged cell manually.
The topic was on the agenda at the design meeting but did not receive further input. There is no good solution for the optimal height making this request a WF. I created the spin-off bug 155146 for the overflow indicator.