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: RESOLVED DUPLICATE of bug 131025
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: 2021-10-22 18:04 UTC (History)
8 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
Example file to reproduce the issue (14.83 KB, application/vnd.oasis.opendocument.text)
2021-02-05 07:55 UTC, Alkis Georgopoulos
Table Autoformat Style, Data Loss (12.92 KB, application/vnd.oasis.opendocument.text)
2021-05-10 21:29 UTC, Chandanathil P. Geevan

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 data...so 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
Comment 21 Alkis Georgopoulos 2021-02-05 07:55:09 UTC
Created attachment 169489 [details]
Example file to reproduce the issue

Same problem here; LibreOffice 6.4.6 on Ubuntu 20.04.

I'm attaching an example "bug119377.odt" file that always reproduces the issue for me, in case it helps in bisecting it.
Comment 22 Alkis Georgopoulos 2021-02-05 08:54:59 UTC
This is definitely related to the current locale.

I'm able to reproduce it with a new file in the Greek locale:
LANGUAGE=el LANG=el_GR.UTF-8 soffice

And unable to reproduce it with a new file in the English locale:
LANGUAGE=en LANG=en_US.UTF-8 soffice

BUT note that if when I created my own Academic (in Greek: Ακαδημαϊκά) style, it got saved somewhere in ~/.config/libreoffice, and by applying that specific style, I'm able to reproduce the issue in any new file and any locale.

ALSO note that my "Ακαδημαϊκά" style got saved in the "Example file to reproduce the issue" that I attached; so, by downloading that specific file, and applying my "Ακαδημαϊκά" style, any developer should also be able to reproduce it anywhere.
Comment 23 Alkis Georgopoulos 2021-02-05 09:44:31 UTC
And here's a workaround. Start LibreOffice in the English locale with:

LC_ALL=en_US.UTF-8 LANG=el_GR.UTF-8 soffice bad-file.odt

Then go to Table > Autoformat Styles, and rename or copy the styles you use according to the following rules:
 * Use only ASCII characters in the style names.
 * Do not use the stock style names. This is to avoid the style name getting translated when you switch back to your locale, e.g. Academic would get translated to Ακαδημαϊκά, which isn't ASCII.

Save the document and exit.

From then on, you'll be able to use LibreOffice in any locale, as long as you only use the English-named styles that you defined AND you never touch them again.

If you ever need to change your styles in the future, you'll need to launch LibreOffice using the English locale once more.
Comment 24 Alkis Georgopoulos 2021-02-05 10:15:33 UTC
Finally, an observation on why this happens, which might also help developers to pinpoint it:

Some areas in table autoformat styles are assumed to contain numbers.
For example, if I create the following table, then select it, then create a new table style with it, LibreOffice will auto-detect that the second column contains numbers:

| a | 1 |
| b | 2 |

Then, IF NOT using the English locale, whenever I try to apply that style, the second column in the tables where it's applied will be converted to numbers, and become zero.
Comment 25 Jeremy Whiting 2021-02-15 13:53:23 UTC
 Here is another observation.
 After reloading my document has a mixture of some table cells that have retained the functionality to render a cell with original text and some that do not.
 I will focus here on the cells that are working as expected. Describing what I did differently.
 The only user activity is when I pasted text into a table cell.
 For example pasting


 Notice the initial lower case character.

 Libre Writer detects this cell starts with a lowercase character. I suspect an auto correct function is applied to the cell converting the initial character to upper-case. It becomes


 The document is saved.

 Loading same the document again shows the cell as expected.


 That's the only cause for cells displaying as expected imo. 

 Whereas all cells that I manually reverted to lower-case are now displayed with "O" or "0". Reverting the auto correct function causes the defect identified in this ticket to activate.

 I hope this is of some use to narrow down and identify the root cause.

$ libreoffice --writer -version
LibreOffice 00(Build:2)
$ uname -a
Linux burtha-f33 5.10.13-200.fc33.x86_64 #1 SMP Thu Feb 4 14:54:51 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Comment 26 Chandanathil P. Geevan 2021-05-10 21:22:25 UTC
This problem is still there.
We know the exact sequence. Apply Table Autoformat Style > Save > Close file > Reopen >
Text in 2nd column to last and row-2 to last changes to Zero.
Ine user checked the XML file and noticed that the tags 'STRING' was getting replaced.

Save > Close > Reopen 
The change happens only when we reopen. 

I don't see the need to attach the file because only a video can show how it happens.
Comment 27 Chandanathil P. Geevan 2021-05-10 21:29:23 UTC
Created attachment 171837 [details]
Table Autoformat Style, Data Loss

Attaching - example file.
Comment 28 Justin L 2021-10-22 18:04:17 UTC

*** This bug has been marked as a duplicate of bug 131025 ***