Bug 117721 - Draw: Tables have no "Optimal Width" Feature
Summary: Draw: Tables have no "Optimal Width" Feature
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium enhancement
Assignee: Justin L
URL:
Whiteboard: target:6.2.0
Keywords:
Depends on:
Blocks: ImpressDraw-Tables
  Show dependency treegraph
 
Reported: 2018-05-21 09:16 UTC by Rik Shaw
Modified: 2018-10-12 15:16 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Draw's Table Optimize Options (244.20 KB, image/png)
2018-05-21 09:18 UTC, Rik Shaw
Details
Writer's Table Optimize Options (209.41 KB, image/png)
2018-05-21 09:19 UTC, Rik Shaw
Details
tdf117721_scenarios.odg: various optimize candidates to test the patch on. More ideas are welcome!!! (25.00 KB, application/vnd.oasis.opendocument.graphics)
2018-09-06 10:07 UTC, Justin L
Details
Screenshot with current patch and another test scenario (21.59 KB, image/png)
2018-09-07 07:01 UTC, Heiko Tietze
Details
Another test scenario (16.91 KB, application/vnd.oasis.opendocument.graphics)
2018-09-07 07:02 UTC, Heiko Tietze
Details
tdf117721_scenarios.odg: updated scenarios exploring blank/narrow columns (37.91 KB, application/vnd.oasis.opendocument.graphics)
2018-09-11 09:40 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rik Shaw 2018-05-21 09:16:22 UTC
Description:
Draw Tables have no ability to "Optimal Width" or "Optimal Height" under the Optimize section.

Steps to Reproduce:
1. Create a new table in LibreOffice Draw.
2. Hilight a column in the table.
2. Click "Table Optimize" button, no options like Writer has for "Optimal Width" or "Optimal Height"

Actual Results:  
These features are not available in Draw.

Expected Results:
Hoping that these features can be applied from Writer to Draw.


Reproducible: Always


User Profile Reset: No



Additional Info:
When using tables in Draw, under the "Optimize" section there is no "Optimal Width" or "Optimal Height" options.  Writer has these options and they are very valuable for literacy workers using tables with Draw.

If there is any ability to add this feature it will aid many moving away from MS Publisher.

See attachments comparing Writer and Draw using this Table Optimize button.


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Comment 1 Rik Shaw 2018-05-21 09:18:16 UTC
Created attachment 142223 [details]
Draw's Table Optimize Options

No "Optimal Width" or "Optimal Height" options.
Comment 2 Rik Shaw 2018-05-21 09:19:29 UTC
Created attachment 142224 [details]
Writer's Table Optimize Options

Writer has the options to apply "Optimal Width" or "Optimal Height" to the selected table cells.
Comment 3 Jacques Guilleron 2018-05-21 10:31:31 UTC
Hi,
Legitimate. I agree.
Comment 4 Justin L 2018-05-21 13:09:19 UTC
Writer has had this ability since 3.3: inherited from OOo. So no ability to bibisect and easily see what was required to add this to Writer.

Confirmed still missing in LO 6.1 beta.  There doesn't seem to be any menu option to optimize the width in Draw.
Comment 5 Justin L 2018-09-04 14:04:04 UTC
code pointers: 
-sw/source/uibase/shells/tabsh.cxx::Execute FN_TABLE_ADJUST_CELLS
-sw/source/core/docnote/ndtbl.cxx::AdjustCellWidth

-svx/source/table/tablecontroller.cxx::Execute SID_TABLE_DISTRIBUTE_*
-svx/source/table/tablelayouter.cxx::distribute*
Comment 6 Heiko Tietze 2018-09-04 15:09:28 UTC Comment hidden (no-value)
Comment 7 Justin L 2018-09-04 16:44:52 UTC Comment hidden (no-value)
Comment 8 Justin L 2018-09-06 10:07:36 UTC
Created attachment 144712 [details]
tdf117721_scenarios.odg: various optimize candidates to test the patch on. More ideas are welcome!!!

proposed fix at https://gerrit.libreoffice.org/#/c/60078
Comment 9 Heiko Tietze 2018-09-07 07:01:49 UTC
Created attachment 144728 [details]
Screenshot with current patch and another test scenario

The attached test scenario works fine. But I created my own test and expected one column to resize - that doesn't work, you have always to select at least two. Basic issue with the algorithm is that shrinking the column width fails unless something else takes the space. Selected cols are highlighted, my expectation for resizing is indicated with red lines.

The resizing depends on the table content not the selection, btw. So when I select 1 and the empty col next to it I get the same result as when all cols are selected given the cells are empty. If some cell has a long text it affects the procedure independently from the selection.

