Created attachment 56500 [details] Illustration of what I meani Problem on adjust selected Row or Column to equal space: On previous version (3.4 & 3.3) I can adjust selected row or column to equal space without a problem, but on version 3.5 ( I use 3.5 RC.2 ) I have found problems as follow : On ROW : when I choose row, space equally on selected rows, rows turns into the same height, with a height corresponding to the height of the highest rows in the selected row ie selected rows with a height of 1 cm, 1.3 cm and 1.5 cm, the end result is a rows with a height of 1.5 cm, height is supposed to be 1.27 cm On COLUMN : When I choose column, space equally on selected columns, the entire column in the table turns into the same width, should only the selected columns changed into the same width
I can confirm this bug. Select two of three columns and click "Space Equally" change also the unselected columns! Work fine in LibreOffice 3.4.5 (amd64 Ubuntu 10.04).
I can confirm this bug, too. LibreOffice 3.5.0 Build-ID: 350m1(Build:13) on Ubuntu 10.04 64bit, installed over ppa. I want the "Space Equally"-function to be affected only on the selected columns of a table, but all colums of the table are affected. Thats definitively not what I want. In earlier versions of LO this function worked fine.
(In reply to comment #2) > I can confirm this bug, too. > > LibreOffice 3.5.0 Build-ID: 350m1(Build:13) on Ubuntu 10.04 64bit, installed > over ppa. > > I want the "Space Equally"-function to be affected only on the selected columns > of a table, but all colums of the table are affected. Thats definitively not > what I want. > > In earlier versions of LO this function worked fine. After updating today to LibreOffice 3.5.1 via ppa this problem seems to be solved.
I can confirm this bug too. Running LibreOffice version 4.0.0.3, running on Windows 7 x64. Very very annoying.
For me not reproducible with LO 4.4.0.3, Win 8.1. Can anybody confirm that this bug still persists with the latest release of LO?
Created attachment 113351 [details] Writer document containing table with differently-sized rows and columns. (In reply to A (Andy) from comment #5) > Can anybody confirm that this bug still persists with the latest release of > LO? I tested with LO 4.4.0.3 on Win 8.1, and yes, the bug persists, but only with respect to rows. Columns are adjusted properly. Attaching a sample document containing a table with differently-sized rows and columns. Try to select some rows, right-click on it and click Row -> Space equally.
(In reply to josiasmat from comment #6) > Created attachment 113351 [details] > Writer document containing table with differently-sized rows and columns. > > (In reply to A (Andy) from comment #5) > > Can anybody confirm that this bug still persists with the latest release of > > LO? > > I tested with LO 4.4.0.3 on Win 8.1, and yes, the bug persists, but only > with respect to rows. Columns are adjusted properly. Attaching a sample > document containing a table with differently-sized rows and columns. Try to > select some rows, right-click on it and click Row -> Space equally. Thank you very much for your very fast reply. I tested it with the by you attached file and the columns are now with LO 4.4 spaced equally without interfering the not selected columns. If I select some cells (e.g. first three rows) and I select to space the rows equally, then all are spaced equally. All have the same height of the largest row before (e.g. of 1.72 cm). Is my understanding correct that you think that it should not be adjusted to the largest row but to the average of the selected rows and that this is from your point of view the still persisting part of the bug?
(In reply to A (Andy) from comment #7) > Is my understanding correct that you think that it should not be adjusted to > the largest row but to the average of the selected rows and that this is > from your point of view the still persisting part of the bug? Exactly!
Created attachment 114498 [details] Sample document showing tables adjusted, with current and expected behavior
Reproducible with LO 4.4.1.2, Win 8.1
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Tested on LibreOffice 5.1.2 Win64. The bug persists.
Repro with: Version: 5.4.0.0.alpha1+ Build ID: 274ecb49b70b3f01d47546e3b44317946c106042 CPU threads: 4; OS: Windows 6.2; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-05_22:45:07 Locale: nl-BE (nl_NL); Calc: single
Bug still reproducible in 6.0.0.3 on Windows 10. Columns are adjusted properly. Rows are adjusted to the height of the largest row, but not to the average height of all selected rows.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Djoko Masdjo, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
For me everything seems ok. Please retest. Tested with Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 5b025285b3528910a4360899abb2bbbaadc72c97 CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Also tested in 7.2 and seems ok. Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded
I tested only the COLUMN problem which seems ok. The table width is staying the same. Only selected columns change. The ROW problem is still there. The columns take the maximum height of the cells selected. The total height of table is increasing.
Well, LibreOffice is not a mind-reader, so it cannot know what size you want the row to be. There are now three sizing options. "Distribute Rows Evenly" is what you know - using the largest size row and making all the selected rows the same. "Minimize Row height" does exactly that. "Optimize row height" was introduced in 6.3 (bug 64242). 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. Now I have to admit does optimize doesn't seem to be doing exactly what is described (at least not on the data I was now testing), but I see why. Proposed fix at http://gerrit.libreoffice.org/c/core/+/122572
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.
Created attachment 175250 [details] optimizeRowHeight.odt: should still fit one page when optimized. (In reply to josiasmat from comment #9) > Created attachment 114498 [details] > Sample document showing tables adjusted, with current and expected behaviour Yes, this expected resizing behaviour (of content-less) rows is appropriate, logical, and was supposed to be handled by "optimal height". I attached an example that emphasizes the bug in the calculation of the row height, which has now been fixed. Backport requested for 7.2.
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.
I think this bug is resolved. The columns were acknowledged to be fixed earlier (already in 6.0, but should be improved in 6.3 with the additional optimize). The rows (via optimize) should resize nicely based on content / existing size in starting in 7.2.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/263d2f0b3d1143d6caa467204f187648c43b0e89 tdf#45525: sw_uiwriter2: Add unittest 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.