Bug 62361 - FILEOPEN without optimum row height calculation
Summary: FILEOPEN without optimum row height calculation
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Cells
  Show dependency treegraph
 
Reported: 2013-03-15 06:04 UTC by Rainer Bielefeld Retired
Modified: 2019-03-21 11:26 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Test Kit for easy reproducing Step 20 (12.98 KB, application/zip)
2013-03-15 06:04 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2013-03-15 06:04:09 UTC
Created attachment 76545 [details]
Test Kit for easy reproducing Step 20

I found this one during my tests for "Bug 62268 - FILEOPEN: Optimum row height should be recalculated with "style:use-optimal-row-height='true'"". The core of the problem is that for an existing document (created with 3.3.3) the row height will not be calculated. 

I think that a lot of aspects might have influence whether row height should be adapted. So I contribute all steps including creation of the sample document.

Steps with Server Installation of "LibreOffice 3.3.3  English UI/ German Locale [OOO330m19 (Build:301) tag libreoffice-3.3.3.1] on German WIN7 Home Premium (64bit) (creating sample document)

1. New spreadsheet from LibO Start Center
2. On Sheet2 Cell A1 Type "This is a pretty long text "
3. Increase column A width dragging border between Column headings A-B to 
   app. double size (so that it's a little more than text length)
4. A2: "=A1"
5. fill A2 to A3 .... A20
   > All cells A1:A20 show same text as A1
6. Sheet1.A1: "=CONCATENATE(Sheet2.A1;Sheet2.A2;Sheet2.A3;Sheet2.A4;Sheet2.A5;
   Sheet2.A6;Sheet2.A7;Sheet2.A8;Sheet2.A9;Sheet2.A10)"
   > Shows long text in Sheet1.A1 exceeding Cell size
7. Menu 'Format -> Cells -> Alignment -> Wrap Text Automatically'  <ok>
   > Text wrapped into cell with increased row height (20 text lines or so).
8. Save document as "sample_333_01.ods", close, reopen
   > Still shows text wrapped correctly in Sheet1.A1
9. Double click Sheet2.A1 (Cel Edig mode)
10. <control+a> to select all cell contents
11. <control+c> to copy all cell contents
12. click into cell behind trailing blank
    > caret flashes behind text
13. <control+c> to copy text
    > Text now with double length in All cells
14. Check Sheet1.A1
    Row height has NOT been increased (I haven't a clue whether that is 
    intended or not)
15. Save document as "sample_333_02.ods", close, 
16. reopen "sample_333_02.ods: Now row height HAS been increased, 
    showing approximately 40 text lines in cell for all text
17. Close document without saving

20. Now tests with other versions:
Do only Step 16, until 3.5.6 always will show increased row height for Sheet1.A1
showing app. 40 text lines with all text.

Still [Reproducible] with parallel Dev-installation of  "Version 4.1.0.0.alpha0+ (Build ID: 61add5c77de1ff963b839020c77f67f14ef07de) TinderBox: Win-x86@6, Branch:master, Pull Time:  2013-03-05_00:20:08" ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with LODev/4 Masters User Profile 

Bug:
----
Starting with server installation of "LibreOffice 3.5.7.2  German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit) you will only see the 20 text lines as in step 14, text is truncated in Sheet1.A1.

I believe that this is at least a part of the problem in Bug 62268, But because there might be involved various effects I decided to submit a separate bug.

@Bernhard Dippold:
I believe this test kit reproduces more or less your problem, what do you think? Can you reproduce my observations?
Comment 1 Rainer Bielefeld Retired 2013-03-24 12:19:56 UTC
Seems Bernhard Dippold is not interested in confirming? So I turn it to NEW without review.

