Bug 49255 seems to be similar to my problem, but as it has been reported and fixed previously, it must be different.

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.

Summary more nearby reporter's expectations

@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.

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)

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 ...

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

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.

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 ".

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 on attachment 77008 [details]
Small Calc document where line wrap in cell A4 should cause recalculation of row height

description corrected

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

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)

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

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?

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

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!

(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>

...

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

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?

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"].

Here a link where i assume the bug.
Check: getRowPropertiesMap -> OptimalHeight, OptimalWidth
https://docs.libreoffice.org/xmloff/html/XMLTableExport_8cxx_source.html#l00081

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.

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

((
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!
))

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)

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.

As you see, this issue blocks to view any automated generated calc documents with larger cell content.

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

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.

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

*** Bug 69745 has been marked as a duplicate of this bug. ***

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.

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.

(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

I copy the following comment from bug 128204, to raise everyone's consideration as the fix to this bug caused many serious regressions especially for performance when openning large (but not that large) ODF spreadsheet documents

------

ODF Spec.
'''
20.394 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. 
'''

Well, from this ODF standard, this attribute defines that the row height should be recalculated if the content in this row is changed (i.e., at the time of editing), rather than when the document is open. At time of editing when the row height is recalculated, a new row height value is determined and is saved to the ODF file.

At file open, the application should use the defined row height value directly rather than recalculating each of them. For all new ODF spreadsheet docs there is a defined row height for each row.

The rational of recalculating the row heights at file open as in the commit of bug 62268 is that for some mannully generated ODF files there is no row height value defined in the xml file, normally because those programs are not professional OpenDocument Producers and they simply want an ODF Viewer like Calc to calculate the row height for them when the file is open by the user. And I agree that in such case (if there is no defined row height value) Calc should help to recalculate.


So, consider both bug 62268 and the properly generated ODF filed, the fix should be:

if rowHeight and rowHeight>0:
    finalRowHeight = rowHeight
else:
    if useOptimalRowHeight:
        (recalculate row height)
        finalRowHeight = reCalculatedRowHeight
    else:
        finalRowHeight = defaultRowHeight

The improvement of the speed for the recalculation of row height is another issue. However, for large spreadsheets even the fastest calculation may still cost a lot of time and CPU circles as it need to loop into each row and each cell.

My suggestion above is actually the same as in comment 30, but the actual code in that commit did not consider whether there is a row height attribute.

During my active time in this community new informations in bugs marked as CLOSED FIXED have been constantly ignored.

If a bug is still reproducible, the bug report is to be reopened.

If the fix caused new problems, a new bug report had to be filed and linked to the closed report. This is the case here,I think.

So please find out, if anybody opened a new bug report with the problems caused by this fix - if not, file a new report on your own.

Just for the statistics: the bug fix didn't solve all the formatting problems in our files, so we're still on LO 3.5
(I have not been informed about the persistent problems, so I couldn't find a solution or file a new bug report)

(In reply to Bernhard Dippold from comment #40)
Yes, we have several regression bug open and even a meta bug. I am commenting here because this is the cause of such issues.

As you mentioned that commit did not resolve the promlem on your side, so there is a good reason to reverse that commit.

Even if the issue is not solved at my side (as they might be more and other problems), there are other users affected by the bug (see comment #12, comment #30, comment #36), so reverting it is not the solution.

LibreOffice is used as formatting tool for ODF files modified by other programs. In my experience they are specialized companies or groups I'd like to keep as LibreOffice users.

Even from ODF definition "change" doesn't exclude a document change outside the main program. 

So in my eyes the solution should be:
-add a general check, if the document had been changed since the last save with LO (perhaps there is such a flag already existing, perhaps time stamp of sub files might change?)
- if there was a modification, recalculate every cell with "style:use-optimal-row-height='true'"
- if the document is unchanged, just open it without recalculation.

The vast majority of files are unchanged, so performance stays fast...

(In reply to Bernhard Dippold from comment #42)
We may suggest a flag to be added in the ODF specification, but on case of no such flag it is a waste of time to recaculate. I don't think chrecking the timestamp is the proper way.

If the row had a row-height degined then simply use it, otherwise that attribute would be useless. It is the responsibility of that program to change the row height value into a correct if it modified the content of the file, and if it failed to do this then it is their fault. 
If external programs want certain rows to be recalculated then that program should explicitly remove the rowHeight attribue or set as zero, and LO then should recalculate the height for those rows. If LO encounter row without a row height attribute set, or the row height is zero, then it is LO's responsinility to recalculate, otherwise it is LO's fault.

Forcing recaculation for every spreadsheet for each row is a halm for most users who work on properly generated ODF, while benefit a few users whose ODF are not properly generated. Worse, it is wrong to rely on the style:use-optimal-row-height='true' attribute as this is is defined as "row height should be recalculated automatically if content in the row changes". Openning a doc does not mean such change. Change means changing its value, and such actibity already happened at the time when the external program edited the doc (but failed updating the row height value while expecting LO to update it relying on style:use-optimal-row-height='true' which makes no sense).

Who should decide this? Is a meeting or voting reqiured?

Real spreadsheets at work are normally with a lot of rows and columns with complex formulars. The openning of ODF docs should be quick. Note that XLSX docs fo not have such problem.

(In reply to Kevin Suo from comment #43)

Generally I support this. Just for completeness, one must not forget some special cases of "content change" that happen on open: e.g., opening the file in an environment with different locale: it may use different numbering system, separators, default decimals, etc.; or missing fonts, which results with substituting fonts and different text size in general. It is difficult to predict such situations. So when deciding, we should clearly state that in these cases, we know and expect that the layout may be unexpected, and that is normal and not a bug.

(In reply to Kevin Suo from comment #43)
> Forcing recaculation for every spreadsheet for each row is a halm for most
> users who work on properly generated ODF, while benefit a few users whose
> ODF are not properly generated. Worse, it is wrong to rely on the
> style:use-optimal-row-height='true' attribute as this is is defined as "row
> height should be recalculated automatically if content in the row changes".
>

I disagree. Calc does exactly what this style requires it to do. I suggest we don't re-litigate this bug report here, but instead discuss how to solve the wider issue elsewhere (perhaps even a stakeholder call would be great - I personally lost track of the many different places this was/is discussed).

> Calc does exactly what this style requires it to do

No, that is not the case. style:use-optimal-row-height='true' is defined as "height should be recalculated automatically if content in the row changes". Fileopen is not content change, no matter if the file is open readonly or in editing mode. Content change is changing the content in a cell (e.g. you type sth in the cell, or edit or delete the content in a cell). At the time when the cell has content change, a new row height is calculated and is stored in style:row-height, and is then used in the next fileopen. In this case, the recalculation is done each time for a single row, thus no one would notice it's slowness (the calculation finishes on the fly). Each row has a style:row-height in case the document is properly generated. If the row height need to be recalculated everytime on fileopen then the style:row-height is useless!

style:use-optimal-row-height='true' should only be used at the time when you edit a cell. Those cells with this attribute set to true (which is the default for every cell) need a recalculation of row height each time on cell content change (so that when you change the cell content the row height will adapt to the content). The program which produced the ODF document should be responsible to calculate the style:row-height both at the time when the cell is first filled with value or the content is changed. Those cells with style:use-optimal-row-height set to false will not have row height recalculation no matter how you change the cell content, so that style:row-height is always the old value, even on fileopen. 

style:use-optimal-row-height is not a flag indicating force recalculation of row height on fileopen. If you need that kind of flag, then you should request the ODF standard to defined one in the next specification.

Regarding the speedup of row-height recalculation speed, in my opinion there is little room to improve. Even if the technic is very good there is still a uneeded slowdown. Keep in mind that we are talking about large spreadsheets in working environment with millions or tens of millions of rows, not those simple spreadsheets with only several hundrands of rows.

(In reply to Kevin Suo from comment #43)
> If external programs want certain rows to be recalculated then that program
> should explicitly remove the rowHeight attribue or set as zero, and LO then
> should recalculate the height for those rows. If LO encounter row without a
> row height attribute set, or the row height is zero, then it is LO's
> responsinility to recalculate, otherwise it is LO's fault.


In one sentence: If use_optimal-row-height is set and row-height exists just use row-height otherwise calculate the row height.

This is by the way the algorithm I suggested in comment #12 in 2013. This solution would hurt _nobody_ and help people using in example an XML/XSLT tool chain as I did that time.

If LO now behaves that way everything is okay IMHO and I don't understand what's this dispute is about.

"style:use-optimal-row-height='true' should only be used at the time when you edit a cell" seems adequate to me. But 

B1. style:use-optimal-row-height='true' either does not appear in the user interface or is so non-intuitive to find that it effectively renders "automatic row height adjustment to wrapped text edits" inaccessible and effectively useless.
B2. Right-clicking on a row number and using the Optimal Row Height... menu item works only once. It does not resolve the lack of automatic optimal row height use when you edit a cell.

Generally in all versions of LibreOffice I can remember, there is no reliable automatic adjustment to optimal row height on edit. Specifically in v24.2.0.3, the following steps leave rows higher than wanted.

S1. In a new spreadsheet, add text on multiple columns of the same row.

S2. Edit the text on multiple columns to increase their number of lines to various lengths. Row height responsively increases repeatedly.

S3. Edit the text on the longer cells to decrease their number of lines.

S4. Row height does not responsively decrease. You must double-click between the row number and the row+1 number to adjust the row height to fit.

What can I do about this? Re-open this bug? File a new report? Keep searching bugs for the right one? This issue is so long-standing that the problem must be very sticky and related to design decisions in LO that don't exist in other spreadsheets (Excel and Google Sheets most recently). It makes me embarrassed to recommend LibreOffice to my colleagues.