If a *.docx file has a table in the header/footer, Writer discards the table (the information in the table is not lost). -= To reproduce =- Open new text document (File -> New -> Text Document) Insert a header (Insert -> Header -> Default) Insert a default 2x2 table (Insert -> Table -> OK) In the table, insert some data: Left top cell: A1 Right top cell: B1 Left bottom cell: A2 Right bottom cell: B2 Save the file as a "Microsoft Word 2007 XML (*.docx)". Close Writer Open the saved file in Writer Expected result: 2x2 table in header with data in each cell Actual result: Table is missing, the data remains (without table structure) -= End of reproduction =- I specifically think this is an importing issue, rather than an exporting issue because: 1. MS Word 2007 opens the docx file correctly (table is present in header as expected) 2. Creating a *.docx file in MS Word 2007 with a table in the header exhibits the same behaviour as described (I.e. opening the file in LibO loses the table) -- LibreOfficePortable 3.3.2 (as from portableApps.com) Windows 7 Professional 64-bit LibreOffice 3.3.2 OOO330m19 (Build:202) tag libreoffice-3.3.2.2
Tested bug description on my system. I can confirm the export/import of docx, exactly like described. Additionally, I tried to save in LO the file to .doc and open the .doc file again in LO. This time, everything looks fine. The table with values is there in the heading. Hence, it seems to be really a problem with the docx import filter. System: Ubuntu 10.10/Gnome 2, LibreOffice 3.3.2 PPA, German UI, Intel 32-Bit.
Sorry, I wanted to write in my previous post: I can confirm the bug concerning export/import problems of .docx, exactly like described.
I will try to have a look at it
I also have this bug Sabayon Linux libreoffice 3.5.0 libreoffice 3.4.4 It is somehow important bug for me, hence all the QA dept uses tables in the headers and I was not able to open these documents.
Changed to all platforms since this has been confirmed on Linux
Could anyone give a quickstart as to where i should look. This bug is killing me and i want to get rid of it.
I am sorry, I did really mean to look at this ( as at the time I was looking going to look into something similar ) unfortunately I moved to look at other things and forgot about this bug. I release it here back to the default. Also I cc Miklos here who might have a better idea (In reply to comment #6) > Could anyone give a quickstart as to where i should look. This bug is killing > me and i want to get rid of it. iirc all the table import handling is mainly performed in writerfilter/source/dmapper/DomainMapperTableHandler.cxx & writerfilter/source/dmapper/DomainMapperTableManager.cxx and also TablePropertiesHandler.cxx I don't recall too much of the detail about the import ( it's been quite a while since I looked at anything to do with docx ) but I think DomainMapperTableManager::endOfRowAction() might be a place to start, I seem to recall that the table is built row by row. Sorry I'm not much more help. Might be worth asking some questions on the dev list too.
Sorry, I did not notice this bug, but I had the same issue in bug 49659. Already fixed in master and -3-6, and soon in -3-5. *** This bug has been marked as a duplicate of bug 49659 ***