Created attachment 41824 [details] Speadsheet with bugs demo When I open some (not all) xls-files in LibreOffice I have got wrong formatting height of row (see row_styles.xls and row_styles2.xls) and wrap words (see row_styles1.xls). These bugs is reproductible only in LibreOffice on Linux and Windows (I tested only on x86 architecture). Sun-Oracle versions haven't this bugs (see attachment pictures for detail). LibreOffice-row_styles-bug.png - show opened files with bugs in LibreOffice OracleOpenOfficeorg-row_styles.png and SunOpenOfficeorg-row_styles.png - show opened files without bugs in Sun/Oracle versions of OpenOffice.org Regards Michael Kazarian.
Good find. I'll take it.
I think bug https://bugs.freedesktop.org/show_bug.cgi?id=34717 is related to this one.
(In reply to comment #2) > I think bug https://bugs.freedesktop.org/show_bug.cgi?id=34717 is related to > this one. No. This bug appear from Go-oo 3.1 and present in higher versions. It's Go-oo problem, not in original OpenOffice.org
(In reply to comment #1) > Good find. I'll take it. Hi, Kohei. Year away I posted this bug. Have you some plans to fix it?
Sorry. Got busy. I might turn this into an EasyHack so that others (which could be you) can work on it. The tricky part is that OOo's solution was a sledge hammer approach that massively hurt performance for *all* documents (they simply re-calculated row heights on all rows, which was super slow). So our solution must be sensible performance-wise, by identifying the rows that need re-calculating and only re-calc heights on those rows. BTW strictly speaking we are faithfully importing row heights per what the Excel document specifies. Excel seems to amend row heights on some of them on import when those specified row heights are not high enough (for whatever reason). The right fix is to search for any clues in the file format as to which rows need re-calculation. Setting status to NEW as I'm not working on this. If anyone wants to look into it let me know. I'll provide a code pointer.
Not working @ Ubuntu 11.10 LibreOfficce 3.4.4 OOO340m1 (Build:402) I will have a look on 3.4 soon....
(In reply to comment #6) > Not working @ Ubuntu 11.10 LibreOfficce 3.4.4 OOO340m1 (Build:402) Florian, this bug in LO 3.5 too. See comment 5 from Kohei Yoshida for details.
Reference to the gnumeric bugzilla. https://bugzilla.gnome.org/show_bug.cgi?id=614399 They are having the same issue there as well.
Created attachment 80274 [details] wrong word wrap in print preview mode vs edit mode I think the situation in my attachment is related to this bug. In print preview mode, it show different word wrap vs edit mode. I'm in Ubuntu 13.04 with LibreOffice 4.0.3.3.
> I think the situation in my attachment is related to this bug. > In print preview mode, it show different word wrap vs edit mode. Unlikely, I think. In my situation preview and edit mode behave equally. You have found other bug.
> Unlikely, I think. In my situation preview and edit mode behave > equally. You have found other bug. This bug shows when set the column width almost the same as the text in the auto-wrap cell, while text in that cell is in a single line. Maybe I should file another bug report.
> Maybe I should file another bug report. I think, you would report about your bug. LO developers will understand about related whether our bugs.
Kohei's description in comment 5 might be an explanation for bug 62268 and bug 62361 too. If the performance issue caused ignorance of "style:use-optimal-row-height='true'" in LibO since version 3.5.7.2, we know at least a reason - the next step would be a solution... (I don't add 62268 and 62361 to the related bugs list, as this still might be another reason)
Verified: Ubuntu 14.04 x64 Version: 4.5.0.0.alpha0+ Build ID: 8b65be4740f4349b769a8709867e0cc32d93686d Changing priority according to priority flowchart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg Minor - can slow down professional quality work but will not prevent it. Low - default seems appropriate. Also: Verified on: Ubuntu 14.04 x64 LibreOffice 3.3 (inherited from OOo) Updating version as version is the oldest version that the bug has been confirmed on. Thanks for your patience and understanding in this issue. LibreOffice is powered by volunteers who donate thousands of hours for free to help improve LibreOffice for everyone.
Created attachment 119684 [details] XLS sample A
Created attachment 119685 [details] XLS sample B I have encountered a similar case in LOC 4.4.5.2 - Windows 8.1, I thought it was a bug, but after some tests and checks have established the following. The original sheet is an XLS (Excel XP) in which the rows are formatted with "fixed" height (not "optimal") because the width of the original column was larger and did not have the need. Migrating to LO and opening it in the Calc spreadsheet, it retains those settings correctly. Having now the need to restrict the column and consequently to set the "Wrap text automatically", this feature does not apply if you do not change the formatting of the row by setting "Optimal Height" (what would happen in Excel too). As evidence of the above I attach two files XLS: "SampleTest A" has lines formatted with "fixed" height and opening it with Calc gets the problem; "SampleTest B" has the line 5 formatted "optimal" and gets no problem.
changing summary accoring to findings in bug 95098
Removing comma from Whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
Version: 5.3.0.0.alpha0+ Build ID: c89294233b6a9ffc1bd75e6e9226ad723b7d5538 CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; Locale: en-US (en_US.UTF-8) Still a problem. Setting severity and priority. Minor: Can slow down but will not prevent high quality work; Low: Default for minor bugs.
*** Bug 107552 has been marked as a duplicate of this bug. ***
*** Bug 91234 has been marked as a duplicate of this bug. ***
** 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
Still a thing after 9 years.
Dear Michael Kazarian, 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
Created attachment 180585 [details] XLS sample C I don't know if what I encountered is related to this bug but here's what I've found. I have an xls-file that was generated by a system that we work with. I don't know any details on how it was created. When I opened this file in LibreOffice (tried 7.2.7, 7.3.3 and 3.3.4 as previous comment suggested) the height of rows was incorrect. When I opened it in Microsoft Excel 2016 the height was correct. After I saved it in Excel (without changing anything) and reopened it in LibreOffice the height was also correct. The file has a lot of sheets so I'll attach just one. I also resaved row_styles1.xls and row_styles2.xls in Excel 2016 from the original post. The result was the same: now they both have correct row height in LibreOffice. Maybe this information will help.
repro 7.5+ Based on comment 5, I'd guess this is the XLS version bug 62268 and needs something like the controversial patch 693953dd4699887bd3f5bca2c3582b5fae1d6992 that explicitly called Calc to re-calculate rows after ODS load.
This is fairly easily fixed for XLS in sc/source/ui/docshell/docsh.cxx's ScDocShell::ConvertFrom by setting bSetRowHeights = true. Although that does every row in every sheet, I don't think the performance will be much worse than tracking each row during import - except perhaps for unused rows.
I confirm that Sample-C.xls from comment 26 is another good example for this bug report.
(In reply to Justin L from comment #28) > This is fairly easily fixed for XLS The code change is here. https://gerrit.libreoffice.org/c/core/+/140199 It shows good potential, with only one unit test failing, and that at least partly is because XLSX also needs a fix like this. But even so, empty rows are calculated differently, so the unit test still fails when XLSX is also "fixed". For now, I leave this as a code pointer only.
This bSetRowHeights was true earlier (and called UpdateAllRowHeights), until commit c3ce9a34e710538aee37def65d0077af18140bcb Author: Daniel Rentz on Tue Oct 23 13:51:33 2001 +0000 #93255# speed up chart import bSetRowHeights started calling the brand new ScDocRowHeightUpdater with commit 0cfa5a12cc75e95f26fb6d8b348045bf8ba9bdd1 Author: Kohei Yoshida on Fri Oct 1 22:30:59 2010 -0400 Ported calc-perf-import-dbf-sc.diff from ooo-build This speeds up import of dBase (dbf) files 4-5 times. and as noted in comment 27, ScDocRowHeightUpdater is also used with ODS import.
*** Bug 39486 has been marked as a duplicate of this bug. ***
(In reply to Justin L from comment #30) > But even so, empty rows are calculated differently That might be inevitable. The difference that I saw was border spacing (.71mm in XLS and .35mm in .XLSX). AFAICS, these are unchangeable, built-in defaults although I haven't found the code for that yet. Bug 140185 talks about this.
(In reply to Justin L from comment #33) > I haven't found the code for that yet. sc/source/filter/excel/xistyle.cxx's XclImpXF::CreatePattern // Excel's cell margins are different from Calc's default margins. SvxMarginItem aItem(40, 40, 40, 40, ATTR_MARGIN); [Excel here meaning binary excel. oox matches Calc's default margins and so doesn't need to do anything different.]
Is this not being called for XLS? void ImportExcel::AdjustRowHeight() { /* Speed up chart import: import all sheets without charts, then update row heights (here), last load all charts -> do not any longer update inside of ScDocShell::ConvertFrom() (causes update of existing charts during each and every change of row height). */ if( ScModelObj* pDocObj = GetDocModelObj() ) pDocObj->UpdateAllRowHeights(); }