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: All 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-07-04 12:35 UTC (History)
5 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
Comment 14 Justin L 2020-07-03 11:17:26 UTC
(In reply to kevin from comment #11)
> I agree that trying to reformat the text does not bring it back - but the
> text has not gone. Its just rendered wrong.
This is true with one major caveat - if you save the file again in LO, the text is gone.

Confirmed with bibisect that this was a problem since at least LO 3.5. In earlier versions, this zeroing out happened immediately and not just after the reload.

There was a change in default styles (in bibisect) between 6.0 master (3D style for example) and 6.1 oldest (acaedemic style for example). But I didn't see a code commit in that 3 day window to account for the change.

Initially, the zeroing out didn't happen with these new styles. That started happening between bibisect 6.2master and 6.3 oldest. Again, I didn't see a code commit in that 5 day window to account for the change. (What is going on here!!)
Comment 15 Justin L 2020-07-03 17:00:08 UTC
I cannot reproduce in my two locally compiled situations, but I can reproduce with bibisect-linux-64-7.1. That is frustrating.
Comment 16 Justin L 2020-07-03 17:15:31 UTC Comment hidden (no-value)
Comment 17 Justin L 2020-07-03 18:37:56 UTC
In bibisect 6.4 and above, removing the user profile seems to fix the problem. Only throughout all of bibisect 6.3 can I reproduce the problem.
Comment 18 Justin L 2020-07-04 09:07:10 UTC
The 6.0 patch for similar-sounding bug 106322 might be helpful.
Comment 19 Justin L 2020-07-04 10:35:54 UTC
I can't really do any development on this because I can't properly reproduce it in bibisect or in my compiled environment.  I CAN reproduce it in my normal Ubuntu install, even after deleting the user profile.  (normally deleting the user profile fixes the problem in compile/bibisect).
Comment 20 Telesto 2020-07-04 12:35:42 UTC
The relevant info/ including some bibisects are nicely distributed over multiple bugs... so this might help a little.. 
Bug 131025 
Bug 133611
Bug 133660 

It's consistent on Windows, using bug 133611 comment 5 (even in safe mode)

Disabling numbering formatting 'solves' the issue, except you need to do some additional steps, see bug 133198