I'm missing access beside the toolbar button, e.g. in the context menu. That's not a problem if optimization always and clearly works on the whole table. This solves most issues and would just need a different UI. Perhaps a button at the table properties dialog or at the table design section in the sidebar.
Comment 10 Heiko Tietze 2018-09-07 07:02:43 UTC
Created attachment 144729 [details]
Another test scenario
Comment 11 Justin L 2018-09-07 10:12:52 UTC
(In reply to Heiko Tietze from comment #9)
> I expected one column to resize - that doesn't work, you have always to
> select at least two.
The same thing is true in Writer's implementation.  With only one column, the only option would be to shrink the width of the table. Otherwise where would you put the extra space? I don't like the idea of having the table space shrink during column adjustments (even though Writer does currently do that). Allowing the table to shrink to optimize a single column probably should be a separate bug report requesting that enhancement for both Writer and Draw. (It probably won't be that hard to do and won't affect this implementation because it will be a totally unique/alternative code path.)

> Basic issue with the algorithm is that shrinking the column
> width fails unless something else takes the space.
Optimizing  columns shouldn't mean shrinking to fit the content. It should mean distributing the available space beneficially.

> my expectation for resizing is indicated with red lines.
1: so you want special consideration made for an empty column - so that it grows more than a column containing content? That could only be true for a "last column", Think about if you increase the selection to include Lorem Ipsum - then you want the empty column to minimize instead of grabbing as much as it can. So that would add complexity and inconsistency to assign special meaning to contentless columns based on context.

Hello Word: same as above. The excess space is given out proportionally, so Hello Word gets a larger chunk of free space than the empty column. That proportionality certainly makes sense in a content-situation.

ABC: same as above, but now the complexity has increased much more because now an empty column needs to be contextually aware that none of the following columns are going to want any of the free space. What if there are two empty columns - do they equally share the excess or does the first one grab it all?

Ultimately, it seems very arbitrary to assign more weight to an empty column and certainly isn't worth making the algorithm unreadable.

> The resizing depends on the table content not the selection, btw. So when I
> select 1 and the empty col next to it I get the same result as when all cols
> are selected given the cells are empty. If some cell has a long text it
> affects the procedure independently from the selection.
If you mean that resizing calculation depends on the entire COLUMN's content, not just on the selected content, then I agree, and that only makes sense. The selection is only to determine which columns to resize. There is no way that the resizing operation should only look at the content of the cells that are selected. That would generally produce disastrous results.

> I'm missing access beside the toolbar button, e.g. in the context menu.
> That's not a problem if optimization always and clearly works on the whole
> table. This solves most issues and would just need a different UI. Perhaps a
> button at the table properties dialog or at the table design section in the
> sidebar.
The function can be called from the two places that "equally distribute" can be called (namely right-click->Column, and the bottom Table toolbar's "Optimize" button). Since equally distribute also will be missing from the other suggested locations, I think that is outside the scope of this bug and would be better handled as a separate enhancement request by a real UI person - not me. But I agree that it should be available somewhere in the menu (the Shape/[previously Modify] menu?) and possibly in the sidebar.
Comment 12 Heiko Tietze 2018-09-07 12:37:38 UTC
(In reply to Justin L from comment #11)
> With only one column,
> the only option would be to shrink the width of the table. Otherwise where
> would you put the extra space?

How about equally distributed over all columns. Could be done in the same way for Writer. And actually that's the default action for double click between header cells.
Comment 13 Justin L 2018-09-10 10:56:24 UTC
(In reply to Justin L from comment #11)
> (In reply to Heiko Tietze from comment #9)
> > I expected one column to resize - that doesn't work, you have always to
> > select at least two.

> The same thing is true in Writer's implementation.
I was wrong here - just make sure that the cell has content in it, and then the option to optimize that column IS enabled (although the implementation is awful since it doesn't optimize based on column content, but only on that cell's content.).  [I've already added the ability for optimize a single column to my Draw patch - thanks for the suggestion.]
Comment 14 Justin L 2018-09-11 09:40:44 UTC
Created attachment 144782 [details]
tdf117721_scenarios.odg: updated scenarios exploring blank/narrow columns

At least for me, a common spreadsheet has numbered rows, and a section for general notes. Any blank column simply exists for visual spacing (in an otherwise populated table - the only kind of table you attempt to optimize).

When optimizing, ideally the numbered column should be able to accept one more full-width digit (going from 9 to 10 for example) and wide columns get the bulk of the unused space since they would tend to be "free-form" fields instead of fixed-content. Proportional spacing (as opposed to equally divided spacing) has the best chance of succeeding at the goal of keeping thin columns thin, while still giving them a bit of extra buffer room.

Ultimately, what optimizing means will be in the eye of the beholder, and dependent on the content. In the case where there is no free space, the choice is obvious. In the case where free space needs to be distributed, a model that is consistent, buffered, and which an observant user can figure out is best. Proportional spacing does all that.
Comment 15 Commit Notification 2018-09-21 14:48:40 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=73859a1c00d443714a1e5f2a1a8d16fe46877944

tdf#117721 draw ui: add .uno::SetOptimalColumnWidth

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Commit Notification 2018-09-22 04:28:31 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=871795ad598dfccc156e6dd47937638893b727d8

tdf#117721 draw ui: add .uno::SetOptimalRowHeight

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Luke 2018-09-22 05:13:03 UTC
(In reply to Justin L from comment #11)
> Optimizing  columns shouldn't mean shrinking to fit the content. It should
> mean distributing the available space beneficially.

Have you tried Word's Autofit? Both Word's "Autofit Content" and Writer's "Optimize Width" behave in the exact same way by shrinking to fit content. 

Are you thinking of Word does offer additional Autofit options such as "Fixed column width" and "Autofit Window"? We have other functions that map closely to these too.
Comment 18 Justin L 2018-09-22 06:46:28 UTC
(In reply to Luke from comment #17)
> Have you tried Word's Autofit? Both Word's "Autofit Content" and Writer's
> "Optimize Width" behave in the exact same way by shrinking to fit content. 
I will be proposing adding a Writer "minimal column width" to keep the shrinking option, and changing optimize to keep the table width - thus providing both options.

> Are you thinking of Word which does offer additional Autofit options such as
> "Fixed column width" and "Autofit Window"? We have other functions that map
> closely to these too.
I have no idea how Word does anything. Note that this is a Draw bug, and draw tables do not have any auto-fit functions for columns / table width.
Comment 19 BogdanB 2018-10-01 11:04:32 UTC
Confirm the bug is solved.

Version: 6.2.0.0.alpha0+
Build ID: a906b68a9fff30c2af5c03189e59c1952cd3f69f
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-30_19:07:59
Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
Comment 20 Commit Notification 2018-10-11 07:53:20 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=79bc165b6c906aa4f9efa6f4cdebb2f8a5f405b1

tdf#117721 draw ui: add .uno::SetMinimal[RowHeight|ColumnWidth]

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Commit Notification 2018-10-12 03:56:27 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3fa8f934195cabb9c6fa9cd09ee0a05c7ded46ab

tdf#117721 draw ui: modify Optimize/Distribute RowHeight

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Justin L 2018-10-12 05:58:44 UTC
@Olivier: Suggested help content for Draw.

Minimize column width: Adjusts the width of the selected columns to fit the entire column's content. The table can shrink if necessary, but will not grow. 
(Note: this is slightly different from Writer's implementation. Minimize is based on the entire column's width, not just the selected cell's width.)

Optimize column width: Adjusts the width of the selected columns to fit the entire column's content, without changing the width of the table. Any leftover space is distributed proportionately, with thin columns growing slightly, and wide columns growing much wider.

Distribute columns evenly: Adjusts the width of the selected columns so that each column has the same width, regardless of content. The table width remains unchanged.


Minimize row height: Adjusts the height of the selected rows to fit the content, causing the table to shrink.

Optimize row height: Adjust the height of the selected rows to match the height of the tallest row in the selection (fit to content), without shrinking the table. This option is the same as minimizing row height and then distributing rows evenly except that it adds the benefit of preventing the table from shrinking.

Distribute rows evenly: Adjusts the height of the selected rows to match the height of the tallest row in the selection (regardless of the content), causing the table to grow.
Comment 23 Justin L 2018-10-12 06:54:26 UTC
It is probably worth noting that the implementation of Distribute Rows Equally has changed. Previously it worked similar to optimize - based on the minimum height of the row with the most content.  Now it matches the help documentation, which says it is based on the tallest row (regardless of content).
Comment 24 Heiko Tietze 2018-10-12 07:02:33 UTC
(In reply to Justin L from comment #22)
> @Olivier: Suggested help content for Draw.

Let's keep it open for documentation then.
Comment 25 Rik Shaw 2018-10-12 10:41:36 UTC
Thanks to everyone, especially @JustinLuth, for the work on this feature.  It will be a big help in formatting Draw documents.
Comment 26 Xisco Faulí 2018-10-12 11:33:36 UTC
(In reply to Heiko Tietze from comment #24)
> (In reply to Justin L from comment #22)
> > @Olivier: Suggested help content for Draw.
> 
> Let's keep it open for documentation then.

Ideally, It would be better to have a follow-up bug for documentation....
Comment 27 Heiko Tietze 2018-10-12 12:26:16 UTC
(In reply to Xisco Faulí from comment #26)
> Ideally, It would be better to have a follow-up bug for documentation....

Right, we agreed on that. => bug 120550