Created attachment 183344 [details] ODT file containing tables to optimize Make a table narrower than the page width, fill its cells with text and make some columns too narrow for their content, but others too wide for their content. Then select the entire table and click 'Optimal column width'. Result: Those columns which were too narrow are widened adequately. Those columns which were too wide are not touched. Expected: The width of those columns that were too wide should be shrunk, so the internal border of the cells should be equal throughout the table. This bug has been with us since the beginning of LO.
I think main problem is, that it is not clear, how this feature works or should work (see also bug 113604). If you see third table in attachment 183344 [details], feature works, if you select second and third row. So it seems, that feature doesn't work, if you select columns with different numbers of cells in a row. But the menu structure (Table -> Size -> Optimal Column Width) lets you think, that it affects the width of all columns in the table. So I think some input from Design-Team is needed here.
(In reply to Dieter from comment #1) > I think main problem is, that it is not clear, how this feature works or > should work (see also bug 113604). > Help page: https://help.libreoffice.org/7.4/en-GB/text/swriter/01/05120200.html?&DbPAR=WRITER&System=WIN Perhaps informations here are not sufficient and "Choose Table - Autofit - Optimal Column Width" is a wrong information. Correct would be "Choose Table - Size - Optimal Column Width."
Created attachment 183579 [details] Screencast Looks good to me. What exactly is not working as expected - or how is your workflow different to mine? Version: 7.4.2.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 8; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.4.2-2 Calc: threaded
Heiko, what do you mean by 'looks good'? The example file that I submitted shows clearly that columns that are too wide for their content are not shrunk. The help function quoted in comment 2 says: "Automatically adjusts column widths to match the contents of the cells." In order to render a rational discussion possible, I offer a definition of 'optimal column width': The column width of a table is optimal iff each column is adjusted to the width of its content in such a way that the height of the table is minimal while the width of the table is no wider than required by the content of the cells. (Needless to say, page width is to be respected.) If you go by this definition, the function currently does not provide optimal column width. Or else you have a different definition in mind.
(In reply to Christian Lehmann from comment #4) > Heiko, what do you mean by 'looks good'? Tried to show this with the screencast in attachment 183579 [details].
Heiko, please look again at the table. After your actions, the first column of Table 3 keeps its original width, which is too wide. Possibly Dieter is right in his comment 1: The feature does not work if cells have been merged. (There are more things that don't work if cells have been merged; but that is a different story.)
(In reply to Christian Lehmann from comment #6) > Heiko, please look again at the table. After your actions, the first column > of Table 3 keeps its original width, which is too wide. > > Possibly Dieter is right in his comment 1: The feature does not work if > cells have been merged. (There are more things that don't work if cells have > been merged; but that is a different story.) The optimization works nicely and adjusts the total size to the width of the last row. The drawback is that you either put space into one of the split cells or distribute those. I think the first approach is more safe having in mind that split cells could have different width too.
I have no doubt that the mistake can be corrected manually. It still would seem better if the optimization could distribute white space equally in the columns.- In my example Table 3, delete the last three words, select the entire table and apply 'Optimal Column Width'. You will see that the width of the entire table and the excess space in some of the cells are still conserved. It still seems that Dieter is right that the routine somehow fails if the table contains merged cells.
(In reply to Christian Lehmann from comment #8) > It still seems that Dieter is right that the routine somehow fails if the table > contains merged cells. Maybe, but the example is at least not sufficient to justify coding effort. Can you create something more striking?
(In reply to Christian Lehmann from comment #8) > It still seems that Dieter is right that the routine somehow fails if the table > contains merged cells. We should add at least this information to help page.
Forwarding the topic to documentation.
(In reply to Heiko Tietze from comment #11) > Forwarding the topic to documentation. So I think we can change status to NEW.