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
Created attachment 142223 [details] Draw's Table Optimize Options No "Optimal Width" or "Optimal Height" options.
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.
Hi, Legitimate. I agree.
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.
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*
(In reply to Justin L from comment #5) > code pointers: Is it an easyhack?
(In reply to Heiko Tietze from comment #6) > Is it an easyhack? I doubt it.
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
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.
Created attachment 144729 [details] Another test scenario
(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.
(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.
(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.]
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.
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.
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.
(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.
(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.
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
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.
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.
@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.
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).
(In reply to Justin L from comment #22) > @Olivier: Suggested help content for Draw. Let's keep it open for documentation then.
Thanks to everyone, especially @JustinLuth, for the work on this feature. It will be a big help in formatting Draw documents.
(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....
(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
Similar to Writer, I looked into improving minimize/optimize, but it didn't turn out so well for Draw. For the record, it is at http://gerrit.libreoffice.org/c/core/+/136518