You can adjust the column width to the content similarly to double-click between header cells in a spreadsheet. This function is applied directly so I'd say the user doesn't expect an auto-size behavior subsequently.

The selection is needed to size only a part of the table (if nothing has been selected the column with the focus is taken).

To me it's a perfect WFM.

It is a missing feature. The spec has the attribute "20.383 style:use-optimal-column-width" for to mark a column to automatically adapt width, if a content changes.

How is this function expected to work regarding constraints. I mean col A and B are defined as style:use-optimal-column-width so one of the two has to give room when both grow. What happens when I enter a lot of text, or have just one character? Without a (adjustable) minimum and maximum the feature makes not much sense.

(In reply to Heiko Tietze from comment #3)
> How is this function expected to work regarding constraints. I mean col A
> and B are defined as style:use-optimal-column-width so one of the two has to
> give room when both grow. What happens when I enter a lot of text, or have
> just one character? Without a (adjustable) minimum and maximum the feature
> makes not much sense.

I don't know. The spec has no rule for it. The text of section 20.383 is:
The style:use-optimal-column-width attribute specifies that a column width should be recalculated automatically if content in the column changes.
The defined values for the style:use-optimal-column-width attribute are:
    • false: column width should not be recalculated automatically if content in the column changes.
    • true: column width should be recalculated automatically if content in the column changes.

The current behavior in UI in LibreOffice is to adjust the total width of the table; and in case the total width would have to be enlarged but that is not possible, the command is ignored.

(In reply to Heiko Tietze from comment #1)
> You can adjust the column width to the content similarly to double-click
> between header cells in a spreadsheet. This function is applied directly so
> I'd say the user doesn't expect an auto-size behavior subsequently.
> 
> The selection is needed to size only a part of the table (if nothing has
> been selected the column with the focus is taken).
> 
> To me it's a perfect WFM.

Sorry I don't understand this. In the versions of LO Writer available to me, I cannot "adjust the column width to the content similarly to double-click
> between header cells in a spreadsheet". Instead, I have to do all the steps I enumerated in my first post.

Again, the selection is only needed if the user does actually want to optimize only a subset of the columns. In my production of hundreds of tables in the last decades, this has never happened to me. Anyway, if application of the function to the entire table is the default case, then it should not require selecting anything.

(In reply to Christian Lehmann from comment #5)
> In the versions of LO Writer available to me, I cannot "adjust the 
> column width to the content similarly to double-click...

Of course, that was the analogy from more known spreadsheet tools used to what I think users expect.

(In reply to Christian Lehmann from comment #0)

I prefer using right-click menu and hot keys, much rather than the toolbar or the upper menu. For me, it means that I use Right click -> Size -> Optimal Column Width to resize the columns. 

The other part is missing, indeed. I would like to have a Select menu item in the right click menu with the following items:
- Cell
- Row
- Column
- Table

In the LO I can access now (5.3.0.3 on a Mac) there are no hot keys but if they were then the whole operation would be just 
- Right Click -> E -> T (for selecting the table) (S is used by Select therefore E could be used)
- Right Click -> S -> O (for optimizing the column width)

Besides this, it would be even better if the multiple clicks would work more extensively, in the following manner. 

within a cell:
- click: poition the cursor (it works)
- double click: select the word (it works)
- triple clikck: select the cell (this is missing now)

on the left margin:
- click: select the row (it works)
- double click: select whole table (this is missing now)

I admit, this is not a complete solution for your problem but it seems to be much easier to implement. By contrast, your proposal requires to change the ODF format as well, I think, because you want to save the "always apply optimal column width" table setting as well.

Do you think such a semi-solution would be enough?

To Csongor:
It does not seem excluded that something like my suggestion for refurbish the entire table management will be adopted in a future version of LO. Then that would include a simple solution for selecting portions of a table and applying anything to them. And sure enough, these latter actions should be accessible by right-click menus.

As long as this presupposition is not fulfilled, any interim solution which requires less key hitting or button clicking is fine.

However, I would insist on two things:

1) If one wants optimal column width, then the default is to want it for an entire table. I cannot even imagine a sensible scenario where I would require it for only a subset. Suppose that applying optimal column width to the entire table produces a result that does not appeal to me. Then it suffices to drag the disturbing vertical borders to the side, which I would have to do, anyway. And in particular, applying optimal column width only to one cell should not even be offered, as this would imply table distortions à la MS Word.

2) Optimal column width is a permanent property of a table until the user resets it. It remains in vigor after editing the cells. Again, I cannot imagine a scenario where I would want optimal column width for the present content of my table, but not for a changed table content.

Reply(In reply to Christian Lehmann from comment #8)

> 2) Optimal column width is a permanent property of a table until the user
> resets it. It remains in vigor after editing the cells. Again, I cannot
> imagine a scenario where I would want optimal column width for the present
> content of my table, but not for a changed table content.

I can. :) 

Example: the user fills the cells with some content and then changes the column widths to be optimal (whatever it means). Later on, they may change the content slightly, like fixing some typos or making some other minor changes. It can happen that the user still wants to keep the existing postion of each column, for example, because they placed some wrap-through images or frames here and there. 

I admit, in many cases applying such images and frames is not necessary or can be avoided but there are some other cases when they provide the quickest/simplest solution. In those cases the user may want to preserve the overall layout of the page, including the table cell positions.

Created attachment 137932 [details]
use case showing when automatic readjustment of column withs would destroy the precisely adjusted layout

I add an attachment now to illustrate what kind of use case I was referring to. 

Let's say a teacher, who creates work sheets for their student and uses many images for illustrations, they can adjust the images manually, like the attachment shows. They create the document at 11pm in the evening, print them for the next morning and probably never use the same document again. 

For them, this manual positioning is the most straightforward way (please correct me if there is a better one). If a small change like "R" => "r" in this example, would adjust the columns slightly and would destroy the precise alignment between the umbrealla and the letter J then quite likely they would realise it only after printing or maybe the next day. This would cause frustration for them.

As there is no better way to define relative positions in a nicer way, they don't have other choice than reviewing the whole document continuously.


I'm not saying LO should never reposition anything. I just showed an example where this can be different what the user wants.

Cut a long story short, I think the user may need two things:
- adjust the column width to be optimal according to their current content
- permanently keep the column withs optimal

Now LO has the first functionality and doesn't have the second one. I think we should keep the existing menu item and we should introduce a new checkbox in the table propertise called "Keep column widths optimal".

(In reply to csongor from comment #10)
> Cut a long story short, I think the user may need two things:
> - adjust the column width to be optimal according to their current content
> - permanently keep the column withs optimal
> 
> Now LO has the first functionality and doesn't have the second one. I think
> we should keep the existing menu item and we should introduce a new checkbox
> in the table propertise called "Keep column widths optimal".
Is this the essence of this bug? I would support this as I never understood why the now available checkbox isn't permanent. That is different to the behavior of all other checkboxes.

Heiko's suggestion or demand in comment 3 for a min. and max. width would be a nice enhancement but I don't know if this is possible without cluttering the UI.

In view of csongor's scenarios, the demand may now be specified:
1) Setting optimal column width for the entire table should be more directly accessible.
2) Once checked (maybe in a new checkbox "Keep column width optimal"), optimal column width should be conserved across future editing of the table content unless the user manually resizes the table or any column. This latter operation automatically unchecks the box.

