Bug 62268 - FILEOPEN: Optimum row height should be recalculated with "style:use-optimal-row-height='true'"
Summary: FILEOPEN: Optimum row height should be recalculated with "style:use-optimal-r...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Vasily Melenchuk (CIB)
URL:
Whiteboard: target:6.2.0 target:6.1.4
Keywords: bibisected, bisected, regression
: 69745 (view as bug list)
Depends on:
Blocks: Calc-Cells
  Show dependency treegraph
 
Reported: 2013-03-12 23:49 UTC by Bernhard Dippold
Modified: 2019-05-02 09:13 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
File containing two lines: First one unchanged with wrong row height, second one re-arranged with optimal height. (13.04 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-03-12 23:49 UTC, Bernhard Dippold
Details
Macros as Workaround (16.73 KB, application/x-vnd.oasis.opendocument.spreadsheet)
2013-03-14 05:56 UTC, Rainer Bielefeld Retired
Details
Sample document, first step. (8.52 KB, application/x-vnd.oasis.opendocument.spreadsheet)
2013-03-14 19:23 UTC, Rainer Bielefeld Retired
Details
Small Calc document where line wrap in cell A4 should cause recalculation of row height (36.39 KB, application/x-vnd.oasis.opendocument.spreadsheet)
2013-03-25 16:28 UTC, Bernhard Dippold
Details
Testdocument showing that row height is not being corrected by LO to display large text (8.88 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-08-17 10:43 UTC, Svante Schubert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Dippold 2013-03-12 23:49:24 UTC
Created attachment 76450 [details]
File containing two lines: First one unchanged with wrong row height, second one re-arranged with optimal height.

In the anesthesia documentation software used on about 100 PC (and several Citrix server) in 9 hospitals we add data to the content.xml of a spreadsheet, open it in a hidden mode and export it to PDF. From OOo 3.1 to LibO 3.4.4 this worked fine - we created great charts and well arranged tables.

With LibO 3.6.2.2 (Build ID: da8c1e6) and LibO 4.0.1.2 (Build ID: 84102822e3d61eb989ddd325abf1ac077904985) on Win XP automatic row height is no longer recalculated on fileopen.

Expected behavior:
The largest content in any cell of a row determines the row height when opening the file. All the content is visible in the cell.

Present behavior:
The cells are determined by the cell height defined in the content.xml ignoring the flag "style:use-optimal-row-height='true'". 

How to reproduce:
Open the attached file: You see two rows with text. 
Row 4 contains a large text that is not visible as the row height is not adapted to the optimal row height.
Row 5 has been re-adjusted with [Format] - [Row] - [Optimal height] just to find out, if there are differences in the content.xml (I can't see any)

I hope there is a way to find the reason for this behavior - I don't want to force our admins to re-install LibO 3.4.4 on more than 100 PCs.

Best regards 
Bernhard (formerly known as bedipp at OOo and LibO)
Comment 1 Bernhard Dippold 2013-03-13 00:02:40 UTC
Bug 49255 seems to be similar to my problem, but as it has been reported and fixed previously, it must be different.
Comment 2 Rainer Bielefeld Retired 2013-03-13 06:41:53 UTC
To avoid misunderstanding: I do not think that we promise somewhere that there will be automatic row height adaption when a file is opened I would dislike such a function. What if I intendedly wanted to "hide" some text? When I open a document I want to see the same row height I saw when I saved the document.

And that seems more or less what reporter expects.

To get familiar with the current situation I did some tests (what might not all be related to core of the problem).

Due to <http://odf-validator2.rhcloud.com/odf-validator2/> reporter's sample document is valid ODF
I opened reporter's sample with various different LibO Versions (all: WIN7, 64 Bit), checked row heights for rows, tested result (problem healed?)  after
a: for A4:A5 Format --> Rows -> Optimimum height'
b: Insert <Space>, then <Enter> at end of cell text
c: Result (text vies A5) when reopen documents after test 'b' (problem with version from ....)

3.3.3
row 4: 51,8 mm, not all text visible, a: yes,  b: yes
row 5: 07,6 mm, all text visible,   
c: 3.3.3=cut top/bottom  3.4.5=cut top/bottom   3.5.7.2=cut top/bottom  
4.0.1.2=cut top/bottom, Master=cut top/bottom
AOO=cut top/bottom  Symph=cut top/bottom

3.4.5
row 4: 51,8 mm, not all text visible, a: yes,  b: yes
row 5: 07,6 mm, all text visible, 
c: Same as with 3.3.3  

3.5.7.2
row 4: 04,8 mm, not all text visible, a: yes,  b: yes
row 5: 07,9 mm, all text visible,     
c: All correct opened

3.6.5.2
row 4: 04,8 mm, not all text visible, a: yes,  b: yes
row 5: 07,9 mm, all text visible,
c: All correct opened     

4.0.1.2
row 4: 04,8 mm, not all text visible, a: yes,  b: yes
row 5: 07,9 mm, all text visible,  
c: All correct opened

4.1.0.0+ Master
row 4: 04,8 mm, not all text visible, a: yes,  b: yes
row 5: 07,9 mm, all text visible, 
c: All correct opened

AOOo 3.4.1
row 4: 54,8 mm, all text visible,
row 5: 07,2 mm, all text visible,    
c: not tested

Symphony
row 4: 51,4 mm, all text visible, not all text visible, a: yes,  b: yes
row 5: 07,2 mm, all text visible,
c: not tested   

After all these results I would like a more precise Bug Summary: Optimum row height should be retained after save - close - reopen.
For this bug definitions after LibO 3.4 no longer any problems

So I see this problem WFM.

@Bernhard Dippold
first: I can not reproduce your results. Only AOOo opens your sample with optimum row height. All LibO versions cut contents.
I think your problem is different to the one you stated in the summary line. It seems you expect that due to "style:use-optimal-row-height='true' the row height should be recalculated when you open the file. But that might be wrong.

I cite ISO/IEC 26300 First edition 2006-12-01:
15.10.2 Optimal Table Row Height
The style:use-optimal-row-height attribute specifies that the row height should be recalculated automatically if some content in the row changes.

Or 
Open Document Format for Office Applications (OpenDocument) Version 1.2 Part 1: OpenDocument Schema OASIS Standard  29 September 2011:
20.384 style:use-optimal-row-height
The style:use-optimal-row-height attribute specifies that a row height should be
recalculated automatically if content in the row changes.
The defined values for the style:use-optimal-row-height attribute are:
● false: row height should not be recalculated automatically if content in the row changes.
● true: row height should be recalculated automatically if content in the row changes.

This is something like my test 'B' and works for all LibO Versions. But you can't expect a recalculation at fileopen, your software manipulating contents will be responsible for height recalculation. May be you benefitted from some liberal interpretation of ISO or similar? Can you explain the different observations? I see text in A5 truncated also with 3.4.5., can it be that 3.4.4 behavior differs? I will check later.

Currently I see no bug here.
Comment 3 Rainer Bielefeld Retired 2013-03-13 06:46:43 UTC
Summary more nearby reporter's expectations
Comment 4 Rainer Bielefeld Retired 2013-03-13 09:13:21 UTC
@Bernhard:
I can't reproduce your result that optimum row height will be calculated when open file with Server Installation of "LibreOffice 3.4.4  - WIN7 Home Premium (64bit) German UI [Build ID: OOO340m1 (Build:402)]": Your sample and all copies created with m Test b from various versions all show truncated test at bottom and top of cell A4.
Comment 5 Bernhard Dippold 2013-03-13 22:31:28 UTC
Thank you very much, Rainer, for your examinations and the explanations you made about ODF OASIS Standard.

You're right in explaining our expectations - and your new summary describes our intentions very well.

My sample document has been opened and saved with LibO 3.6.2 and thus doesn't show the way former versions did handle the files for several years.

I'm going to ask our software developer to provide a file unchanged by LibO, so you can test it with the older versions. What he told me is:

- LibO up to version 3.4.4 recalculated row height on fileopen, when style:use-optimal-row-height="true"
- Excel 2010 recalculates it in the same way.
- As you tested, AOO 3.4.1 does the same recalculation on fileopen

- only present LibO versions don't do the recalculation, but use the row height defined in the content.xml despite the flag.

With your tests you describe a similar difference between the versions:
Up to version 3.4.5 row height in Row 3 is 51,8 mm. Even if the content is not fully visible, row height has been recalculated to fit the text. The height is slightly too small, so I assume that someone wrote a patch in order to optimize this recalculation. I'm quite sure that this didn't affect fileopen only, but entire recalculation of optimal row height. 

I probably didn't search for the right key words, but I wasn't able to find the bug containing the patch correcting the problem, that automated row height adaption was slightly too small.

This (or a similar) patch seems to stop recalculation of optimal-row-heigth on fileopen: 

In your test all versions from 3.5.7.2 show a row height of 4,8 mm - the height defined in content.xml ignoring the optimal-row-height flag.

I'm not the one to decide, if AOO and Excel 2010 are wrong in interpreting ODF OASIS Standard as recalculation of row height after modification of the content whether this has been made in the current application or outside.

If LibO interpretes the Standard as only to be respected inside the own application, we need to drop the new LibO versions in all our hospitals.

Please tell me, if I should address this question to one of the mailing lists (which one? libreoffice@lists.freedesktop? discuss@documentfoundation?).

But I could imagine that some of the XLS related bug reports might be related to the problem that the slightly different font size between the office suites cause wrong row heights on fileopen...

Please change the status to NEEDINFO again, if you need more information.
(Or change it to NEW if you think it is worth to work on it)
Comment 6 Rainer Bielefeld Retired 2013-03-14 05:56:14 UTC
Created attachment 76510 [details]
Macros as Workaround

(In reply to comment #5)
As a quick workaround I tried 2 Macros.
Row by row from 
 <http://www.calc-info.de/files/Calc_StarBasic.pdf> (slow!)
and "System" with a self recorded macro what simply does menu(s) 
'Edit -> Select All ->> Format Row height -> Optimum Row Height' (auick)

Macros not as ready solution, only as a demo showing possibilities. An expert should be able to created some kind of Extension solving your problem in such a way applying optimum row hight at every file open.

Because I do not know whether this here will end with a fix (because behavior might be intended) I recommend to present the problem on <http://ask.libreoffice.org/en/questions/> and may be post a minimum description with link to "AskLibO" on 
<discuss@de.libreoffice.org>, <discuss@documentfoundation.org>
May be someone can give a hint concerning a secret flag in the LibO settings or similar ...
Comment 7 Rainer Bielefeld Retired 2013-03-14 19:23:00 UTC
Created attachment 76538 [details]
Sample document, first step.

I did some more tests and was already able to reproduce an at least very similar problem, but it seems that the problem is related to a very particular way to create the document, and I forgot the way :-(
But I will find it again, I am sure.

May be you want to do some tests with attached sample.ods, what should show correctly calculated row height in Tabelle1.A1 until LibO 3.4, starting with 3.5(.7.2) row height calculation fails
Comment 8 Bernhard Dippold 2013-03-14 23:28:46 UTC
Here at work I can't test other versions than 3.6.2 and 4.0.1.

Both show the wrong height in your sample.ods.

The height shown is the one defined in the content.xml: 24,64mm
So it ignores "style:use-optimal-row-height='true'".

I don't know how you created the sample file, but it's behavior is similar to bug 57519 (if you save the created file): 
You just have to open a file where the row height defined in content.xml is different from the result of a recalculation of the optimal row height.

Perhaps the modification we're looking for has not been any work concerning row height recalculation, but was part of speed optimization on fileopen:

If someone decided that it is not necessary to recalculate every row (with 'optimal height') on fileopen, this would probably lead to faster opening of large documents. 

I didn't get a sample document from our software developer containing the data we open in LibO and convert to PDF - I'll upload it ASAP.

PS: Your macros miss the (previously unmentioned) point that our documents contain rows with absolute (fixed) height. If you are interested in such a document (containing 7 sheets) I'm going to remove all identificable patient data and send it to you as PM.
Comment 9 Rainer Bielefeld Retired 2013-03-15 06:06:28 UTC
I submitted "Bug 62361 - FILEOPEN without optimum row hight calculation", what seems related or even might be a DUP. I think in that bug I reproduce reporter's original problem, what is not possible with sample "2013-03-12 23:49 UTC, Bernhard Dippold ".
Comment 10 Bernhard Dippold 2013-03-25 16:28:46 UTC
Created attachment 77008 [details]
Small Calc document where line wrap in cell A4 should cause recalculation of row height

Now got an example file unmodified by a recent LibO version:

Open the file and have a look at cell A4:

LibO Versions before 3.5.7.2 (my test version: LibO 3.4.3 build OOO340m on WInXP) show five lines of text:

START
THIS IS A LOOOONG TEXT

TEXT TEXT TEXT
->ENDE<-

Row height is expanded to 1,89cm to fit the content.

Newer versions (I tested it with LibO 4.0.0.3 Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89 on WinXP) just show the empty middle line, marked with a red triangle at the rigth border to indicate more content.

Row height is 0,48cm.

Automatic word wrap is activated for cell A4.

Content.xml states optimal row height as true while defining row-heigth as 0,478cm :

- <style:style style:family="table-row" style:name="ro2">
  <style:table-row-properties fo:break-before="auto" style:row-height="0.478cm" style:use-optimal-row-height="true" /> 
.
.
.
- <table:table-row table:style-name="ro2">
- <table:table-cell office:value-type="string" table:style-name="ce4">
  <text:p>START THIS IS A LOOOONG TEXT TEXT TEXT TEXT ->ENDE<-</text:p> 
  </table:table-cell>
...
</table:table-row>

This file should replace attachment 76450 [details] because my first file had been opened and saved by LibO 3.6.4 and therefore doesn't show the different behavior between the older and newer versions.
Comment 11 Bernhard Dippold 2013-03-25 16:31:26 UTC
Comment on attachment 77008 [details]
Small Calc document where line wrap in cell A4 should cause recalculation of row height

description corrected
Comment 12 Bernhard Donaubauer 2013-10-21 15:00:54 UTC
Is there any news on this issue. We installed a new version of LO on our server and have now the same problem as Bernhard Dipphold explained. This error - in my opinion it is an error - hits our reporting tools based on ODF an LO.

I think I can remember that at least OO always stated that the creation of ODF via XML, XSLT, ... is a valid way to generate ODF Files. If you don't calculate the row height this way is getting invalid at least in respect to the "use-optimal-row-height" attribute. I have no way in XSLT to calculate the row height.

I wonder why this feature was removed? Is there a bug number?


I think it would be possible to settle both parties with the following algorithm:


a) if there is no height attribute and the "use_optimal-row-height" attribute is set then calculate the row height

b) if there is no height attribute and the "use_optimal-row-height" attribute is not set then use the default value

c) if there is a height attribute just use it


Regards,
Bernhard Donaubauer
Comment 13 Bernhard Dippold 2013-10-30 08:22:27 UTC
If I understood Rainer Bielefeld correct, he moved the main target of this bug to bug 62361. Even if nobody else commented the other bug, it's status is NEW while this one is still UNCONFIRMED - so it stays under the radar of (nearly) everybody.

I'm going to add a comment to bug 62361 about your confirmation here for the present versions of LibO - and if you would change the status here to NEW, this might lead to more interest here. Perhaps one of the developers would be able to decide if this one is a duplicate to #62361 or vice versa.

(I added you to the CC list - please remove yourself if you get my comments twice becasue of your preference settings)
Comment 14 Robinson Tryon (qubit) 2014-12-30 00:15:28 UTC
TESTING on Ubuntu 14.04 + LO 3.5.0.3 and LO 4.4.0.1

(In reply to Bernhard Dippold from comment #10)
REPRO Steps:
> Open attachment 77008 [details] and have a look at cell A4:
> 
> LibO Versions before 3.5.7.2 (my test version: LibO 3.4.3 build OOO340m on
> WInXP) show five lines of text:
> 
> START
> THIS IS A LOOOONG TEXT
> 
> TEXT TEXT TEXT
> ->ENDE<-

CONFIRMED: That's how it appears for me in 3.5.0.3

> Row height is expanded to 1,89cm to fit the content.
> 
> Newer versions (I tested it with LibO 4.0.0.3 Build ID:
> 7545bee9c2a0782548772a21bc84a9dcc583b89 on WinXP) just show the empty middle
> line, marked with a red triangle at the rigth border to indicate more
> content.

CONFIRMED: Testing with 3.5.7.2, it looks like I just see the bottom edge of the line of text, until I click on the Input Line.

With 4.4.0.1, the multiple lines appear consolidated into a single line (with all of the text visible), and no red arrow. When I click on the Input Line, then the cell expands and I see multiple lines at once.

This is definitely a change in behavior. I'm guessing it's intentional and not an unexpected regression, but it would be good to know when this happened, so 
Whiteboard -> bibisectRequest
keywords -> regression
Status -> NEW
Comment 15 Bernhard Dippold 2015-01-05 15:01:00 UTC
Thanks Robinson (qubit) for confirming!
Could you please also have a look at the correspondig bug 62361 ?

In this bug report here we have three different behaviours when opening the example file (attachment 77008 [details]):

LibO before 3.5.7.2 expands the row height on fileopen according the flag "style:use-optimal-row-height='true'". The multiple line input is visible when the file is opened, row-height of row 4 is 1,89cm. 
(tested with 3.5.5.3 today)

LibO 3.5.7.2 shows only a part of the text, as the text contains the line breaks and the cell height is not expanded. At the moment, I don't have access to this version, but the description in comment 12 is what I remember from 4.0.0.3.


Present LibO versions ignore the line breaks in the text - it is consolidated into one line: "STARTTHIS IS A LOOOONG TEXTTEXT TEXT TEXT->ENDE<-" (row-height of line 4 is 0,48cm). Input field shows only "START", probably because of the (invisible) line break. There is no red triangle, because all of the text is visible, even if the format is broken.

If you click inthe input line or double click the text the text is formatted:
"START
THIS IS A LOOOONG TEXT

TEXT TEXT TEXT
->ENDE<-"

Row height is still too small to fit the text, but if you modify the text (even if you add and remove a character), it is recalculated with the correct row height (1,74cm). If you leave the cell without modifications, row height stays small, the text is consolidated again. Even if you undo the modifications row height is reduced and the text doesn't contain any line breaks anymore.

Please - anybody with knowledge in this area: Could yo tell us, what is the reason for these changes?
Comment 16 Matthew Francis 2015-01-20 08:23:06 UTC
Bibisect points to source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6 in 43all (massive quantities of skipping required so I will omit the log)

Follow-up source bisection points to the below commit. Looks like a GSOC 2012 job.


commit cd2f8a1cabbfb924c62d7af2aac3ac09288c2d4c
Author: Daniel Bankston <daniel.e.bankston@gmail.com>
Date:   Mon Jun 25 01:21:26 2012 -0500

    Stop calculating row heights and instead use imported row heights only
    
    Change-Id: I1a5e33c292fb915e61511efbdb9ce4a0cfd7265f
Comment 17 Bernhard Dippold 2015-01-21 12:58:01 UTC
Hi Matthew, thanks for bibisection!

As ignoring the flag "style:use-optimal-row-height='true'" on FileOpen has been done on purpose, I wouldlike to know, where we should discuss the positive and negative aspects of this behavior. 

While I understand, that file opening time can be reduced in the majority of cases by ignoring that flag, LibreOffice loses it's capacity to handle files in ODS Format being modified on XML base (while staying valid OASIS ODF documents).

I stated in the first comment the importance of this point for our group of hospitals, so we need a decision inside LibO on the way to go. If necessary we would give AOO a try, but that's a step I'd really like to avoid.

So - where should the question be discussed?
discuss@documentfoundation.org?
libeoffice@lists.freedesktop.org?

Thanks for reply!
Comment 18 Robinson Tryon (qubit) 2015-12-13 11:09:40 UTC Comment hidden (no-value, obsolete)
Comment 19 Tester 2017-04-21 05:17:36 UTC
(I prepared this text for the bug report and found this here... so i post my issue. i agree with Bernhard Dippold

Calc Version: 5.3.0.3 (Bug is still present)

Issue, libreoffice-Calc should update the automatic optimal height of rows, wen the file is opened.
This is a issue which maybe shows up only by outside generated documents (Not saved by libreoffice-Calc).

The Rows are set to be formated in optimal height, and because the generator can not know this hight, the data is left out.
Calc should now update the Rows heights to there optimal. But after opening a document, all rows are in the same standard hight.
The expected behavior is that Calc updates the height from this rows automatically by the opening of the file, in case no height is set in the XML. So that the user don't have to take any further action to correct the heights manually.
I speculate, a simple trigger of a "Do-Automatic-Row-Height-Correction" in the opening process fix the bug. dependent of the code, it is maybe only 1 code line more.

Below are the XML codes generated form external generator, and tests.
See in "office:automatic-styles" the "style:use-optimal-row-height" option in ro1 ro2
See in "office:automatic-styles" the "style:row-height" option in r03 r04
r03 r04 are the data generated from a external generator, form him it is impossible to predict the height.

If a automatic update is not wanted, "style:use-optimal-row-height" simply must be "false". It is set to "false" from Calc automatically, in case a user changes the hight manually.
If it is "true", the correct behavior is to update it on file-load.


(I ca send a exampple.ods, but a expert should unterstand the issue immediately.)

(In case you care about details, my ODS generator is a PHP code, which generates documentation for medical informations. The users of the generator should not do extra work to correct the row hight after opening the document. And the generator can not know the hight Calc will create, so can not set it in the generation process. The update must be done by loading the file. So pleas no work arounds.)


content.xml:
...

	<office:automatic-styles>
	
		<style:style style:name="ta1" style:family="table" style:master-page-name="Default">
			<style:table-properties table:display="true" style:writing-mode="lr-tb"/>
		</style:style>
		
		<style:style style:name="co1" style:family="table-column">
			<style:table-column-properties fo:break-before="auto" style:column-width="50mm"/>
		</style:style>
		
		<style:style style:name="ro1" style:family="table-row">
			<style:table-row-properties style:row-height="4mm" fo:break-before="auto" style:use-optimal-row-height="false"/>
		</style:style>
		
		<style:style style:name="ro2" style:family="table-row">
			<style:table-row-properties style:row-height="4mm" fo:break-before="auto" style:use-optimal-row-height="true"/>
		</style:style>
		
		<style:style style:name="ro3" style:family="table-row">
			<style:table-row-properties style:row-height="" fo:break-before="auto" style:use-optimal-row-height="true"/>
		</style:style>
		
		<style:style style:name="ro4" style:family="table-row">
			<style:table-row-properties fo:break-before="auto" style:use-optimal-row-height="true"/>
		</style:style>
		
	</office:automatic-styles>
	
	
	<office:body>
		<office:spreadsheet>
			<table:calculation-settings table:automatic-find-labels="false" table:use-regular-expressions="false" table:use-wildcards="true"/>
			<table:table table:name="Tabelle1" table:style-name="ta1">
				<table:table-column table:style-name="co1" table:default-cell-style-name="Default"/>
				
				<table:table-row table:style-name="ro1">
					<table:table-cell office:value-type="string" calcext:value-type="string">
						<text:p>Fix Hight, No Automatic Update, Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight</text:p>
					</table:table-cell>
				</table:table-row>
				
				<table:table-row table:style-name="ro2">
					<table:table-cell office:value-type="string" calcext:value-type="string">
						<text:p>Automatic Known Hight, but Wrong, Do Automatic Update?, Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight</text:p>
					</table:table-cell>
				</table:table-row>
				
				<table:table-row table:style-name="ro3">
					<table:table-cell office:value-type="string" calcext:value-type="string">
						<text:p>Automatic Unknown Hight, Do Automatic Update!, Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight</text:p>
					</table:table-cell>
				</table:table-row>
				
				<table:table-row table:style-name="ro4">
					<table:table-cell office:value-type="string" calcext:value-type="string">
						<text:p>Automatic Unknown Hight, Do Automatic Update!, Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight</text:p>
					</table:table-cell>
				</table:table-row>
				
			</table:table>
			<table:named-expressions/>
		</office:spreadsheet>
	</office:body>

...
Comment 20 Tester 2017-04-21 20:16:29 UTC
Bug is still present in 5.3.2.2. 

i tray quick if i can see something in the code. here the result.
i am not a Libre coder, i look in the code the first time and only for minutes.
i have not check the code logic! please a coder should check the conclusion here carefully, and forgive me in case i searched at the wrong place...
if this is not the bug source, i will try to search a little more, to see how far i come... but please check the argument here first.


this is the search trace so far

from libreoffice-5.3.2.2.tar.xz

--> use-optimal-row-height
TOKEN( "use-optimal-column-width",        XML_USE_OPTIMAL_COLUMN_WIDTH ),
TOKEN( "use-optimal-row-height",          XML_USE_OPTIMAL_ROW_HEIGHT ), 

--> XML_USE_OPTIMAL_ROW_HEIGHT

!!! This code shows a anomaly. The name mapping seams to be wrong.
	libreoffice-5.3.2.2\xmloff\source\table\XMLTableExport.cxx

"XML_MIN_ROW_HEIGHT" is mapped as "OptimalHeight"
"XML_USE_OPTIMAL_ROW_HEIGHT" is mapped as "OptimalWidth"

 const XMLPropertyMapEntry* getRowPropertiesMap()
{
    static const XMLPropertyMapEntry aXMLRowProperties[] =
    {
        RMAP( "Height",         XML_NAMESPACE_STYLE, XML_ROW_HEIGHT,                    XML_TYPE_MEASURE,   0 ),
        RMAP( "OptimalHeight",  XML_NAMESPACE_STYLE, XML_MIN_ROW_HEIGHT,                XML_TYPE_MEASURE,   0 ),
        RMAP( "OptimalWidth",   XML_NAMESPACE_STYLE, XML_USE_OPTIMAL_ROW_HEIGHT,        XML_TYPE_BOOL, 0 ),
        MAP_END
    };

    return &aXMLRowProperties[0];
}

--> getRowPropertiesMap
	libreoffice-5.3.2.2\xmloff\source\table\XMLTableExport.cxx

	mxRowExportPropertySetMapper = new SvXMLExportPropertyMapper( new XMLPropertySetMapper( getRowPropertiesMap(), xFactoryRef.get(), true ) ); 


	libreoffice-5.3.2.2\xmloff\source\table\XMLTableImport.cxx

	rtl::Reference < XMLPropertySetMapper > xRowMapper( new XMLPropertySetMapper( getRowPropertiesMap(), xFactoryRef.get(), false ) ); 


	
	
--> Some More... XML_USE_OPTIMAL_ROW_HEIGHT
Here it seams to be correct
"XML_USE_OPTIMAL_ROW_HEIGHT" is mapped as "OptimalHeight"

const XMLPropertyMapEntry aXMLScRowStylesImportProperties[] =
{
    // #i57867# Include background color (CellBackColor/IsCellBackgroundTransparent) for import only.
    // Import and export should use the same map, with MID_FLAG_NO_PROPERTY_EXPORT for the background entries,
    // but this doesn't work at the moment because SvXMLImportPropertyMapper compares MID_FLAG_NO_PROPERTY to 0.
    // If this is changed (not for 2.0.x), a single map can be used again.

    MAP( "CellBackColor", XML_NAMESPACE_FO, XML_BACKGROUND_COLOR, XML_TYPE_PROP_TABLE_ROW|XML_TYPE_COLORTRANSPARENT|MID_FLAG_MULTI_PROPERTY|MID_FLAG_MERGE_ATTRIBUTE, 0 ),
    MAP( "Height", XML_NAMESPACE_STYLE, XML_ROW_HEIGHT, XML_TYPE_PROP_TABLE_ROW|XML_TYPE_MEASURE, CTF_SC_ROWHEIGHT),
    MAP( "IsCellBackgroundTransparent", XML_NAMESPACE_FO, XML_BACKGROUND_COLOR, XML_TYPE_PROP_TABLE_ROW|XML_TYPE_ISTRANSPARENT|MID_FLAG_MULTI_PROPERTY|MID_FLAG_MERGE_ATTRIBUTE, 0 ),
    MAP( "IsManualPageBreak", XML_NAMESPACE_FO, XML_BREAK_BEFORE, XML_TYPE_PROP_TABLE_ROW|XML_SC_TYPE_BREAKBEFORE, CTF_SC_ROWBREAKBEFORE),
    MAP( "OptimalHeight", XML_NAMESPACE_STYLE, XML_USE_OPTIMAL_ROW_HEIGHT, XML_TYPE_PROP_TABLE_ROW|XML_TYPE_BOOL, CTF_SC_ROWOPTIMALHEIGHT),
    MAP_END()
};
 const XMLPropertyMapEntry aXMLScRowStylesProperties[] =
{
    MAP( "Height", XML_NAMESPACE_STYLE, XML_ROW_HEIGHT, XML_TYPE_PROP_TABLE_ROW|XML_TYPE_MEASURE, CTF_SC_ROWHEIGHT),
    MAP( "IsManualPageBreak", XML_NAMESPACE_FO, XML_BREAK_BEFORE, XML_TYPE_PROP_TABLE_ROW|XML_SC_TYPE_BREAKBEFORE, CTF_SC_ROWBREAKBEFORE),
    MAP( "OptimalHeight", XML_NAMESPACE_STYLE, XML_USE_OPTIMAL_ROW_HEIGHT, XML_TYPE_PROP_TABLE_ROW|XML_TYPE_BOOL, CTF_SC_ROWOPTIMALHEIGHT),
    MAP_END()
}; 
const XMLPropertyMapEntry aXMLScFromXLSRowStylesProperties[] =
{
    MAP( "Height", XML_NAMESPACE_STYLE, XML_ROW_HEIGHT, XML_TYPE_PROP_TABLE_ROW|XML_TYPE_MEASURE, CTF_SC_ROWHEIGHT),
    MAP( "IsManualPageBreak", XML_NAMESPACE_FO, XML_BREAK_BEFORE, XML_TYPE_PROP_TABLE_ROW|XML_SC_TYPE_BREAKBEFORE, CTF_SC_ROWBREAKBEFORE),
    MAP( "OptimalHeight", XML_NAMESPACE_STYLE, XML_USE_OPTIMAL_ROW_HEIGHT, XML_TYPE_PROP_TABLE_ROW|XML_TYPE_BOOL_FALSE, CTF_SC_ROWOPTIMALHEIGHT),
    MAP_END()
};


Here it seams to be correct
"XML_USE_OPTIMAL_COLUMN_WIDTH" is mapped as "OptimalWidth"

const XMLPropertyMapEntry* getColumnPropertiesMap()
{
    static const XMLPropertyMapEntry aXMLColumnProperties[] =
    {
        CMAP( "Width",          XML_NAMESPACE_STYLE,    XML_COLUMN_WIDTH,               XML_TYPE_MEASURE,   0 ),
        CMAP( "OptimalWidth",   XML_NAMESPACE_STYLE,    XML_USE_OPTIMAL_COLUMN_WIDTH,   XML_TYPE_BOOL, 0 ),
        MAP_END
    };

    return &aXMLColumnProperties[0];
}


thanks
Comment 21 Tester 2017-04-22 13:42:32 UTC
So much i see, [fo:break-before="auto"] for word wrap is not either updated in the file open process. (The small red arrow on the right of the cell is visible)

Could it be that a developer deactivated the updating function on file open, if the above post really shows a bug, and causes wrong behavior on file load?
Comment 22 Tester 2017-04-22 14:52:24 UTC
A correction for my last post:
The [fo:wrap-option="wrap"] option is not either updated in the file open process, 
not the [fo:break-before="auto"].
Comment 23 Tester 2017-04-22 23:48:50 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 24 Bernhard Dippold 2017-04-23 00:06:58 UTC
Thanks for looking in that one, Tester!

As I'm no developer, this issue causes quite a number of computers to be stuck with LibO 3.4 (sic!) for years...

If the bug just consist of a wrong mapping, a fix should be probably easy.
As you stated:
"Optimal height" is mapped to XML_MIN_ROW_HEIGHT (pobably the minimal height)
"Optimal width" is mapped to XML_USE_OPTIMAL_ROW_HEIGHT (width and height mixed up?)

In Comment 16 Matthew Francis found out, that Daniel Bankston did some startup improvement to Calc as a Google Summer of Code (GSOC) 2012 job, mentored by Kohei Yoshida and Markus Mohrhard (who is still active on the developer list).

It seems that his hack omitted recalculation of row height even if the flag the flag "style:use-optimal-row-height" is set to "true". If it's just a wrong association between optimal and minimal height and width and height respectively, it should be corrected. I always thought that there might have been a performance issue to standard Calc files.

So if some developer might dig into it (or ask Markus for mentorship?), it would help us very much!

PS: I added your email to the CC list, so you get new mails too.
Comment 25 Tester 2017-04-23 02:17:21 UTC
Yes, i check the code my self, when i have seen that your first post was 2013... You wait a LONG time for a fix, so lite things can be so nasty.
I hope my speculation is right, and the mapping caused a wrong behavior, and a developer simply deactivated the defective update function. And that a skilled developer looks in to this soon.
(The code is not documented in comments, this makes it additional difficult for a "outside" developer to understand the logics. A "inside" developer can fix it maybe in minutes, if this is the bug.)
Such stubborn bugs are sometimes multiple bugs which makes a search hard, let as hope it is only this. (And never take out a red warning light, instead to fix the problem.)


I don't know jet where to reactivate the row updater. This are some related functions:

-> UpdateAllRowHeights
-> AdjustRowHeight
-> IsAdjustHeightEnabled (This can suppress the update. If(!) his only propose is to camouflage the bug, it could be deleted entirely.) 
	mbAdjustHeightEnabled EnableAdjustHeight
Comment 26 Tester 2017-04-23 04:13:34 UTC
((
This next here is somehow of topic and somehow related anyway. So i write it here, but it should not hinder the main discussion here!
I checked now even the OptimalColumnWidth functionality, in case of a bug relation with OptimalRowHeight.

Calc seams to entirely not support OptimalColumnWidth [style:use-optimal-column-width="true"]
- It don't stick with the column after manual use, it is not stored in column propertys.
- It is not stored in the file. 
- There seams to be no code for OptimalColumnWidth (No functions like UpdateAllColumnWidths, AdjustColumnWidth, ...?).
- This exists, but it seams it is never used(?):
	CMAP( "OptimalWidth",   XML_NAMESPACE_STYLE,    XML_USE_OPTIMAL_COLUMN_WIDTH,   XML_TYPE_BOOL, 0 ),

Is this a TODO, or is this specification of the ODS format intentional not supported?
It could be useful for columns which for example have only short values, or same length IDs, or 1 Charakter marks. The problem is the same, a outside generator can not know the optimal width of a column.
Even if OptimalRowHeight is more common and important, OptimalColumnWidth should be supported too, i think.
Should i write a feature-request/bug-report, or there will be no support for OptimalColumnWidth [style:use-optimal-column-width="true"] in the future?

! But, OptimalRowHeight by file load should be fixed first, before somebody look in to this OptimalColumnWidth issue!
))
Comment 27 Tester 2017-05-30 16:56:15 UTC
5.3.3.2 still has the bug.
Is here really no interest to fix this bug?
This bug makes it specially for professionals difficult, which generate ODS in code.
2013 .... to be honest, this is disappointing.

Just compare the last working version with the first buggy version to finde the changes in the critical area can not be so difficult.
(Use the Version infos from Bernhard Dippold)
Comment 28 Svante Schubert 2017-08-17 10:43:08 UTC
Created attachment 135612 [details]
Testdocument showing that row height is not being corrected by LO to display large text

I might simplify the test case by adding a Hello World calc document.

I created a small test spreadsheet with LibreOffice doing a hello world with hello in a cell in one row and world in the next row with a very high font (see document attached).
After saving the document with LibreOffice, I manually removed the explicit row hight on the second row with the high font text.
The row has after reload the same row height as any other rows and the content with the high text font vanished.
This happens for latest MS Office as well, but works with OpenOffice.org.
Comment 29 Svante Schubert 2017-08-17 10:44:20 UTC
As you see, this issue blocks to view any automated generated calc documents with larger cell content.
Comment 30 Adam 2018-02-15 11:30:16 UTC
This is still an issue in LibreOfficeCalc 6.0.

Like others, I generate ods files externally to LibreOfficeCalc with a custom database export script. I generate the all the necessary xml files, the mimetype and add png files. I carefully zip it all up to get a compliant ods file.

As stated before, it is not possible during generation to know the row height in order to set it in the xml. (Or rather it would require duplicating the current LibreOfficeCalc auto row height calculation code based on content, font, kerning, padding, size etc)

Opening the file in Excel, everything looks good.
Opening the file in LibreOfficeCalc6, all rows are at their default heights.

It is a problem, since users run the exporter themselves to create the ods, and expect it to look correct when opening it. Getting them to run a macro is not a solution.

It seems that the algorithm from Bernhard Donaubauer should be sufficient:

a) if there is no height attribute and the "use_optimal-row-height" attribute is set then calculate the row height

b) if there is no height attribute and the "use_optimal-row-height" attribute is not set then use the default value

c) if there is a height attribute just use it

If that is not possible, could a new custom xml attribute be introduced and used to trigger row height recalculation on file open? Then we can just add that to the xml. I don't care if it is stripped back out on save, since then the height will be set anyway.

Regards,
Adam
Comment 31 dumischbaenger 2018-02-21 10:44:48 UTC Comment hidden (me-too)
Comment 32 Commit Notification 2018-06-07 22:48:15 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1e55a47e89a9d9d6cf9cb3993484022aaf2c097b

tdf#62268: allow row height recalculation on document load

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 33 Xavier Van Wijmeersch 2018-06-08 18:19:30 UTC
its working with home build 2018-06-08

Version: 6.2.0.0.alpha0+
Build ID: 5708534b942c1d0ce384f6a8473da6bb569410e7
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 34 Timur 2018-06-18 16:14:48 UTC
*** Bug 69745 has been marked as a duplicate of this bug. ***
Comment 35 Commit Notification 2018-10-22 21:31:42 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=693953dd4699887bd3f5bca2c3582b5fae1d6992&h=libreoffice-6-1

tdf#62268: allow row height recalculation on document load

It will be available in 6.1.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 36 Kilian 2019-02-13 16:06:38 UTC
Hello,

I ran into a similar problem and found this thread.

I tested the given example "Small Calc document where line wrap in cell A4 should cause recalculation of row height".

LibreOffice 3.3 --> It worked
LibreOffice 6.2.0.3 --> Doesn´t work
LibreOffice 6.2.1.0 --> Doesn´t work

So I don´t know if the issue is really fixed.
Comment 37 Xisco Faulí 2019-03-13 18:50:08 UTC
(In reply to Kilian from comment #36)
> Hello,
> 
> I ran into a similar problem and found this thread.
> 
> I tested the given example "Small Calc document where line wrap in cell A4
> should cause recalculation of row height".
> 
> LibreOffice 3.3 --> It worked
> LibreOffice 6.2.0.3 --> Doesn´t work
> LibreOffice 6.2.1.0 --> Doesn´t work
> 
> So I don´t know if the issue is really fixed.

Dear Kilian,
This bug has been in RESOLVED FIXED status for more than 3 months.
If the issue is still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/, please report a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if     needed, the steps and documents to reproduce it.
Thanks for your understanding and collaboration.
Closing as RESOLVED FIXED