Bug 76409 - FORMATTING: content.xml data differs
Summary: FORMATTING: content.xml data differs
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: Other All
: medium normal
Assignee: Kohei Yoshida
URL:
Whiteboard: BSA target:4.3.0 target:4.2.4
Keywords: possibleRegression, regression
Depends on:
Blocks:
 
Reported: 2014-03-20 17:10 UTC by Camaleón
Modified: 2015-12-15 22:10 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
"content.xml" sample outputs showing the difference bewteen 4.1 and 4.2 versions (15.53 KB, application/x-gzip)
2014-03-20 17:10 UTC, Camaleón
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Camaleón 2014-03-20 17:10:24 UTC
Created attachment 96115 [details]
"content.xml" sample outputs showing the difference bewteen 4.1 and 4.2 versions

Problem description: 
"content.xml" file contains different data from one LO version to the other

Steps to reproduce:
1. Create a new ods file with a number value on it (eg., "46,236589998745") and give the cell a format to fit your locale (mine "es_ES") so that it displays as "46,24".

2. Save the file and rename it as .zip to get the raw data

3. Now tag "<text:p>" contains "46,236589998745" instead "46,24" as it hapenned on older LO versions.

Current behavior: "<text:p>" contains the raw/unformatted data (see attached file)

Expected behavior: "<text:p>" should contains the formatted data (see attached file)

              
Operating System: All
Version: 4.2.0.4 release
Last worked in: 4.1.1.2 release
Comment 1 m_a_riosv 2014-03-20 22:16:47 UTC
Hola Camaleón, thanks for reporting.

Cell format never changes cell value, maybe in the older version you have activate the option Menu/Tools/Options/LibreOffice calc/Calculate - Precision as show.
Comment 2 Camaleón 2014-03-20 22:53:38 UTC
I don't think I had enabled (at least on purpose) any option for that, in fact, it was disabled when I tried on 4.1.1.2. 

Anyway, I have checked that option in 4.2.0.4, then saved the ods file and renamed as zip but it makes no difference in the resulting "content.xml", still shows the raw value but maybe I am missing something or doing it in the wrong way. Can you reproduce my results?
Comment 3 m_a_riosv 2014-03-20 23:05:55 UTC
As I have commented, doesn't matter how you change the cell format, the raw values remains inalterable.

For me in the <text:p> tag both versions (416 and 402) have "46,236589998745", the correct value.
Comment 4 Camaleón 2014-03-21 06:42:37 UTC
Well, that's weird. 

1/ Can you please, given the steps I provided above, create a new ODS file at your end and test with both LO releases (4.1.x and 4.2.x)?

2/ Is there any chance to get formatted data inside the <text:p> tag in "content.xml" instead raw data ?
Comment 5 m_a_riosv 2014-03-21 09:56:01 UTC
Sorry Camaleón, I had not format the cell with two decimal positions.

I have added another cell with a date for comparison and haven't clear what is the right.
4.1.6
<office:spreadsheet>
   <table:calculation-settings table:case-sensitive="false" table:automatic-find-labels="false"/>
   <table:table table:name="Sheet1" table:style-name="ta1">
    <table:table-column table:style-name="co1" table:default-cell-style-name="ce1"/>
    <table:table-row table:style-name="ro1">
     <table:table-cell office:value-type="float" office:value="46.236589998745" calcext:value-type="float">
      <text:p>46,24</text:p>
     </table:table-cell>
    </table:table-row>
    <table:table-row table:style-name="ro1">
     <table:table-cell table:style-name="ce2" office:value-type="date" office:date-value="2014-12-31" calcext:value-type="date">
      <text:p>31/12/14</text:p>
     </table:table-cell>
    </table:table-row>
   </table:table>
   <table:named-expressions/>
  </office:spreadsheet>

4.2.0
<office:spreadsheet>
   <table:table table:name="Sheet1" table:style-name="ta1">
    <table:table-column table:style-name="co1" table:default-cell-style-name="ce1"/>
    <table:table-row table:style-name="ro1">
     <table:table-cell office:value-type="float" office:value="46.236589998745" calcext:value-type="float">
      <text:p>46.236589998745</text:p>
     </table:table-cell>
    </table:table-row><table:table-row table:style-name="ro2">
     <table:table-cell table:style-name="ce2" office:value-type="date" office:date-value="2014-12-31" calcext:value-type="date">
      <text:p>42004</text:p>
     </table:table-cell>
    </table:table-row>
   </table:table>
   <table:named-expressions/>
  </office:spreadsheet>

Master save as 4.2.0
Aoo 4.0.1 save as 4.1.6

Not too much clear in ODF specification what content must be.
http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part1.html#element-table_table-cell
http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part1.html#element-text_p

Seems a bug, difficult to see because the cell format is applied immediately after open the file.
Comment 6 Kohei Yoshida 2014-04-14 16:12:15 UTC
What would be the real world use case where this change causes any impact?
Comment 7 Kohei Yoshida 2014-04-14 16:16:03 UTC
AFAIK, ODF is very vague about what should be in the <text:p> element.  It's mostly for "informational purpose" and it doesn't have much strict requirement.
Comment 8 Camaleón 2014-04-14 20:38:12 UTC
(In reply to comment #6)
> What would be the real world use case where this change causes any impact?

Well, having both values available (short and long numbers) saves me a lot of work. 

In my case, I get/download a MS Excel (.xlsx) file and then open it with LO to save it as ODT in order to extract the raw xml data (content.xml) that I then use inside html page with a stylesheet (xsl). 

If the resulting xml file contains both values (short and long numbers) I don't need to make additional formatting work to have the proper number displayed on the html page which is what it used to be. Now, in order to get readable numbers I have to use xsl formatting functions so the value is displayed as it should.

All in all, I consider an advantage to have both values (short and long numbers) in the xml file, because it allows a more flexible approach.
Comment 9 Kohei Yoshida 2014-04-15 14:09:56 UTC
Fair enough.  I'll fix it.  Looks like it was changed unintentionally anyway.

FYI, this bug has zero impact as far as loading ods in LibreOffice goes.  This one benefits for postprocessing of ODS documents via 3rd party ODF processing tools.
Comment 10 Commit Notification 2014-04-15 14:16:55 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a0752fa4246dc71b64907c679657a1af3cb617e1

fdo#76409: Write output cell string to <text:p> element when saving to ods.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 11 Kohei Yoshida 2014-04-15 14:22:05 UTC
4.2 backport: https://gerrit.libreoffice.org/9014
Comment 12 Commit Notification 2014-04-15 15:47:47 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=eec62f3d823048c9b3b767cb7de72650a40b73cd&h=libreoffice-4-2

fdo#76409: Write output cell string to <text:p> element when saving to ods.


It will be available in LibreOffice 4.2.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 Kohei Yoshida 2014-04-15 15:50:05 UTC
Fixed.
Comment 14 Robinson Tryon (qubit) 2015-12-15 22:10:22 UTC
Migrating Whiteboard tags to Keywords: (PossibleRegression)
[NinjaEdit]