Download it now!
Bug 113604 - Optimal column width of table in Writer is cumbersome and not persistent
Summary: Optimal column width of table in Writer is cumbersome and not persistent
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.2.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Writer-Tables-Enhancements Writer-Table-Properties-Dialog
  Show dependency treegraph
 
Reported: 2017-11-02 15:53 UTC by Christian Lehmann
Modified: 2020-03-04 17:08 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
use case showing when automatic readjustment of column withs would destroy the precisely adjusted layout (88.87 KB, application/vnd.oasis.opendocument.text)
2017-11-23 00:49 UTC, csongor
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Lehmann 2017-11-02 15:53:40 UTC
Description:
1) If the user wants optimal column width for a table, he currently has to mark the entire table (after which the table menu closes), then open the table menu again and choose 'Size - Optimal column width'. The first step is superfluous and should be reserved for the (conceivable but improbable) situation that the user wants optimal width only for a subset of columns. Otherwise, it should be sufficient to choose optimal column width for the entire table without prior marking.

2) Currently, once the user has chosen optimal column width, but then adds content in a table cell which exceeds the "optimum width", line-break applies, and therefrom column width remains suboptimal.
If the user wants optimum column width for a table, then he wants it for any future possible content of the table (provided, of course, that the table fits in the page width). Consequently, it is necessary that LO remembers the request 'Optimal column width' for a table if it was once chosen, and reapplies it automatically whenever the table is changed (as does MS Word). This setting is undone once the user touches the width of a column.


Steps to Reproduce:
1. Make a table and fill it.
2. Put the cursor in it.
3. Choose 'Table - Size - Optimal column width

Actual Results:  
Nothing happens.

Expected Results:
If nothing is marked, optimal column width should be applied to the entire table.


Reproducible: Always


User Profile Reset: No



Additional Info:
And for the second shortcoming mentioned in the description:
1. Apply 'Optimal column width' to the entire table.
2. Expand or reduce the content of a column.
3. Leave the cell.

Nothing happens.
Expected: Optimal column width is automatically reapplied.


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Comment 1 Heiko Tietze 2017-11-14 10:45:09 UTC
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.
Comment 2 Regina Henschel 2017-11-14 10:57:37 UTC
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.
Comment 3 Heiko Tietze 2017-11-14 12:10:12 UTC
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.
Comment 4 Regina Henschel 2017-11-14 14:05:48 UTC
(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.
Comment 5 Christian Lehmann 2017-11-15 07:37:54 UTC
(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.
Comment 6 Heiko Tietze 2017-11-15 08:10:05 UTC
(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.
Comment 7 csongor 2017-11-22 00:29:48 UTC
(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?
Comment 8 Christian Lehmann 2017-11-22 08:13:13 UTC
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.
Comment 9 csongor 2017-11-23 00:08:31 UTC
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.
Comment 10 csongor 2017-11-23 00:49:21 UTC
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".
Comment 11 Thomas Lendo 2018-01-16 19:22:14 UTC
(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.
Comment 12 Christian Lehmann 2019-10-31 16:10:46 UTC
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.
Comment 13 V Stuart Foote 2020-01-13 12:46:15 UTC
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.
Comment 14 Evert Heylen 2020-03-04 11:32:34 UTC
(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).
Comment 15 Justin L 2020-03-04 17:08:55 UTC
(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