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.
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.
Created attachment 127951 [details] odt variant of test
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.
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.
> 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?
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
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.
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.
(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 )
(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.
(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.
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.
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
(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...