Created attachment 48027 [details] Data loss in right column after saving correctly rendered .docx as .odt Problem: Data loss in right column after saving correctly rendered .docx as .odt. How to reproduce: * Please open the attached file in Writer. Writer correctly imports the .docx file. In the document you see two tables. In the right column of both tables, there are names of people. * Please save this document as .odt * Please open again this .odt-file * Result: The right column is gone. The names in this column are lost. It is strange that Writer can display it correctly, but cannot save it in the native file format. System: Ubuntu 11.04, Gnome2, LibreOffice 3.3.2 PPA, Intel 32-Bit, German UI
Reproduced with Ubuntu 10.04.2 x86 LO 3.4
still a problem in 3.4.1 and build from master (2011-07-06) Does anyone has the time to see if a similar problem occurs when working with a new/plain ODF file? Or what happens if (part of) the table(s) are copied to a clean ODF file? Tedious work, but very helpful. Thanks a lot, Cor
@Cor: I tried part of your testing scenario. Here are the results: First scenario: * I created an empty writer document * I opened attached file * I copied the second table and pasted it into the new writer document. I saved the new file, closed it and reopened it. -> Result: Same problem occurs as described in this bug entry. Second scenario: * I did exactly the same like described in the first scenario, but I chose "Paste Special" and "Formatted text RTF" when pasting the table to the new document. -> Result: The problem does not occur. There is no data loss. [Only the width of the first row is wrong compared to the original window, but there is no data loss]
Created attachment 48868 [details] clean new table in 3.4.1 thank you very much! So either it are properties of the table as such, or properties as given by MsWord. Creating such a table clean in Writer 3.4.1, closes and opens just fine. (Won't be able to do much the next weeks - sorry )
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Created attachment 55204 [details] simple table that demonstrated this problem
Reproduced in LibO 3.5.0 beta 1 Steps to produce test document in MSWord 2007: 0. Start MSWord 2007 1. Create table 3 columns and 2 rows 2. Select first 2 cells in first row 3. Right click them and select "Merge cells" 4. Save document
Still [Reproducible] with "LibreOffice 3.5.5.3. German UI/Locale [Build-ID: 7122e39-92ed229-498d286-15e43b4-d70da21] on German WIN7 Home Premium (64bit) Still a problem with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 3985521]" (tinderbox: W2008R2@16-minimal_build, pull time 2012-06-24) @Michael: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
On pc Debian x86-64 with master sources updated today, I reproduced the problem with the first attachment. I noticed these console logs during docx opening: warn:sw:20874:1:/home/julien/compile-libreoffice/libo/sw/source/core/table/swnewtable.cxx:2155: Different Line Widths warn:legacy.osl:20874:1:/home/julien/compile-libreoffice/libo/sw/source/core/doc/tblrwcl.cxx:3501: Line's Boxes are too small or too large warn:sw:20874:1:/home/julien/compile-libreoffice/libo/sw/source/core/table/swnewtable.cxx:2156: Line's Boxes are too small or too large repeated many times each and during odt export: warn:legacy.osl:20874:1:/home/julien/compile-libreoffice/libo/sw/source/filter/xml/xmltble.cxx:187: rows have different total widths warn:legacy.osl:20874:1:/home/julien/compile-libreoffice/libo/sw/source/filter/xml/xmltble.cxx:979: table and/or table information seems to be corrupted. both repeated a dozen times each.
(In reply to comment #9) > ... > repeated many times each > Forgot to say there was this trace 1 time: warn:legacy.osl:21063:1:/home/julien/compile-libreoffice/libo/oox/source/helper/storagebase.cxx:74: StorageBase::StorageBase - missing base input stream I tried too with Sasha's attachment, I also reproduced the problem, same kind of logs, got exactly this during export: warn:legacy.osl:21010:1:/home/julien/compile-libreoffice/libo/sw/source/filter/xml/xmltble.cxx:187: rows have different total widths warn:legacy.osl:21010:1:/home/julien/compile-libreoffice/libo/sw/source/filter/xml/xmltble.cxx:979: table and/or table information seems to be corrupted. warn:legacy.osl:21010:1:/home/julien/compile-libreoffice/libo/sw/source/filter/xml/xmltble.cxx:979: table and/or table information seems to be corrupted.
hi all, can you test with recent version of LibreOffice 3.6.3.1 I tested the file you posted here and it save correctly in ODT format, so if we can close this bug as fixed in upstream will be fine :D
In LibreOffice 3.5.4.2 Build ID: 350m1(Build:2) on Ubuntu, the problem is still there. Maybe, it is different in the 3.6.x line...
On pc Debian x86-64, I tested with 3.5, 3.6 and master branches, the 3 of them updated today with a brand new LO profile for each test, here are the results: master (future 3.7): OK 3.6: OK 3.5: KO
It works fine in LO 4. Thanks! I close it as RESOLVED->WORKSFORME