Bug 53992 - FORMATTING MS-COMPAT: Handling of fo:wrap-option and sequential <text:p> elements
Summary: FORMATTING MS-COMPAT: Handling of fo:wrap-option and sequential <text:p> elem...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: ODF-export-invalid
  Show dependency tree / graph
 
Reported: 2012-08-24 08:13 UTC by Nicholas Shanks
Modified: 2022-09-13 03:33 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Shanks 2012-08-24 08:13:21 UTC 
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.
Comment 1 bfoman (inactive) 2013-03-14 14:01:35 UTC 
CCing Calc expert from https://wiki.documentfoundation.org/FindTheExpert.
Please comment and set status accordingly.
Comment 2 Markus Mohrhard 2013-06-28 02:11:33 UTC 
(In reply to comment #0)
> 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.
> 

No. The spec does not specify the default behavior so actually both applications are correct.

I agree that we can export the wrap-options attribute unconditionally but it does not solve the problem that there are still documents and will be documents without that attribute.

@Thorsten: Is there a reason why there is no default value in the ODF1.2 RNG? I haven't found any default value definitions for optional attributes in the whole spec.
Comment 3 (unused account) 2013-06-28 20:16:05 UTC 
bugzilla-daemon@freedesktop.org wrote:
> @Thorsten: Is there a reason why there is no default value in the
> ODF1.2 RNG?
>
There are a few - let's please treat missing ones as a bug in the
spec.
Comment 4 Joel Madero 2013-09-09 03:27:12 UTC 
@Thorsten/Markus - can we mark this as NEW & prioritize?
Comment 5 Robinson Tryon (qubit) 2014-07-03 21:17:04 UTC 
(had a chat w/Markus)

Whiteboard: Remove 'NeedAdvice'
Status -> NEW

Thorsten -- could you please file a bug in the ODF issue tracker? (and link to it from here)
Comment 6 QA Administrators 2015-07-18 17:44:42 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2016-09-20 10:18:46 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2019-12-03 14:05:32 UTC Comment hidden (obsolete)
Comment 9 Regina Henschel 2020-09-12 14:34:28 UTC 
The property fo:wrap-option is defined by reference to chapter 7.15.13 in [XSL] in 20.230 ODF 1.3.
[XSL]= http://www.w3.org/TR/2001/REC-xsl-20011015/

And there you find, that the initial value is "wrap". LibreOffice defines no-where in the inheritance chain, the value of fo:wrap-option. So application, which relay on the initial value will wrap in cells. LibreOffice writes it only out in case of fo:wrap-option="wrap".

To avoid to write it out in all uses cells, fo:wrap-option="no-wrap" should be added to <style:default-style style:family="table-cell"> in styles.xml.

Tested with Version: 7.1.0.0.alpha0+ (x64)
Build ID: 1e0cfd5662d95cea84e80e4fe10d52c3b1101ae6
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL
Comment 10 QA Administrators 2022-09-13 03:33:33 UTC 
Dear Nicholas Shanks,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug