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]
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.
Could it be related to bug 59243?
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
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)
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
Author: Bjoern Michaelsen <firstname.lastname@example.org>
Date: Mon Dec 10 15:00:52 2012 +0000
Author: Xisco Fauli <email@example.com>
AuthorDate: Mon Sep 24 22:15:09 2012 +0200
Commit: Xisco Fauli <firstname.lastname@example.org>
CommitDate: Mon Sep 24 22:32:33 2012 +0200
pywizards: get rid of import * (3)
: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
Whoever takes this one, if you have the time when you're digging into the code, here is another related issue:
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:
Author: Pierre-Eric Pelloux-Prayer <email@example.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.
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.
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 ?
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.
fixed on master by 6819f9b834581acd5507cd2301bda8b5395b937d
(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.