Created attachment 43799 [details] Sample document Excel 97 files generated by "1C:Enterprise 8.1 platform" are opened with incorrect row height in LibO 3.3.1 (and Go-oo) on Linux, Windows. OO 3.2.1/3.3, Excel 2007 opens them correctly.
Created attachment 43800 [details] Comparison between OO and LibO
Just out of interest, what is 1C:Enterprise ?
I don't think this is a regression if OOo 3.2.1 behaved the same?
(In reply to comment #2) > Just out of interest, what is 1C:Enterprise ? http://www.1centerprise.com/ (In reply to comment #3) > I don't think this is a regression if OOo 3.2.1 behaved the same? It is a regression. All OOo versions behave correctly as stated in the original bug description.
OK, I misread the initial comment, I mized up a period and comma...
One more thing: incorrect row height is set only for rows with automatic row height. If I set fixed row heights for some rows in "1C:Enterprise 8.1", then these rows are opened correctly, and all rows with automatic height not.
(In reply to comment #2) > Just out of interest, what is 1C:Enterprise ? 1C is "de facto" (like Windows) standart in economic software in former USSR with rapacious pricing and with bad (and high cost) architecture solutions.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
The bug is still present in 3.5.0 beta1.
Still a problem in LibO 3.6.0 Same document works fine in AOO 3.4.0
[Reproducible] with "LibreOffice 3.6.1.2 German UI/Locale [Build-ID: e29a214] on German WIN7 Home Premium (64bit), already visible with 3.3.0., ok with AOOo 3.4 As in Bug 50044, every formatting in any cell of the row heals the problem for that row. Might be related to: "Bug 34552 - EDITING: Calc loses row height value when modifying a cell", the action what there destroys row hight here heals a problem" "Bug 39486 - FILEOPEN; Incorrect row height when opening some .xls files." and others "Bug 50044 - FILEOPEN partiular .xls shows too small row height"
*** Bug 34552 has been marked as a duplicate of this bug. ***
*** Bug 50044 has been marked as a duplicate of this bug. ***
*** Bug 39486 has been marked as a duplicate of this bug. ***
@Spreadsheet Team: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC).
*** Bug 63074 has been marked as a duplicate of this bug. ***
Sarò assente fino al 15/07/2013: risponderò al mio ritorno. Per urgenze contattare: sys_admin@despar.it I will be out of the office and will not return until 15/07/2013. Please contact: sys_admin@despar.it Grazie/Thanks Nicola Ruggero Sollten Sie diese E-Mail unbeabsichtigt bzw. irrtümlich erhalten haben, so weisen wir Sie darauf hin, dass gemäß § 93 Abs 4 TKG der Inhalt sowie die Tatsache des Empfangs dieser E-Mail weder aufgezeichnet noch verwertet oder Unbefugten mitgeteilt werden dürfen. Wir ersuchen Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. If you have received this email accidentally or in error, we point out that, in accordance with § 93 para. 4 TKG (Telecommunications Act), the contents of this email and the fact of its receipt must not be recorded, exploited or communicated to unauthorized persons. We ask you to delete the message from your system and to contact us.
Still a problem in LibO 4.1.4.2
4.2.0.4 - w/o changes
** 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.2 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-05-02
Still reproducible exactly as before: Versija: 4.4.2.2 Darinio identifikatorius: c4c7d32d0d49397cad38d62472b0bc8acff48dd6 Lokalė: lt_LT
Same issue also in LO: 5.0.5.2-2.fc23
** 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.2.5 or 5.3.0 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-20170306
Still reproducible exactly as before: Versija: 5.3.0.3 Darinio identifikatorius: 1:5.3.0~rc3-0ubuntu2 Procesoriaus gijos: 4; Operacinės sistemos versija: Linux 4.10; Sąsajos pateikimas: numatytasis; VCL: gtk3; Layout Engine: new; Lokalė: lt-LT (lt_LT.UTF-8); Calc: group
Im a Java developer and working with Apache POI to generate xls and xlsx documents. When the row height is set to -1, you get exactly the undefined/default row height behaviour. https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Row.html#setHeight(short) In every MS Office Version, you have the behaviour wenn row height is set to -1 to autosize the row height. The bug is currently stil in the latest libreoffice version I am running. Version: 5.3.4.2 Build-ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3 CPU-Threads: 4; BS-Version: Windows 6.2; UI-Render: Standard; Layout-Engine: neu; Gebietsschema: de-DE (de_DE); Calc: group
** 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
The bug is present in: Versija: 6.2.0.0.alpha0+ Darinio identifikatorius: 6af1637d0cf85566ca8482cc284669c4968ae977 Procesoriaus gijos: 4; OS:Linux 4.17; Sąsajos pateikimas: numatytasis; VCL: gtk3; Lokalė: lt-LT (lt_LT.UTF-8); Calc: group threaded And in: Versija: 6.0.5.2 (x64) Darinio identifikatorius: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 Procesoriaus gijos: 8; OS:Windows 10.0; Sąsajos pateikimas: numatytasis; Lokalė: lt-LT (lt_LT); Calc:
To workaround it you need to enable "Optimal Height" on rows with Wrapping enabled.
Created attachment 160885 [details] video of the bug It's annoying when you need to open a file every day. The single solution is to set a default line high size. See the video Version: 7.0.0.0.alpha1+ Build ID: b1e396d86655a0131498a4691dd8069ea76c3477 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: ro-RO (ro_RO.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-05-15_04:58:38 Calc: threaded
Created attachment 180989 [details] Different views of the solutions I investigated the issue, and I have no clear idea how to solve this problem: The row height will be read in ImportExcel::Defrowheight345() which reads a default row height of 160. This value will be set in XclImpColRowSettings::SetDefHeight, and used for the height of the different rows, as seen in the first image. If the current nStdRowHeight of a row is 256 applied, the result is as seen in the second column. At the end of the import in ErrCode ImportExcel8::Read(), even a code was removed in order to avoid the automatic adaptation of the row height: #if 0 // Excel documents look much better without this call; better in the // sense that the row heights are identical to the original heights in // Excel. if ( !rD.IsAdjustHeightLocked()) AdjustRowHeight(); #endif https://github.com/LibreOffice/core/commit/1363fe2fa6849aa1ac678ea444c58a82d417eb47 If we reactivate the last call, it could lead to long loading times of big documents.
In OOP the height adjustments occur in: https://github.com/apache/openoffice/blob/9d58340b4b4928db974535ae81750b02811b636a/main/sc/source/filter/excel/read.cxx#L1213
We could check if the content is to small for that cell and at least adjust the height of the row, but still I am not convinced about such a solution. Opinions?
This document only sets default height (160) when the normal height (for 10pt font) is 255. So that explains the small row height. None of the rows are flagged as having content. They are all NOT ExcColRowFlags::Used, and therefore the row just gets mnDefHeight.
Created attachment 182462 [details] Comparison between MSO and LO for original and MSO resaved XLS and XLSX If original XLS is resaved in MSO as XLS and XLSX, they open fine in LO. So this is under Low category of bugs where file is not proper but it opens OK in MSO and in this case OO. In adddition, LO opens original XLS with Liberation 10 instead of Arial 8. Marked as NotOutBug, although it could have been left in this category of invalid files, like some other bugs.