Download it now!
Bug 131025 - Writer document with tables lost data in cells (apparently) replacing with 0
Summary: Writer document with tables lost data in cells (apparently) replacing with 0
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, dataLoss, regression
: 131904 (view as bug list)
Depends on:
Blocks: Writer-Tables 106322
  Show dependency treegraph
Reported: 2020-02-29 11:54 UTC by asuntoswebpablo
Modified: 2020-04-05 14:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

A document with table with data. It shows 0 in cells if the bug in tha application exists. (28.13 KB, application/vnd.oasis.opendocument.text)
2020-02-29 11:57 UTC, asuntoswebpablo

Note You need to log in before you can comment on or make changes to this bug.
Description asuntoswebpablo 2020-02-29 11:54:58 UTC
After saving an OpenOffice Write document (.odt) that have tables, and openin the same document with the OpenOffice Writer again is apparent that numerous data in the cells are replaced by the '0' character (one each cell) losing the content.
In reality the data is here (I was able to recover it opening the document with Windows WordPard) but the fright is great.

Steps to Reproduce:
1.Open the file that I will send with the bug report

Actual Results:
Majority of the cells on tables show 0

Expected Results:
They must show the data that I wrote in them.

Reproducible: Always

User Profile Reset: No

Additional Info:
I will attach a file that when is opend show the bug, but if is opened with WordPad it is clear that data is here. I am now using rtf format to save those texts and tables in LibreOffice and in this fileformat I am not havin that problem.
Comment 1 asuntoswebpablo 2020-02-29 11:57:25 UTC
Created attachment 158273 [details]
A document with table with data. It shows 0 in cells if the bug in tha application exists.
Comment 2 Roman Kuznetsov 2020-02-29 21:08:05 UTC
no repro from scratch. Table has the same data after saving and reopening
Comment 3 Oliver Brinzing 2020-03-01 07:44:48 UTC
reproducible with:

Version: (x64)
Build ID: f2db813374b8d65e1edec1387fa0c534b40885e1
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

steps to reproduce:

- new writer document
- insert a table
- format cell A1: #.##0,00
- insert text: Hello
- save & reload document
- cell A1 has format: @
- format cell A1 again: #.##0,00
- save & reload document
-> A1 has value 0,00
Comment 4 Oliver Brinzing 2020-03-01 07:54:54 UTC
reproducible with:

Version: (x64)
Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: 

and with:

Version: (x64)
Build-ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU-Threads: 4; BS: Windows 6.19; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: single

the cell value will change immediatelly after reformat - a second save & reload cycle is not necessary
Comment 5 Oliver Brinzing 2020-03-01 09:51:13 UTC
> - format cell A1 again: #.##0,00
> - save & reload document
> -> A1 has value 0,00

also reproducible with:

Version: (x64)
Build-ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: 

> the cell value will change immediatelly after reformat - a second save & reload > cycle is not necessary

same with

Version (Build ID: e183d5b)
AOO 4.1.5
Comment 6 Oliver Brinzing 2020-03-01 12:33:42 UTC
This issue seems to be a regression from tdf#106322. As mentionied above, changing the cell format immediatelly changed cell content to "0". With tdf#106322 now cell value is kept, but after a save & reload cycle the cell value changes to "0".

content.xml after changing cell format:
<table:table-cell table:style-name="Table1.A1" 
                  office:value-type="float" office:value="0">
  <text:p text:style-name="P1">Hello</text:p>

commit	acf7e4c0a3dc0cca986bf4d4b7a65bafe7e70abc	[log]
author	  Eike Rathke <>	Fri Dec 01 19:46:45 2017 +0100
committer Eike Rathke <>	Fri Dec 01 20:05:50 2017 +0100
tree	ae49d7b966f3229caffe4642bf0f3acccde691ca
parent	350eec67a5989365560e38e9270990dcd0a019e8 [diff]

Resolves: tdf#106322 keep original cell content when assigning number format
... and content can't be parsed as number. Instead of converting 0.
Change-Id: Ief0c0a0284762fc0e801d6cc598720a97d733e31

$ git bisect good
473fa5e7649113f1fbdded753cd7ea961fdf2de6 is the first bad commit
commit 473fa5e7649113f1fbdded753cd7ea961fdf2de6
Author: Norbert Thiebaud <>
Date:   Tue Dec 12 00:24:31 2017 -0800
    source sha:acf7e4c0a3dc0cca986bf4d4b7a65bafe7e70abc
    source sha:acf7e4c0a3dc0cca986bf4d4b7a65bafe7e70abc

:040000 040000 e2d939849e4bb08597fb9e76a7f43c5f4e85bdd5 7c628f65d132cafb24a544a1f75f6788529f9cc7 M      instdir

