If a cell contains a trailing space, the space is copied literally to the content of the <text:p> tag for the cell rather than being encoded as a <text:s/> tag: <office:document-content ...> ... <table:table-cell office:value-type="string" calcext:value-type="string"> <text:p><text:s/>spaces </text:p> </table:table-cell> ... </office:document-content> I'm not familiar with the ODS spec so I don't know whether a literal space is permitted in this context, but at least some versions of Excel seem to discard the space. (LibreOffice itself preserves the space without problems.) To reproduce, create a new Calc document, enter the text " spaces " in the first cell, and save as ODS.
I confirm the behaviour as mentioned by the bug reporter. I also confirm that this ods file when open in MSO 2010 the last space is not shown. But I am not sure whether this is a bug of LibreOffice or not. Adding keyword implementationError, needsDevEval. The ODF specification says: (http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part1.html#element-text_s) > The <text:s> element is used to represent the [UNICODE] character “ “ (U+0020, SPACE). > > This element shall be used to represent the second and all following “ “ (U+0020, SPACE) characters in a sequence of “ “ (U+0020, SPACE) characters. > > Note: It is not an error if the character preceding the element is not a white space character, but it is good practice to use this element only for the second and all following “ “ (U+0020, SPACE) characters in a sequence.
@Regina, Do you have any insight here?
I have no strong opinion yet. Whitespace handling is still an issue in the TC, see OFFICE-3706 and OFFICE-3828
The description of <text:s> has, "This element shall be used to represent the second and all following “ “ (U+0020, SPACE) characters in a sequence of “ “ (U+0020, SPACE) characters. In Version: 7.0.0.2 (x64) Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL I see the <text:s> element, if there are two spaces. I therefore think, that it is correct, that for one space no <text:s> element is used.
> The description of <text:s> has, "This element shall be used to represent the second and all following “ “ (U+0020, SPACE) characters in a sequence of “ “ (U+0020, SPACE) characters. As an initial issue, "shall be used to represent the second" does not imply "shall not be used to represent the first", so I don't think this is enough to resolve the question. Looking at the ODF 1.3 specification (https://www.oasis-open.org/committees/download.php/67566/OpenDocument-v1.3-part3-schema.odt): """ 6.1.2. White Space Characters Consumers shall collapse white space that occur in * a <text:p> or <text:h> element [...] Collapsing white space characters is defined by the following algorithm: [...] 5) Leading " " (U+0020, SPACE) characters at the start of the resulting text [...] are removed. """ I hope I haven't omitted any relevant points by accident, but by my reading of this algorithm, "<text:p> space</text:p>" should have the initial space removed and be parsed as the text "space" (5 characters), suggesting that Excel has the right of it and <text:s/> is required to correctly encode the leading space. Apologies for not doing the legwork on this in the first place, but reopening.
(I belatedly realize I filed the bug over _trailing_ rather than _leading_ spaces, but the same logic applies to trailing spaces.)
@Micheal: Can you please look at it? Problem is step 5) in the algorithm in section 6.1.2 (ODF 1.3 part3) compared to the description of <text:s> in section 6.1.3 (ODF 1.3 part3).
i think it's a bug in LO. the space before the end of the element must be written as text:s because: 5) Leading “ “ (U+0020, SPACE) characters at the start of the resulting text and trailing SPACE characters at the end of the resulting text are removed.
Dear Andrew Church, 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
Still present as of version 25.2.5.2.