https://bugs.freedesktop.org/show_bug.cgi?id=53992

             Bug #: 53992
           Summary: FORMATTING MS-COMPAT: Handling of fo:wrap-option and
                    sequential <text:p> elements
    Classification: Unclassified
           Product: LibreOffice
           Version: 3.6.0.4 release
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Spreadsheet
        AssignedTo: libreoffice-bugs@lists.freedesktop.org
        ReportedBy: nicksha...@nickshanks.com


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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to