$ git bisect log
# bad: [75d131082ce51ed5a898d97bdc2b7a9fe5ddb340] source sha:5b3765f4d881e7ddefd0c4aad6886a46f000b4fc
# good: [29d08f54c2f71ffee4fe12dbb24c5f5cbedecfd2] source sha:6eeac3539ea4cac32d126c5e24141f262eb5a4d9
git bisect start 'master' 'oldest'
# bad: [6227e15df9be101688e37cd891817cd858b49e03] source sha:b8b7f8a8f8d97088181d287bb75e74facece16c6
git bisect bad 6227e15df9be101688e37cd891817cd858b49e03
# bad: [f73e8407e9dd38ee6588002e02c30e29880abdca] source sha:27938e1bbd5f3405c47b9933be7489eeb03920f3
git bisect bad f73e8407e9dd38ee6588002e02c30e29880abdca
# bad: [9fc78e2f29e8823251694faba1a762cfc347fcb8] source sha:4f0a97a81dc9aa93dd6579590110a1ea71154351
git bisect bad 9fc78e2f29e8823251694faba1a762cfc347fcb8
# bad: [e451888cda13c56f0cfac959ffeeef3661f1bd83] source sha:c9904bdd5bf2645c9723a8135c5fbceadb6b9aed
git bisect bad e451888cda13c56f0cfac959ffeeef3661f1bd83
# good: [ac768805b7c0d6149638a7c0ee956a52b6b683e6] source sha:bb1fd2c9819d1ee5ba26c181d8fea8272b89b673
git bisect good ac768805b7c0d6149638a7c0ee956a52b6b683e6
# bad: [7e30547f5641156a964354b0bb75b98b66f346f9] source sha:aa0b08980aba7bc82ab75151129b0c643cde7dfa
git bisect bad 7e30547f5641156a964354b0bb75b98b66f346f9
# bad: [1012ee5cf876d567f685bf78c573a5127105b82a] source sha:fdd63585a802e158abb06aa9b87fad2635db5103
git bisect bad 1012ee5cf876d567f685bf78c573a5127105b82a
# bad: [a8a1a1814262b63b2932152335f6d4a19caa9bd6] source sha:aeff59771431dd273159c767080b3db0a4f93565
git bisect bad a8a1a1814262b63b2932152335f6d4a19caa9bd6
# good: [b3c6edc5b5075ca456b179d715204bcc553a8cc7] source sha:1d44bcf18712d899f9e53676b9bc54ddc88147eb
git bisect good b3c6edc5b5075ca456b179d715204bcc553a8cc7
# good: [3ad46a7e29451f573c2209617b0c00e354530922] source sha:dccfe8765c25caf8485e659711a6df6c43ed63a9
git bisect good 3ad46a7e29451f573c2209617b0c00e354530922
# bad: [5af3bd7d2c3a45cc0312ad713a099e3451efdbb2] source sha:ae745789704fd7ad86c84ff9875cda810ff915b0
git bisect bad 5af3bd7d2c3a45cc0312ad713a099e3451efdbb2
# bad: [473fa5e7649113f1fbdded753cd7ea961fdf2de6] source sha:acf7e4c0a3dc0cca986bf4d4b7a65bafe7e70abc
git bisect bad 473fa5e7649113f1fbdded753cd7ea961fdf2de6
# good: [ca79be85102959ed6c455b05683f68728506432c] source sha:350eec67a5989365560e38e9270990dcd0a019e8
git bisect good ca79be85102959ed6c455b05683f68728506432c
# first bad commit: [473fa5e7649113f1fbdded753cd7ea961fdf2de6] source sha:acf7e4c0a3dc0cca986bf4d4b7a65bafe7e70abc
Comment 7 Mike Kaganski 2020-03-02 11:47:03 UTC
The problem is when a cell has a structure like this:

> <table:table-cell table:style-name="Table1.A1" office:value-type="float" office:value="0">
>     <text:p text:style-name="P1">Some Text</text:p>
> </table:table-cell>

In this case, the value of the cell is 0, but the contents is "Some Text" textual string.

When import filter calls SwTableBox::ActualiseValueBox(), this sees that the value 0 formatted using the number format gives a string different from "Some Text", and replaces it.

Questions are:
1. Why it doesn't happen if using Standard number format?
2. What does standard say about such cases?
3. How should Writer tell if normalizing should or should not happen: say, in a document using "default" language; in case when a cell contains a formatted numeric text, using, e.g., en-US format, and the document is opened in Russia, the new formatted text would also be different, but in this case the change is legitimate.
Comment 8 Mike Kaganski 2020-03-02 11:51:52 UTC
So two problems here:

1. How should Writer open existing documents with such data
2. It should *not* generate such data itself as shown in comment 3. If the data is textual, it must not write cell value type "float".
Comment 9 Oliver Brinzing 2020-04-05 14:49:27 UTC
*** Bug 131904 has been marked as a duplicate of this bug. ***