Description: 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: 6.0.1.1 (x64) Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-AU (en_AU); Calc: CL
Created attachment 144331 [details] Example file repro Version: 6.2.0.0.alpha0+ 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
Repro with Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Created attachment 144334 [details] Example file Proper example file
Hi. I just filled bug 120437, which seems similar. https://bugs.documentfoundation.org/show_bug.cgi?id=120437
Bug also appears for me with LO 6.0.6.2 under Linux.
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.
Tested on: Version: 6.1.3.2 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
Created attachment 147112 [details] WRN Screenshot - three tests.
Reproduced (or discovered anew). Version: 6.1.2.1 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
@Jim, I thought you could be interested in this issue...
I agree that trying to reformat the text does not bring it back - but the text has not gone. Its just rendered wrong. Example: 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.
Dear sirgillem, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still repro in Версия: 7.0.0.0.alpha0+ (x64) ID сборки: 41177730421f9be9ad955766a5a19667d8003b11 Потоков ЦП: 4; ОС: Windows 10.0 Build 18362; Отрисовка ИП: по умолчанию; VCL: win; Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU Calc: threaded
(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!!)
I cannot reproduce in my two locally compiled situations, but I can reproduce with bibisect-linux-64-7.1. That is frustrating.
Too strange. It is related to the user profile. If I delete the user profile, then simply opening the file renders it properly.
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.
The 6.0 patch for similar-sounding bug 106322 might be helpful.
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 6.4.4.2 install, even after deleting the user profile. (normally deleting the user profile fixes the problem in compile/bibisect).
@Justin 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
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.
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.
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.
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.
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 "sendRequisitionToBuyer" 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 "SendRequisitionToBuyer" The document is saved. Loading same the document again shows the cell as expected. "SendRequisitionToBuyer" 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 7.0.4.2 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
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.
Created attachment 171837 [details] Table Autoformat Style, Data Loss Attaching - example file.
*** This bug has been marked as a duplicate of bug 131025 ***