In the Table > Autofit drop down menu there are entries: "Distribute Columns Evenly" "Distribute Rows Evenly" The respective F1 - Help for each shows an article: "Space Columns Equally" Adjusts the width of the selected columns to match the width of the widest column in the selection. The total width of the table cannot exceed the width of the page. "Space Rows Equally" Adjusts the height of the selected rows to match the height of the tallest row in the selection. Presently: 1) No capability to distribute table rows equally in Writer Tables. Rather the existing Table > Autofit > "Distribute Rows Equally" is misleading and performs a resize of all rows simply assigning equal spacing against the tallest row. The Table expands vertically in response. 2) No capability to evenly space Columns in Writer Tables. Rather the exsiting Table > Autofit > "Distribute Columns Equally" performs a distribution resizing into the existing table width. 3) the F1 - help entries for the two existing Distribute actions are incorrect. Question for UX-Advise Proper Distribution of Columns and Rows within a Table is a very useful layout action. Likewise for actions for Equal Spacing of Columns and Rows. Should the Table > Autofit menu have entries for both "Distribute" and "Equal Spacing" of columns and rows, and consistent F1 - Help entries?
setting version back to 3.3.4 as reported in
this UX issue came over with OOo migration, have set LibreOffice version to earliest.
(In reply to comment #0) > The respective F1 - Help for each shows an article: > "Space Columns Equally" > Adjusts the width of the selected columns to match the width of the widest > column in the selection. The total width of the table cannot exceed the > width of the page. > > "Space Rows Equally" > Adjusts the height of the selected rows to match the height of the tallest > row in the selection. Both work as described for me in 4.1.1.2 For the Columns: I tried with a table that is not as wide as the text margin ..
Hey V Stuart - you mind giving exact steps on how to reproduce this? I'm not horrible familiar with tables in writer. Also verifying that the issue still exists in 4.3. Thanks! Putting this in NEEDINFO - once you retest and give us some repro steps please put it in UNCONFIRMED and we'll try again. Thanks again
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Message generated on: 2015-02-18
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker -- The LibreOffice QA Team This NEEDINFO Message was generated on: 2015-04-01 Warm Regards, QA Team
*** Bug 44871 has been marked as a duplicate of this bug. ***
Have a misleading button lable for Table -> Autofit -> "Distribute Rows Equally", the current .uno:DistributeRows action is actually to "Size rows equally" -- and adjusts the height of the selected rows to match the height of the tallest row in the selection. The height of the table increases to hold the now equally sized rows. The distribute rows entry is mislabeled in help as "Space Rows Equally" and the help describes action to size rows equally. What is missing, is a true distribution of rows. That requires for the whole table (or for a selection cells on multiple rows) the rows are equally resized and the existing vertical space is retained, i.e. the table size is fixed and the rows (whole table, or within a selection) are distributed equally into the existing height. Conversely for Columns; the Table -> Autofit -> "Distribute Columns Evenly" .uno:DistributeColumns performs a correct distribution. The selected columns are equally distributed into the existing width. But here the Help is wrong. It is labeled "Space Columns Equally" and it lists action to be "Adjusts the width of the selected columns to match the width of the widest column in the selection. The total width of the table cannot exceed the width of the page." That action would be a "Size columns equally" but it is really doing a correct distribution.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Please check again. Tried with something like |--|--|-----|-|-| and after 'distribute evenly' ending up with |---|---|---|---| Version: 5.4.2.2.0+ Build ID: 5.4.2-2 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
(In reply to Heiko Tietze from comment #10) > Please check again. > > Tried with something like > |--|--|-----|-|-| > and after 'distribute evenly' ending up with > |---|---|---|---| > > > Version: 5.4.2.2.0+ > Build ID: 5.4.2-2 > CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: gtk3; > Locale: en-US (en_US.UTF-8); Calc: group Columns are correctly distributed as noted in comment 9, rows are not. Rows continue to be be resized (as in comment 0) rather than properly distributed into the existing table size. And, the help entries still wrong name the distribution actions "Space". There needs to be four actions: 1. distribute rows - use existing table height and distribute 2. distribute columns - use existing table width and distribute 3. space rows - increase/reduce height of each row to match the tallest, table resizes 4. space columns - increase/reduce width of each row to match the widest, table resizes
(In reply to V Stuart Foote from comment #11) > Columns are correctly distributed as noted in... comment 8 not 9, sorry.
(In reply to V Stuart Foote from comment #11) > There needs to be four actions: > 1. distribute rows - use existing table height and distribute > 2. distribute columns - use existing table width and distribute > 3. space rows - increase/reduce height of each row to match the tallest, > table resizes > 4. space columns - increase/reduce width of each row to match the widest, > table resizes Nothing to add here from UX since "5. Optimal Row Height/Col Width" exists.
Olivier Hallot committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/help/commit/?id=263b467e2b2e5f1a5ccb9a76645606e739881b82 tdf#64242 Terminology: Distribute x Spacing
Olivier Hallot committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/help/commit/?id=eb0bad0276a2166577e145cab7d77466578ed697&h=libreoffice-6-0 tdf#64242 Terminology: Distribute x Spacing
A polite ping to Olivier Hallot: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks
(In reply to Xisco Faulí from comment #16) > A polite ping to Olivier Hallot: is this bug fixed? if so, could you > please close it as RESOLVED FIXED ? Thanks Ping ?
Unfortunately this remains incorrect. Documentation was changed, so now both named Distribute. Some functional descriptions: -- Distribute should hold table at its size, while its elements are resized. -- Equally Space should cause the table to resize--growing as needed for all elements to match; could be with or without influence of page margins/page size. -- Optimal size should adjust cell elements to fit (by selection: cells, rows, colummns, full table); with or without influence of page margins/page size. The margin/page boundary is a limitation now, but could be improved. So in reality, there are *six* actions needed to structure tables: to Equally space, Distribute, assign Optimal width/height. We do just four: space distribute optimal size Rows OK * missing OK Columns missing OK OK *-with current implementation, Help description for Rows is for Spacing--not--Distribution, it is mislabeled in Help. 1. current .uno:DistributeRows should be retitled maybe as SpaceRowsEqually. 2. need a new action to Distribute Rows (and hold table size) 3. need a new action to Equally Space Columns (and allow table to grow)
(In reply to V Stuart Foote from comment #18) > space distribute optimal size > Rows OK * missing OK > Columns missing OK OK I don't see much point in implementing a distributed row. Table height auto-grows with data entry, so maintaining the same height while rebalancing columns seems somewhat pointless. Equal space I can understand because it provides symmetry, and optimal size (minimize) is an obvious need. (distribute is only useful if you expand the size of an empty table and then want to rebalance the rows). Columns by definition should act differently because they don't auto-grow with data entry, so maintaining table width should be paramount. In that case equal space(size-based symmetry) and distribute space(content-based rebalance) both have value. Column Minimize only seems to make sense if rows are also minimized. So, I would propose something like this equal | minimize | optimize Rows OK (grow) | OK (shrink) | minimize+equal (no shrink) Columns OK (same width)| cols/rows(table shrink) | proportional (same width) ( * column optimize is mostly working, except that it can shrink the width. ) This gives us the symmetry options that make sense (equal, row-optimize) and content-based best-fit (minimize, column-optimize).
(In reply to Justin L from comment #19) > Minimize columns = cols/rows(table shrink) Ehh, that only makes sense if the entire table is selected, so just leave this simply as selected columns being minimized.
temped to comment here, but isn't this a follow up for bug 102290 ? https://bugs.documentfoundation.org/show_bug.cgi?id=102290#c12
Justin just did some refactoring of the Draw Tables for bug 117721, while https://gerrit.libreoffice.org/#/c/60027/ for bug 102290 will impact Writer tables here. See his attachment 144693 [details] Needs testing, but I'm OK to have things moving in this direction. Of course the documentation will again need to be tweaked. Thanks Justin!
Suggested help content (note that the proposed commit is the implementation of the description - not an edit to the help. In other words, it is an implementation of my suggestion in comment 19.) 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 column width: Adjusts the width of the selected columns to fit the selected content. The table can shrink if necessary, but will not grow. (This is how Optimize column width worked in LO <= 6.1.) https://gerrit.libreoffice.org/60902 tdf#64242 sw add minimize table col/row UI Optimize column width: Adjusts the width of the selected columns to fit the selected 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. https://gerrit.libreoffice.org/60905 tdf#64242 sw optimal column width, not minimize 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. Minimize row height: Adjusts the height of the selected rows to fit the content, causing the table to shrink. (This is how Optimize row height worked in LO <= 6.1.) (same commit as minimize column width) 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. https://gerrit.libreoffice.org/60903 tdf#64242 sw optimal row height, not minimize
(In reply to Justin L from comment #23) > Optimize column width: Adjusts the width of the selected columns to fit the > selected 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. Oops, already a documentation bug. (It is correct in the commit message). I figured out how to test the entire column, so this is changed to: Optimize column width: Adjusts the width of the selected columns to fit the entire column's content...
Forwarded from Writer to documentation.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=59ed21b1720db5fd0326e1b723483b288725e662 tdf#64242 sw add minimize table col/row UI 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=0f26c6ddda31221364b011a0b89286ecea303d89 tdf#64242 sw optimal row height, not minimize 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=ab18c17d70e1dcf5cf9db38256d35e6af479373e tdf#64242 sw optimal column width, not minimize 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.
Coding changes are finished and in master, ready for testing. Minimize icons have been requested in bug 120300. I'll watch this to make sure that they get included before 6.2 or else I will remove minimize from icon-only menu locations. (Note, menu ordering was also changed, so column options consistently follow row options.) @Olivier - you can mark this bug as fixed after you update the help for sw. Suggested wording is in comments 23 and 24, including the two *new* minimize functions. (In reply to V Stuart Foote from comment #8) > What is missing, is a true distribution of rows. That requires for the whole > table (or for a selection cells on multiple rows) the rows are equally > resized and the existing vertical space is retained, i.e. the table size is > fixed and the rows (whole table, or within a selection) are distributed > equally into the existing height. I think that the optimize function now does what you were looking for. It will not reduce the table height, but will grow it if necessary since the highest goal is for all the rows to be equal height. The only difference from Distribute is that it bases the calculation on the smallest possible size of the row with the most content, not the row with the greatest physical height (which could be empty...). (In reply to what I wrote elsewhere and at which @Cor was snickering about) > 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. I should be safe here because Minimize Rows/Columns does what Optimize did before. Wooden shoes, wooden head, wooden listen (not even to himself).
@Justin Luth, I've created a new follow-up bug to cover the documentation of this new feature -> bug 121367. Please, close this issue as RESOLVED FIXED if it's completely fixed code-wise speaking
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/0e9d621c471bdf486fb535b068fe841b56e2e8c6%5E%21 tdf#64242 unit test added It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 130343 has been marked as a duplicate of this bug. ***
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/360e6b8453acc26880f4f45e6792c2c0e15f0896 tdf#45525 tdf#64242 sw row optimize: get correct row height It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://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 "libreoffice-7-2": https://git.libreoffice.org/core/commit/209c037872ea8adc964c94ef47c0cb010b9e0db7 tdf#45525 tdf#64242 sw row optimize: get correct row height It will be available in 7.2.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
More documentation errors (talking specifically about Writer's implementation) (In reply to Justin L from comment #23) > Minimize column width: Adjusts the width of the selected columns to fit the > selected content. The table can shrink if necessary, but will not grow. No - it will grow wider up to 100%. Any why not? That helps minimize table height. > Optimize column width: Adjusts the width of the selected columns to fit the > selected content, without changing the width of the table. Without shrinking the table width. Just like minimize, it will widen if desirable.
Created attachment 180986 [details] Optimizing principles.odt: test examples where "first come first served" looked bad Proposed tweak to make minimize/optimize a bit smarter about "too much content to fit" tables. Instead of first-come-first-served, attempt to handle proportionately. http://gerrit.libreoffice.org/c/core/+/136517
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/97f6fc9f752bc8bb34f2793442922ead59008757 tdf#64242 sw table: improve Optimal Column Width function logic It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Justin L from comment #36) > Instead of first-come-first-served, attempt to handle proportionately. > http://gerrit.libreoffice.org/c/core/+/136517 I abandoned this patch because I wasn't convinced it was enough of a guaranteed improvement, and it became harder to describe in documentation. Part of it lives in comment 37's commit - which demonstrably improves symmetry (one of the two major goals in optimization).