Bug 37063

Summary:	importing docx loses table in header/footer
Product:	LibreOffice	Reporter:	Stephan Zietsman <sziets>
Component:	Writer	Assignee:	Miklos Vajna <vmiklos>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	gleppert, j_m_hjelm, sziets, sziets, vmiklos
Priority:	medium
Version:	3.3.2 release
Hardware:	Other
OS:	All
Whiteboard:
Crash report or crash signature:		Regression By:

Description Stephan Zietsman 2011-05-10 04:03:58 UTC

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

Comment 1 gleppert 2011-05-10 09:45:50 UTC

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.

Comment 2 gleppert 2011-05-10 09:50:35 UTC

Sorry, I wanted to write in my previous post: I can confirm the bug concerning export/import problems of .docx, exactly like described.

Comment 3 Noel Power 2011-05-10 12:53:58 UTC

I will try to have a look at it

Comment 4 İbrahim Özgür Erişen 2011-12-22 10:22:33 UTC

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.

Comment 5 Mikael Hjelm 2012-06-15 02:13:19 UTC

Changed to all platforms since this has been confirmed on Linux

Comment 6 Mikael Hjelm 2012-06-15 04:25:26 UTC

Could anyone give a quickstart as to where i should look. This bug is killing me and i want to get rid of it.

Comment 7 Noel Power 2012-06-18 01:34:49 UTC

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.

Comment 8 Miklos Vajna 2012-06-18 01:38:33 UTC

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 ***