Description: Optimal row height does not ignore hidden columns and the optimal row height counts with the height of the invisible (not shown) cells. Steps to Reproduce: 1. Enter some (random) text into a couple of cells (e.g. A1, A2, A3). 2. Set "wrap text" to all of the cells (cell height shall be adjusted automatically). 3. Hide the column with the most text in it. 4. Set optimal row height (with default paramneters). Actual Results: The row height does not change and empty space is left in other cells. Expected Results: The row height should be adjusted and ignore hidden columns. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.1.2 (x64) Build ID: 4d224e95b98b138af42a64d84056446d09082932 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: cs-CZ (cs_CZ); UI-Language: en-US Calc: threaded
Created attachment 158312 [details] testcase
Sorry but what is the bug?, or you like another option to take that in account. I don't think it will implemented.
The bug is as described above: The row height should be adjusted only by taking into account the content of the visible cells and ignore the hidden columns/cells. Why should be row height adapted to the height of the hidden (not visible) cell? It does not make sense. But it very much makes sense to save space when exporting the data to PDF or printing them. A user wishes to hide some of the columns (by accident the columns with most of the data) and he or she won't be able to reduce the blank / empty space automatically.
Not working as you like doesn't mean it's a bug, so better change to request as enhancement in the second box of importance.
(@m.a.riosv This was just a great unsubstantiated comment and a spectacular leave of the discussion. But it is better for now...) The https://wiki.documentfoundation.org/QA/BugReport says: "At a certain point what look like bugs are actually more like feature requests, where we know how the software should work in an ideal world, even though the feature we want hasn't been built yet. Fortunately, you don't have to worry that much about separating bugs from feature requests. If it's something that interferes with normal, valid use of the application, **report it as a bug**." Well, as described above, for optimal printing of the visible cells it interferes with normal use of the Calc. The help page for Optimal row height does not say anything about the hidden cells/columns. file:///C:/Program%20Files/LibreOffice/help/en-US/text/scalc/01/05030200.html?DbPAR=CALC#bm_id3148491
Then let us submit to the will of the User Experience gods
Using single numbers in A1:A5 and Hello+\n+World (line wrapping with ctrl+enter) in A3. Optimal height from context menu using 0cm makes all rows as short as possible. (Issue that hidden rows are shown when applying the optimal height function ignored here.) Please explain your workflow a bit more in detail.
Explanation of the workflow: Handling data tables, applying user friendly formatting and preparing them for printing or export. That includes removing as much empty space as possible. The issue appears when a column with large texts in cells is hidden and empty space shall be reduced. Applying 4. Set optimal row height (with default parameters). does adjust the row height to the largest element in the row even that element / cell content is hidden.
Specifically to Comment 7 https://bugs.documentfoundation.org/show_bug.cgi?id=131073#c7 Imaging you have multiple of such rows. Hide the 3rd column, apply optimal row height (nothing notable happens), and show it to my boss *exaggeration*. He requests: Reduce the empty space in the cells so we cut the number of print pages to half. So, I do it by pulling up the row divider up one by one. Or setting the row height fixed (e.g. 4,52 mm as it is default). It is more handwork, when the data table is filled with text of different lengths/line break/rows. Another workaround: deleting the columns instead of hiding. Applying optimal row height, exporting or printing and undoing the edits or closing without Save-confirm.
True, hidden cols/rows become expanded with optimal width/height. Expected behavior: the size is adjusted to the optimum but the row/cell remains hidden. Easy hack, Eike?
I confirm the issue with Version: 7.1.0.0.alpha0+ (x64) Build ID: 7dc3a20cab712ee987ea25a8f5728529521485b7 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: en-US Calc: CL
Dear thatho, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9caf9f8fde68f075a9ae1377bcc0cf6127c1737f tdf#131073 - Don't show hidden rows/cols after setting optimal row/col height 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.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/38034728339c358286aa4fb97d372210712a9ad9 tdf#131073 - Don't show hidden rows/cols after setting optimal row/col height It will be available in 7.4.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 don't see this fixed as requested, please explain.
Could you please provide a test case or detailed steps in order to check the problem again?
(In reply to Timur from comment #15) > I don't see this fixed as requested, please explain. Hi Timur, Could you please also share the info from Help - About LibreOffice ?
I followed Description. Open attachment 158312 [details] and see that B column is hidden. Mark row 1 and do Optimal height. Actual Results: The row 1 height does not change. Expected Results: The row 1 height should be adjusted to C, not B. Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: a0bc0cc81b597aa81189355a8125753d6b873cce CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Apparently the request is to ignore hidden columns when calculating the optimal row height. I'm not convinced this even is a good idea. Hiding columns is hiding them from the current *view*, not from calculations or other processing. If the request was implemented then we'd end up with different then fixed row heights depending on which column was hidden at the moment of calculation. IMHO not a good state.
From the user perspective, I would expect it to change using also the hidden cols/rows, otherwise, you have to change the optimal height/width again if you show some additional cols/rows.