Bug 59275 - FILESAVE: table lost borders after save as DOCX
Summary: FILESAVE: table lost borders after save as DOCX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) rc
Hardware: Other All
: medium normal
Assignee: Pierre-Eric Pelloux-Prayer
QA Contact:
Whiteboard: bibisected40 target:4.1.0 target:
Keywords: regression
Depends on:
Reported: 2013-01-12 10:02 UTC by Mateusz
Modified: 2013-01-16 15:50 UTC (History)
3 users (show)

See Also:

LO40rc1 - table before and afer saved (63.48 KB, image/png)
2013-01-12 10:02 UTC, Mateusz

Note You need to log in before you can comment on or make changes to this bug.
Description Mateusz 2013-01-12 10:02:37 UTC
Created attachment 72897 [details]
LO40rc1 - table before and afer saved


For Michael Meeks' request [ https://bugs.freedesktop.org/show_bug.cgi?id=47594#c8 ] I split one big bug for a few smaller. This issue is related with 

Bug 59273 - FILEOPEN: Writer doesn't display all table cells in DOCX file [ https://bugs.freedesktop.org/show_bug.cgi?id=59273 ]

Bug 59274 - FILEOPEN: table in DOCX file is more narrower than it should be [ https://bugs.freedesktop.org/show_bug.cgi?id=59274 ]

I don't want upload many times the same files so I will include links from other bugs. 

Download source file, open it and compare with attachment [LO40rc1 - table before and afer.png]

Source file:

By the way. I opened docx in Word Viewer and it shows document without a certain borders too. So I thought FILESAVE filter works properly and maybe bug is in FILEOPEN filter. Please inspect this issue. 

This picture show how document should looks. 
Comment 1 z1949 2013-01-14 13:08:38 UTC
Could it be related to bug 59243?
Comment 2 Joel Madero 2013-01-14 16:26:37 UTC
I can confirm this behavior as a regression.

What I did:

Save attachment below on your local machine
Open file with 3.6
See that you have the right borders
Save file as .docx 
Re-Open file with 3.6
Still have good borders

Do all of above with version 4.0
first time you open the file, good borders
save & close
borders broken

Marking as:
New (Confirmed)
Normal (can prevent high quality work but there is a workaround, just reapply border and save as .doc)
High (up from default of normal because it is a regression and quite annoying, also you might not see that it's broken unless you explicitly reopen the file)

Comment 3 Joel Madero 2013-01-14 16:47:54 UTC
Here is the bisect, just a heads up there were A LOT of issues with this download, when I bisected I just looked for messed up borders. If the borders were right but something else was wrong, I said bisect good

8004efc7f77e76e1dc66eeb0fa7f2b9b2cf9cc05 is the first bad commit
commit 8004efc7f77e76e1dc66eeb0fa7f2b9b2cf9cc05
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon Dec 10 15:00:52 2012 +0000

    commit 9351d0e4181924c3f72be24081fc7af027aa41f7
    Author:     Xisco Fauli <anistenis@gmail.com>
    AuthorDate: Mon Sep 24 22:15:09 2012 +0200
    Commit:     Xisco Fauli <anistenis@gmail.com>
    CommitDate: Mon Sep 24 22:32:33 2012 +0200
        pywizards: get rid of import * (3)
        Change-Id: Ibf7c6fc7863b6eccb28e5396587f2ec00ffcbe43

:100644 100644 a20479cbaa3727d1fffd44cec83df218caf9dbf1 0863ab0e8be4a2ddafd9dddc93ab1fece1d3531d M	autogen.log
:100644 100644 8e62d282e044f8e50129bb22cdbced4b96ebd1ca b2f4fccbfb31eeecda38bcf1e8530f4bcfe6404d M	ccache.log
:100644 100644 9ba22c3c21c7391056a1da76ecacf80f29ab767e 644c844c8c7f37845bcd509b30274fb3171f1b19 M	commitmsg
:100644 100644 aab3b069871ff5609a47327ae064d422aee26bb8 079818d37a3d997fb0b0444f800def75421c0006 M	dev-install.log
:100644 100644 2555d139468d77b5f654500831df091744b86a6e 94f774aa4e04a6a7af6ef5a36b8bfdbd2a14b563 M	make.log
:040000 040000 46fa8a5acb8fc14c2eaa23b7adef44367c114fe6 9d835c4339fa31db59424d45d5ac26a83cbdc83b M	opt

# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
# bad: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect bad 114fd3b76bcba890e6d702d00cef910f1493c262
# good: [6af64581913aa7ce3fcf0890fe671830d416a6ea] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f
git bisect good 6af64581913aa7ce3fcf0890fe671830d416a6ea
# bad: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f
git bisect bad 7e20e241c1d8819d8d5edb7894baeddde33f9d3a
# bad: [18ab426f67674e3ca169118f1f7a3527613374a4] source-hash-4df639baacd871cb2793e75dd9721ad2ae715e20
git bisect bad 18ab426f67674e3ca169118f1f7a3527613374a4
# bad: [8004efc7f77e76e1dc66eeb0fa7f2b9b2cf9cc05] source-hash-9351d0e4181924c3f72be24081fc7af027aa41f7
git bisect bad 8004efc7f77e76e1dc66eeb0fa7f2b9b2cf9cc05
# good: [7441b1f8a21611cc64d2c1c9a455adafc1cf213c] source-hash-93effcb0a2eade8309c53b74d0ea22e8a2217661
git bisect good 7441b1f8a21611cc64d2c1c9a455adafc1cf213c
Comment 4 Joel Madero 2013-01-14 17:59:32 UTC
Whoever takes this one, if you have the time when you're digging into the code, here is another related issue:

Comment 5 Michael Stahl 2013-01-15 18:23:12 UTC
Joel, the bibisect in comment #3 isn't quite right, most likely
since it finds a different regression that also affects DOCX table
import (extra cells are inserted that incidentally don't have
borders; i know because i've introduced that regression :)

actually it seems the regression happened in the commit range:

which points at this commit:

commit 9751056ba806ba9614392f3c70ada3cbd1251814
Author: Pierre-Eric Pelloux-Prayer <pierre-eric@lanedo.com>
Date:   Thu Sep 27 17:00:08 2012 +0200

    docx export: export default table cell margins, based on 1st cell

furthermore don't trust Microsoft Word Viewer, i tried to use it
once to test borders and it displayed them completely differently
than Word 2010.
Comment 6 Pierre-Eric Pelloux-Prayer 2013-01-15 18:49:50 UTC
Just tested on master and indeed some borders are missing after export.

I'll try to get a look at this quickly.

Thanks for the bug report and the bisecting.
Comment 7 Pierre-Eric Pelloux-Prayer 2013-01-16 10:23:33 UTC
I pushed a fix for master (waiting for review for 4-0 branch).

@Mateusz : could I use your docx file to create a new unit test within LibreOffice ?
Comment 8 Not Assigned 2013-01-16 10:59:21 UTC
Pierre-Eric Pelloux-Prayer committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":


fdo#59275: docx export: fix regression on table borders export

It will be available in LibreOffice 4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 9 Michael Stahl 2013-01-16 11:11:01 UTC
fixed on master by 6819f9b834581acd5507cd2301bda8b5395b937d
Comment 10 Mateusz 2013-01-16 15:50:36 UTC
(In reply to comment #7)
> I pushed a fix for master (waiting for review for 4-0 branch).
> @Mateusz : could I use your docx file to create a new unit test within
> LibreOffice ?

Sure! Take it and use if it will be helpful.