One of either LO or Microsoft Excel is wrong here, but I don't know which. Without determining who is wrong and who is right, LO can implement a change which mitigates the problem.

In LO, two consecutive <text:p> elements in a string cell will appear as two lines with no additional formatting needed. In Excel, they appear concatenated with no whitespace between them, unless an fo:wrap-option="wrap" attribute is also present in the cell's style.

I have not checked the specs but I will presume that the default wrapping behaviour (i.e. the default value for fo:wrap-options) is not to wrap cell contents. Cells in spreadsheets normally just overflow in the x direction when their contents don't fit.

If the <text:p> object is, to use HTML parlance, block-level, then Excel is wrong, two p elements should progress in the block-level direction.
If the <text:p> object is inline-level, then LO is wrong and a fo:wrap-option value forcing wrapping is REQUIRED to create wrapping behaviour.
So can you both check the OpenDocument specs and see whether <text:p> is block or inline.


The code Excel spits out is correctly shown on two lines in both UAs (code excerpt below).
The code LO spits out is not shown correctly when opened in Excel (as below but without fo:wrap-option element).


<style:style name="ce0" style:family="table-cell">
  <style:table-cell-properties fo:wrap-option="wrap"/>
</style:style>

<table:table-cell table:style-name="ce0" office:value-type="string">
  <text:p>Line 1</text:p><text:p>Line 2</text:p>
</table:table-cell>


As a workaround, I suggest that LO emit a fo:wrap-option="wrap" attribute anyway, even if it turns out not to be necessary by the letter of the published spec, so that files saved by it can be opened in Excel 2007, 2008, 2010 and possibly future versions. I expect that this will mean cells containing text:p elements with contents wider than the cell will see wrapping within a text:p block, like this: (not verified)

+------------------+
|Line 1 Line 1 Line|
|1                 |
|Line 2            |
+------------------+

Rather than the overflowing first text:p being clipped, and the cell height being consequently smaller. I think this side-effect is reasonably acceptable given that the alternative is no line wrapping when opened in Excel.