@Spreadsheet Team
Please add Whiteboard tag "bibisectrequest" if you think that a bibisect result can ease your work.
Please change  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).
Comment 2 Bernhard Dippold 2013-03-24 14:38:05 UTC
Sorry Rainer - I had too much other work to do this week :-(

I got access to a Windows XP computer with LibO 3.4.3 (OOO340m1, build 302) installed.

With this version your first sample in the testkit (sample_333_01.ods) opens with a height of 8,90 cm for row 1, while the second saple (sample_333_02.ods) opens with 17,29 cm in height.

With LibO 4.0.0.3 on WinXP the row height in sample_333_01.ods is 8,58 cm, in sample_333_02.ods it's 8,58 cm, too.

In both files content.xml shows the defined height for the style used for the first row in sheet 1 (in sample_333_01.ods this style is called "ro1", in sample _333_02.ods the style is "ro2") as "8.585cm". Bot styles use 'style:use-optimal-row-height="true"'.

So yes, I can confirm the bug: Former versions recalculate row height on fileopen, when style:use-optimal-row-height="true", newer versions just use the defined row height without recalculation.

In my eyes this is a REGRESSION, that might be related to quite a number of row height bugs (especially with imported files, as it is very likely that they need a recalculation on fileopen). But as the necessity to recalculate row height on fileopen seems not to be defined in the OASIS ODF definition (as we mentioned in bug 62268), I don't add this keyword. Please feel free to do so, if you agree with me.
Comment 3 Bernhard Dippold 2013-10-30 08:42:52 UTC
After more than half a year without reply by any of the developers asked for comments by Rainer Bielefeld the related bug 62268 has been commented by another user confirming the bug of FILEOPEN without regarding the "use optimal row height" flag being still present in an actual LibO version.

At our hospital group we still use LibO 3.5.5 on servers in 9 hospitals just because of this bug.

I didn't add the REGRESSION keyword as mentioned in my last comment, because I don't know if recalculation on fileopen is part of the OASIS ODF definition.
In bug 62268 Bernhard Donaubauer comments that at least OOo "always stated that the creation of ODF via XML, XSLT, ... is a valid way to generate ODF Files." If this is still valid, this bug is a regression!

Is anybody able to have a look? 
Would it be reasonable to define one of the bugs as duplicate to the other one?
Comment 4 Bernhard Dippold 2013-10-30 11:11:37 UTC
I searched for related bugs and found a few that might be worth to be looked at by a developer starting to work on this (bug 69745 should be added to the related bugs list or marked as duplicate to this one, perhaps bug 55433, bug 63122 or bug 68375 could be fixed too by a possible patch).
Noel Powers provided a patch to bug 49255 (preserving row height on save and open), implemented in LibO 3.5.7. As this bug here (and in bug 62268) was first mentioned in that version, I added him to CC:
Is it possible, that your patch caused ignorance to 'style:use-optimal-row-height="true"' on FILEOPEN?
Do you know any other patch in this version related to this topic?
Best regards
Bernhard (not being a developer I can't find out more by myself)
Comment 5 Bernhard Donaubauer 2013-11-07 09:18:29 UTC Comment hidden (no-value)
Comment 6 Bernhard Dippold 2014-07-15 09:58:05 UTC
Update:
Tested with LibO 4.3.0.2 and LibO-Dev 4.3.1.0.0+ (2014-07-14_09:38:08) on Win 8.1
Sorry for a longer description, but for a decision, if this bug should be closed, you need some more information:

Step 14. results in increased row height, so re-building of the sample documents is no longer possible.

But if you open the sample document "sample_333_02.ods" from the attached Test Kit, you still experience the reduced row height:

Instead of 41 lines in cell A1 on Sheet1 the cell is cut at 21 lines, according to the content.xls it's about 8,6 cm height:
<style:style style:name="ro2" style:family="table-row">
  <style:table-row-properties style:row-height="8.585cm" fo:break-before="auto" style:use-optimal-row-height="true" /> 
</style:style>

So LibO uses the row-height defined in the file, but ignores the flag "style:use-optimal-row-height='true'" in the UI.

As cell A1 on Sheet1 is selected you can find the height of row 1 just in the menu: 'Format -> Row -> Heigth' described as 16,64 cm. 

If you click anywhere in the file (except the LibO menu) the cell is expanded, but the row indices at the left border keep the wrong height.

Only if you force expicitly a recalculation of the screen (by "OK" on row height in the menu, moving the focus out of the visible screen modifying zoom factor or anythign like this) you get the right height including the indices.

Even if you save the document and reopen it, you will get the right row height, as it saves the value style:row-height="16.639cm" in content.xml.

So the bug seems to be still valid - as the behavior in the description "FILEOPEN without optimum row height calculation" is still the same, if you look at the UI.

In the background recalculation seems to be done nevertheless (as to be seen on the menu entry "Format - Row - Height") - so the resulting bug is only a UI refresh bug, no more recalculation.

Should we close this one and open a new bug for this behavior?

Best regards
Bernhard
Comment 7 Owen Genat (retired) 2014-08-01 10:48:42 UTC
(In reply to comment #6)
> Update:
> Tested with LibO 4.3.0.2 and LibO-Dev 4.3.1.0.0+ (2014-07-14_09:38:08) on
> Win 8.1
> Step 14. results in increased row height, so re-building of the sample
> documents is no longer possible.
> 
> But if you open the sample document "sample_333_02.ods" from the attached
> Test Kit, you still experience the reduced row height:
> ...
> If you click anywhere in the file (except the LibO menu) the cell is
> expanded, but the row indices at the left border keep the wrong height.
> ...
> Even if you save the document and reopen it, you will get the right row
> height, as it saves the value style:row-height="16.639cm" in content.xml.

This behaviour also confirmed under GNU/Linux x86_64 using v4.2.5.2. Platform set to All/All.
Comment 8 tommy27 2016-04-16 07:28:57 UTC Comment hidden (obsolete)
Comment 9 Tester 2017-04-21 05:21:22 UTC Comment hidden (obsolete)
Comment 10 Tester 2017-04-21 20:05:17 UTC
Bug is still present in 5.3.2.2. 
Pleas a coder should check the new argument there: bug 62268
Comment 11 Tester 2017-04-22 23:50:11 UTC
Here a link where i assume the bug.
Check: getRowPropertiesMap -> OptimalHeight, OptimalWidth
https://docs.libreoffice.org/xmloff/html/XMLTableExport_8cxx_source.html#l00081
Comment 12 QA Administrators 2018-05-31 02:53:19 UTC Comment hidden (obsolete)
Comment 13 Timur 2018-06-18 16:06:54 UTC
Please test with master and write some simple test steps.
Comment 14 QA Administrators 2019-01-11 15:22:32 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2019-03-21 11:26:10 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-20190321