Much of the request for 'optimize' widget controls in the UI is available now with rework for bug 64242. A selection is still required, and we still don't implement the ODF 'style:use-optimal-column-width'-- and that would require new dev implementation to make that automatic for the listed see alsos.

Otherwise, all six row/column/table controls are available as UNO actions and can be added to Toolbar, Menu, Context-menu, and Keyboard shortcuts.

This is not completely resolved, but any question of the UI customization to manipulate table layout is pretty well available from 6.2 onward.

(In reply to V Stuart Foote from comment #13)
> Much of the request for 'optimize' widget controls in the UI is available
> now with rework for bug 64242. A selection is still required, and we still
> don't implement the ODF 'style:use-optimal-column-width'-- and that would
> require new dev implementation to make that automatic for the listed see
> alsos.
> 
> Otherwise, all six row/column/table controls are available as UNO actions
> and can be added to Toolbar, Menu, Context-menu, and Keyboard shortcuts.
> 
> This is not completely resolved, but any question of the UI customization to
> manipulate table layout is pretty well available from 6.2 onward.

I generate documents programmatically, and use LibreOffice (headless) to turn them into PDFs. Is there a way to optimize column widths programmatically/headless too? The `use-optimal-column-width` property would be awesome but I understand it is not supported yet. I tried writing a macro but could only get it to work while selecting something (i.e. impossible to use headless).

(In reply to Evert Heylen from comment #14)
> Is there a way to optimize column widths programmatically/headless too?
I imagine so, but you will still need to figure out how to programmatically select as well as figure out how to make a UNO call to these functions:
.uno:SetMinimalRowHeight
.uno:SetOptimalRowHeight
.uno:DistributeRows

.uno:SetMinimalColumnWidth
.uno:SetOptimalColumnWidth
.uno:DistributeColumns

Mockup for a solution in bug 145739 with discussion at https://design.blog.documentfoundation.org/2022/04/11/improve-the-table-configuration-in-libreoffice-writer/

Heiko's mockup solves a number of problems. However, it does not contribute much to the problem of optimal column width. We require a definition of this concept to begin with. The idea behind it appears to be this: The columns of a table have optimal width if, for a given table width, the table height is the smallest possible and no column is wider than necessary.

The table width may be "given" because the user defined it or set it to the page width. It is, however, also possible that the user had produced an interim width just for the while that he fills the cells and afterwards wants it to be set automatically to the minimum necessary width.

There are, then, at the moment that the user triggers 'optimal column width', two possible start situations depending on whether or not the user has set and locked the table width. In the former case, the procedure producing optimal column width does have to get by on the given table width. In the latter case, the procedure first determines the minimum height for the maximal table width and then shrinks the table and column width down to the point where it leads to a heightened table height.

This presupposes that there be, on the table configuration mockup and under 'Position/Size', an additional line for the table width (which in the mockup misleadingly is under 'Columns') and which the user may or may not 'lock'. If he does, he limits his freedom to set the column widths. If he does not, triggering 'optimal column width' will set it to the possible minimum.

I attach an example file which illustrates what is meant and also a bug.

Moreover, all of this does not yet solve the problem of making 'optimal column width' persistent. This could be an option in the box presented for 'Insert table', side by side, and of equal status, with 'Don't split table over pages.'

Created attachment 179586 [details]
Demonstration of the effect of 'optimal column width' for different tables

Please try 'optimal column width' on the example tables and assess the acceptability of the result.

According the help, optimal column width is defined by the longest entry likely with some restrictions such as number of columns. Do we really need this? Or let's use it as default unless the user makes adjustments.

The Help defines optimal column width only for a single column. I meant to define it for an entire table.