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