Download it now!
Bug 119377 - Table text replaced by '0' on applying AutoFormat Style and re-opening document
Summary: Table text replaced by '0' on applying AutoFormat Style and re-opening document
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Keywords: dataLoss
Depends on:
Blocks: Table-AutoFormat
  Show dependency treegraph
Reported: 2018-08-20 03:35 UTC by sirgillem
Modified: 2020-03-10 09:38 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Example file (13.84 KB, application/vnd.oasis.opendocument.text)
2018-08-20 14:29 UTC, Telesto
Example file (9.88 KB, application/vnd.oasis.opendocument.text)
2018-08-20 18:26 UTC, Telesto
WRN Screenshot - three tests. (183.75 KB, image/png)
2018-11-29 02:03 UTC, Walter Nicholls

Note You need to log in before you can comment on or make changes to this bug.
Description sirgillem 2018-08-20 03:35:54 UTC
After applying an AutoFormat Style to a table containing data then saving and re-opening the document, some cell data is replaced by '0'.

Steps to Reproduce:
1. Create a new ODT document in LibreOffice Writer
2. Select Table -> Insert Table
3. Create a table with 4 rows and 4 columns
4. Put the following data into the table:
Section Step Description              Action
1.1.2   2    The bar was fooed.       Unfoo the bar.
1.3.4   3    Lorem ipsum sit dolor.
1.4.5   1    Fizz buzz fizz fizzbuzz. None
5. Save the document.
6. Close and re-open the document.
7. Go to Table -> Autoformat Styles.
8. Select 'Simple Grid Rows' and press 'OK'.
9. Save the document.
10. Close and re-open the document.

Actual Results:
Text in the table body in columns 3 and 4 has been replaced by '0'.

Expected Results:
Text remains as originally entered.

Reproducible: Always

User Profile Reset: No

Additional Info:
Not all text is always replaced by '0' - some is left unmodified. I am not sure what causes this, but it seems that it only occurs in rows where column 4 contains text which is not 'None'.

The bug does not appear to occur if a table autoformat style is applied to the table before entering any text in the table body.

Copy of the About LibreOffice window:
Version: (x64)
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: en-AU (en_AU); Calc: CL
Comment 1 Telesto 2018-08-20 14:29:06 UTC
Created attachment 144331 [details]
Example file

Build ID: c958f52b813d34baa9b5236bb34a08a04e6b0aba
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-08-10_05:06:44
Locale: nl-NL (nl_NL.UTF-8); Calc: threaded
Comment 2 Telesto 2018-08-20 17:56:06 UTC
Repro with
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 3 Telesto 2018-08-20 18:26:31 UTC
Created attachment 144334 [details]
Example file

Proper example file
Comment 4 Mamoth 2018-10-09 08:19:04 UTC
I just filled bug 120437, which seems similar.
Comment 5 Mamoth 2018-10-09 15:52:57 UTC
Bug also appears for me with LO under Linux.
Comment 6 kevin 2018-11-15 12:44:40 UTC
Same problem here.

Created a table in a report, Formatted into the "academic" style, saved the report and the next day when I opened it all the text data had been converted to 0. Numeric data was OK. Actually some have been replaced by a space and a zero and some by a zero.

Changing the formatting of those boxes did not help.

I hacked into the content.xml file and the data is still there. If I open in Abiword my table had all the original the data wasn't deleted, just rendered as zeroes

Currently if I save and open the data is OK. But if I reformat as "academic", save and open the text has gone again.
Comment 7 kevin 2018-11-15 12:47:20 UTC
Tested on:
Build ID: 1:6.1.3-1
CPU threads: 3; OS: Linux 4.18; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); Calc: group threaded
Debian Buster
Comment 8 Walter Nicholls 2018-11-29 02:03:13 UTC
Created attachment 147112 [details]
WRN Screenshot - three tests.
Comment 9 Walter Nicholls 2018-11-29 02:08:40 UTC
Reproduced (or discovered anew).
Build ID: 1:6.1.2-0ubuntu1.1
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: en-NZ (en_NZ.UTF-8); Calc: group threaded

Seems to me that it definitely happens when the top-left cell of the table contains only a number or number-like text, but I won't say that is the only one. 

I did a couple of tests, screenshot attached. 

If this loss-of-information bug has been around since LO 4.4 I'm astonished it wasn't found earlier. This probably shows noone in their right mind used table autoformats!
And Table Styles .. were supposed to be a feature point for LO 6 but just seem to have added a new set of bugs on top of a flaky foundation!

I guess this is a "format this cell as a number" thing, so the underlying text effectively evaluates to zero

To add insult to injury, I can't find any reasonable way to get the text back.
  - setting number format to "Text" (format code @) intead of General doesn't work
 - you can't remove a table style - either from the table (no UI for that) or delete the style completely
Comment 10 Telesto 2018-11-29 08:04:11 UTC
@Jim, I thought you could be interested in this issue...
Comment 11 kevin 2018-11-29 10:28:10 UTC
I agree that trying to reformat the text does not bring it back - but the text has not gone. Its just rendered wrong.

Take the example doc above, open, autoformat and select "academic", save and re-open. The table has a lot of data replaced by zero. Now open the same file using Abiword - the table renders correctly.

So for some reason Libreoffice is rendering the content.xml differently than Abiword.

If you don't have Abiword just unzip the file and look at the content.xml file - the text is all there.
Comment 12 QA Administrators 2019-11-30 03:39:08 UTC Comment hidden (obsolete)
Comment 13 Roman Kuznetsov 2020-03-10 09:38:46 UTC
still repro in

Версия: (x64)
ID сборки: 41177730421f9be9ad955766a5a19667d8003b11
Потоков ЦП: 4; ОС: Windows 10.0 Build 18362; Отрисовка ИП: по умолчанию; VCL: win; 
Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU
Calc: threaded