Bug Hunting Session
Bug 102290 - "Table → Size → Optimal Column Width" does not take the optimal width
Summary: "Table → Size → Optimal Column Width" does not take the optimal width
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.1.2 release
Hardware: All All
: medium minor
Assignee: Justin L
URL:
Whiteboard: target:6.2.0
Keywords:
Depends on:
Blocks: Writer-Tables Writer-Table-Properties-Dialog
  Show dependency treegraph
 
Reported: 2016-09-19 15:52 UTC by Konstantin Kharlamov
Modified: 2019-08-21 17:36 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
a simple table with long rows (923 bytes, text/html)
2016-09-19 15:52 UTC, Konstantin Kharlamov
Details
odt variant of test (9.92 KB, application/vnd.oasis.opendocument.text)
2016-10-11 18:21 UTC, Konstantin Kharlamov
Details
tdf102290_scenarios.odt: various optimize column test scenarios (25.25 KB, application/vnd.oasis.opendocument.text)
2018-09-05 10:58 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kharlamov 2016-09-19 15:52:33 UTC
Created attachment 127435 [details]
a simple table with long rows

Looking at the name and the documentation https://help.libreoffice.org/Writer/Optimal_Width it's hard to tell the exact meaning of the option, but either way it doesn't work right.

Both documentation and rational sense tell that upon choosing whole table, then activating the option, table columns — at the very least — should get resized to fit the content. But in reality — I attached a simple table with long rows for testing — the border of the first column jumps far beyond both the content and the page edge.

Additionally — though not mentioned in documentation — but the word "optimal" assumes that the uttermost border would lay down nearby the configured edge of the page. Instead it either jumps far beyond the edge, or stops far before the edge is approached.
Comment 1 Buovjaga 2016-10-11 17:33:36 UTC
Why not attach an ODT file instead of an HTML file? The ODT file with a table should not yet have optimal column width set anywhere.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Comment 2 Konstantin Kharlamov 2016-10-11 18:21:46 UTC
Created attachment 127951 [details]
odt variant of test
Comment 3 Konstantin Kharlamov 2016-10-11 18:22:15 UTC
Attached. I'm not sure if I understood you right, but if the thing in just providing an odt, I did it by converting from the html.

> Why not attach an ODT file instead of an HTML file?

Because of simplicity for both me and — at least I thought so — developers.

* For me it's because I can write a sample with an editor, without bailing to office tools which I hate to use, though sometimes have to. It is so uncomfortable to write much text without a vim mode. I honestly don't understand why the majority still not using Markdown for things where its formatting is enough — one can't even grep through office documents!

* For developers is because the content is immediately obvious, i.e. no need to guess about manual formatting, broken file, and other nuances.
Comment 4 Buovjaga 2016-10-11 18:45:42 UTC
Hmm, now I'm confused. Is your use case about copying a really wide table from HTML, pasting to Writer and then trying to optimize it (=shrink it to manageable size)?
When I wrote my comment 1, I had tested simply from scratch in Writer and could not understand.
Comment 5 Konstantin Kharlamov 2016-10-11 18:49:45 UTC
> Hmm, now I'm confused. Is your use case about copying a really wide table from
> HTML, pasting to Writer and then trying to optimize it (=shrink it to
> manageable size)?
> When I wrote my comment 1, I had tested simply from scratch in Writer and could
> not understand.

Ah, I see. The case is that "optimizing" a wide table does not really optimize it. It doesn't matter whether the table appeared as a result of converting, or copied from other document, or was created, does it?
Comment 6 Buovjaga 2016-10-11 18:51:43 UTC
You might well be right. I do confirm the non-optimal result with the example file.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: 65f2d6b1cc40b4b90f8987e8ea14d24b5f38f950
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on October 10th 2016
Comment 7 Justin L 2018-09-05 10:58:18 UTC
Created attachment 144693 [details]
tdf102290_scenarios.odt: various optimize column test scenarios

I was reading through the code, trying to understand it so that I could implement it in Draw. I saw a possible bug scenario, and found this bug which describes it.

proposed fix at https://gerrit.libreoffice.org/60027

One thing I don't like is that the table size can be reduced if the content is little. But since that has been the existing consequence, I don't want to cause a regression in anyone's mind or workflow by changing that.
Comment 8 Commit Notification 2018-09-06 06:49:05 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=62159ea8cc806df327461275563e95dfdff25667

tdf#102290 sw ui: give all columns a chance to grow

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 9 Cor Nouws 2018-09-06 08:31:26 UTC
(In reply to Justin L from comment #7)

> One thing I don't like is that the table size can be reduced if the content
> is little. But since that has been the existing consequence, I don't want to
> cause a regression in anyone's mind or workflow by changing that.

It is an idea that we might want to discuss with UX.

But, looking at your test scenario's, the second table already shrinks? 
( Version: 6.2.0.0.alpha0+
Build ID: 3559daee24ea1224d3d40e6a86b10cf37e18443f 
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-08-29_23:31:45
Locale: nl-NL (nl_NL.UTF-8); Calc: threaded )
Comment 10 Justin L 2018-09-06 09:26:24 UTC
(In reply to Cor Nouws from comment #9)
> But, looking at your test scenario's, the second table already shrinks? 
Yes, it already shrinks and my patch does nothing to change that.
Comment 11 Justin L 2018-09-06 12:30:24 UTC
(In reply to Cor Nouws from comment #9)
> > One thing I don't like is that the table size can be reduced if the content
> > is little.
> 
> It is an idea that we might want to discuss with UX.
For ROWS, optimize probably SHOULD resize the table.  If there isn't enough space to show the text inside, then we need to take more space, and if there is lots of empty space, we either leave it in a huge empty glob at the bottom of the last row, or else we reduce the table height.

I guess the same argument could be made for columns, but as a user enters data, a table naturally expands downward, but it doesn't expand to the right. For data entry it acts differently, so perhaps for optimization it should also act differently - namely that the width is preserve and either equally or proportionally allocate the unused space.

I'm working on adding this to Draw/Impress (bug 117721) where existing functions make it natural for the excess space to be handed out proportionally. In writer's case, the coding would probably be easier to give equal buffering.
Comment 12 Justin L 2018-09-11 12:52:12 UTC
There at least two things I still don't like about Writer's implementation.
-as mentioned earlier, the table width can shrink.
-selecting cells only calculates the entire column's width based on those cells, which easily leads to disastrous results.

If UI wants to recommend changes, then a new bug report should be created, because even though I don't like the implementation, I don't really want to be the one who makes any changes since inevitably someone will complain, and optimization is a very subjective concept. So, I'm closing this as fixed.
Comment 13 BogdanB 2018-09-16 17:12:26 UTC
Works as aspected.

Version: 6.2.0.0.alpha0+
Build ID: e005ab5d40d358adb75a64e140d46f4bf605647d
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-15_02:08:38
Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
Comment 14 Justin L 2019-08-21 17:36:31 UTC
(In reply to Justin L from comment #12)
> There at least two things I still don't like about Writer's implementation.
> -as mentioned earlier, the table width can shrink.
Fixed by adding a minimize option, and changing optimize to keep the table width with bug 64242.

> -selecting cells only calculates the entire column's width based on those
> cells, which easily leads to disastrous results.
and bug 126784 shows what disastrous results can come from my desire to use the entire column to calculate the width...