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.
CCing Calc expert from https://wiki.documentfoundation.org/FindTheExpert. Please comment and set status accordingly.
(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.
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.
@Thorsten/Markus - can we mark this as NEW & prioritize?
(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)
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.1 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
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