Bug 32950 - FORMATTING Cell height and word wrapping can be wrong (when changing) xls-files because 'Optimal height" of rows is not set (automatically?)
Summary: FORMATTING Cell height and word wrapping can be wrong (when changing) xls-fil...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard: interoperability
Keywords: needsDevEval
: 91234 107552 (view as bug list)
Depends on:
Blocks: Calc-Cells
  Show dependency treegraph
 
Reported: 2011-01-09 23:03 UTC by Michael Kazarian
Modified: 2019-01-29 17:40 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Speadsheet with bugs demo (719.80 KB, application/x-gzip)
2011-01-09 23:03 UTC, Michael Kazarian
Details
wrong word wrap in print preview mode vs edit mode (231.85 KB, application/gzip)
2013-06-04 09:16 UTC, Kevin Suo
Details
XLS sample A (7.50 KB, application/x-ole-storage)
2015-10-17 08:19 UTC, gmarco
Details
XLS sample B (7.00 KB, application/x-ole-storage)
2015-10-17 08:25 UTC, gmarco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kazarian 2011-01-09 23:03:22 UTC
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.
Comment 1 Kohei Yoshida 2011-01-10 20:51:15 UTC Comment hidden (obsolete)
Comment 2 Aurimas Fišeras 2011-03-29 02:58:13 UTC Comment hidden (obsolete)
Comment 3 Michael Kazarian 2011-03-29 22:21:52 UTC
(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
Comment 4 Michael Kazarian 2012-02-14 23:44:25 UTC
(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?
Comment 5 Kohei Yoshida 2012-02-15 07:50:46 UTC
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.
Comment 6 Florian Reisinger 2012-03-25 06:29:16 UTC
Not working @ Ubuntu 11.10 LibreOfficce 3.4.4 OOO340m1 (Build:402)
I will have a look on 3.4 soon....
Comment 7 Michael Kazarian 2012-03-25 22:08:10 UTC
(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.
Comment 8 Kohei Yoshida 2012-05-08 13:28:00 UTC
Reference to the gnumeric bugzilla.

https://bugzilla.gnome.org/show_bug.cgi?id=614399

They are having the same issue there as well.
Comment 9 Kevin Suo 2013-06-04 09:16:05 UTC
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.
Comment 10 Michael Kazarian 2013-06-05 05:51:07 UTC
> 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.
Comment 11 Kevin Suo 2013-06-05 06:45:17 UTC
> 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.
Comment 12 Michael Kazarian 2013-06-05 11:47:36 UTC
> Maybe I should file another bug report.
I think, you would report about your bug. LO developers will understand about related whether our bugs.
Comment 13 Bernhard Dippold 2013-10-30 09:03:18 UTC
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)
Comment 14 Joel Madero 2014-12-15 01:48:03 UTC
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.
Comment 15 gmarco 2015-10-17 08:19:53 UTC
Created attachment 119684 [details]
XLS sample A
Comment 16 gmarco 2015-10-17 08:25:43 UTC
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.
Comment 17 Cor Nouws 2015-10-30 07:33:26 UTC
changing summary accoring to findings in bug 95098
Comment 18 Robinson Tryon (qubit) 2015-11-19 00:37:42 UTC Comment hidden (obsolete)
Comment 19 Robinson Tryon (qubit) 2015-12-14 06:13:31 UTC Comment hidden (obsolete)
Comment 20 Joel Madero 2016-07-04 07:16:23 UTC
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.
Comment 21 m.a.riosv 2017-05-02 01:00:32 UTC
*** Bug 107552 has been marked as a duplicate of this bug. ***
Comment 22 m.a.riosv 2017-05-02 01:01:57 UTC
*** Bug 91234 has been marked as a duplicate of this bug. ***
Comment 23 QA Administrators 2018-06-01 02:16:35 UTC
** 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