Created attachment 94484 [details] Sample document .xls Spreadsheet that fails to expand row height Don't always, but happen, rows in files .xls don't expand automatically with the content. The file attached have a row visualized correctly in Excel but not in LibO LibO: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
I confirm a difference between Excel 97 and LibO 4.2.1.1 on Win7 on the attached .xls file. They should be identical so there is a bug. I have no way to say if the bug is in Excel 97 or LibO for this file (status kept to UNCONFIRMED). If I modify the height of the filled row whichever in Excel 97 or LibO, the other application then opens correctly.
Confirmed:4.3.0.0a0+:OSX Version: 4.3.0.0.alpha0+ Build ID: 2e40ddbd325fb5dc963e2017245e3df2f4f809c8 TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2014-02-27_02:42:27 NEW
Created attachment 94813 [details] confirmed
reproducible under Win7x64 using LibO 3.3.3, 4.2.4 and 4.4.0.0.alpha0+ Build ID: 95272e7e5b7e38753ab07dbd6503b7cfa2974842 TinderBox: Win-x86@42, Branch:master, Time: 2014-06-26_23:01:43 same issue with OOo 3.3.0 and AOO 4.1 so bug is "inherited from OOo"
** 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 (4.4.1 or later): 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: 2015-07-18
still reproducible with LibO 4.4.5.1 and 5.1.0.0.alpha1+ (x64) Build ID: 449d272daf5e99f039cdfdd25f020bd798fb9e1d TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-08_08:13:06 Locale: it-IT (it_IT)
** 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.1.5 or 5.2.1 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 helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
still repro in Version: 6.3.0.0.alpha0+ (x64) Build ID: de024e572dd7a588f82b84c68daa2051ec6b20e9 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-18_01:13:57 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
Dear Marco A., 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
repro 7.5+ In Excel 2003 the row is small - shrunk to fit. In LO, the row is tall - lots of extra space shown. [My complaint tends to be the opposite. I have the row set to automatic height, but on reload the row will not auto-grow when content is added.]
In XLSX, we can see row formatting like ht="12.75" customHeight="false" where customHeight being false should mean "automatic height" in which case ht should just be ignored. But we aren't doing that apparently. It works if ht is not specified at all (but we ALWAYS round-trip an ht value.) For Sample.xls, I see that row 2 is not custom height, but it seems like row3 is: sc/source/filter/excel/colrowst.cxx:226: --- row[3] nPrevFlags[9] (Used & Man) However, I do confirm that Excel 2003 opens Sample.xls with row 3 minimized to fit the contents, so I'm not sure what is going on there. But at least I can fix my own problem with http://gerrit.libreoffice.org/c/core/+/139822
Created attachment 182426 [details] Sample.pdf: Page 1 is from LO 3.6 (same as today's 7.5) and Page 2 is from Excel 2003 It is hard to understand what the real concern is here. The description talks about expanding automatically with content, but in the comparison it looks like MS Office is SHRINKING to set optimal row height (and yet if I add content, then Excel is not expanding anything). I wonder if there is a problem with this document. If I round-trip it with Excel 2003, then LO opens it up just fine. If I round-trip it with LO, then Excel opens it up the same way as LO. LibreOffice reports that a manual height has been set on row 3. In that case it ought to honor the specified height. So unless there is some over-riding setting that we don't know about, it seems to me that LO handles it properly. The only problem I see is that LO to easily saves "manual height" and thus on a round-trip things are no longer dynamic. (It seems that if the height changes due to content addition that export is marking as custom height. If the file is simply round-tripped, then it is fine.)
Created attachment 182447 [details] i93609_auto_row_height.xlsb: from OpenOffice.org bug 93609 (In reply to Justin L from comment #12) > LibreOffice reports that a manual height has been set on row 3. Wrong. LO is reading in non-manual height, but it specifically calls SetManualHeight for merged horizontal cells because of https://bz.apache.org/ooo/show_bug.cgi?id=93609 if( bTextWrap ) GetOldRoot().pColRowBuff->SetManualRowHeight( rStart.Row() ); Bottom line: There is so much monkey business going on here, it isn't worth fixing this particular bug report.