Bug 98355 - Internal borders of tables that are removed re-appear in .docx files
Summary: Internal borders of tables that are removed re-appear in .docx files
Status: RESOLVED DUPLICATE of bug 82177
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: bibisected, regression
Depends on:
Reported: 2016-03-02 17:24 UTC by Fellype
Modified: 2016-03-29 17:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

.odt file with correct table formatations (8.85 KB, application/vnd.oasis.opendocument.text)
2016-03-03 13:03 UTC, Fellype
Corresponding .docx file with wrong table formatations (4.64 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-03-03 13:05 UTC, Fellype

Note You need to log in before you can comment on or make changes to this bug.
Description Fellype 2016-03-02 17:24:27 UTC
To reproduce this bug:

1 - create a table in Writer
2 - remove all borders of the table
3 - add back only the external borders
4 - save the document in .docx format
5 - close the document
6 - open the document

result -> many internal borders, specially the lines, re-appear in the table.

This bug affect versions 4.4.5 and newer.
Comment 1 Joel Madero 2016-03-02 21:20:45 UTC
Please attach a simple odt document and corresponding docx. Marking as NEEDINFO, once attached set to UNCONFIRMED.

In the future sample documents are *always* appreciated, our time is really stretched (the small contributor group) so the more you take off our plates, the more helpful the bug report is. Thanks for understanding.
Comment 2 Fellype 2016-03-03 13:03:52 UTC
Created attachment 123196 [details]
.odt file with correct table formatations
Comment 3 Fellype 2016-03-03 13:05:31 UTC
Created attachment 123197 [details]
Corresponding .docx file with wrong table formatations
Comment 4 raal 2016-03-04 20:32:14 UTC
I can confirm with  Version:
Build ID: aaca25d67eb5ea252730cdcf555ecc04ce04a5e6
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-02-24_23:58:47
Comment 5 Joel Madero 2016-03-29 01:46:20 UTC
Bodhi Moksha
LibreOffice 5.2


Major - loss of data (border data) that is irretrievable without an odt backup;
High - default + regression. 

Using discretion not to up this to highest, don't think it's appropriate in this case.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2bd7d7ecf3c6ff844c9b8febae4e9ccfea958837 is the first bad commit
commit 2bd7d7ecf3c6ff844c9b8febae4e9ccfea958837
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon May 12 07:48:28 2014 +0000

    commit 214751e3cc5b154d90963f4abf0a9317733b001b
    Author:     Noel Grandin <noel@peralex.com>
    AuthorDate: Fri Apr 4 08:45:26 2014 +0200
    Commit:     Noel Grandin <noel@peralex.com>
    CommitDate: Fri Apr 4 13:44:16 2014 +0200
        cleanup up the EditEngine::GetAttribs call
        It was using a bool parameter, but passing various constants
        through it.
        Make the constants into an enum, and use the enum in the GetAttribs
        Change-Id: I3010397dfe83b24db3946b9dea2fb37f4393abdd

:100644 100644 4aca410638bdfd90456138c641d94ed2bf2af3ef 72f041db1709363ea3831ef3428971b17d1641be M	ccache.log
:100644 100644 69f321c7070eeca01bc0c6cd13bc1a768d47d0ac fded967f258c7148e0d8e7ad4e35e38ebd056c05 M	commitmsg
:100644 100644 22147ce93240bb72ceeb89adf7e96c4236c8ccd8 ad8d0284128c0fe1842a9f76808b71cd737b49f2 M	make.log
:040000 040000 3e62c8625504c18f6da9e47396d6c4bbd8962247 9c324f9b84c4125e64f0787404dd1e8d99073201 M	opt

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d
# good: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
git bisect good a900e72b6357882284c5955bdf939bf14269f5fb
# skip: [e80660c5a1d812cd04586dae1f22767fc3778c4a] source-hash-07c60c8ee2d1465544a6a39e57bc06b3690b8dfb
git bisect skip e80660c5a1d812cd04586dae1f22767fc3778c4a
# bad: [df9bcaed2faa2a8d11b19f877cdff3a12a887278] source-hash-6ba9692d8bbe3e3c245aca9a7c928e81178d05f1
git bisect bad df9bcaed2faa2a8d11b19f877cdff3a12a887278
# good: [9d57c189d74551d2b3770cc81139ea10a62e672f] source-hash-5b5e62650354788e50b44f32c22b687b2018aba9
git bisect good 9d57c189d74551d2b3770cc81139ea10a62e672f
# bad: [894c969cde608547fda47917dbeeffdf7ebb4628] source-hash-7cc6de1cc2cfb466131072c2a1cd99c4a6279ebc
git bisect bad 894c969cde608547fda47917dbeeffdf7ebb4628
# good: [043d1114b660bf322c82b6d4af3d7a6decf410b6] source-hash-de0309581b2a539e8ccf370ff0f054a56dba1c11
git bisect good 043d1114b660bf322c82b6d4af3d7a6decf410b6
# good: [b8d4c2c363da2881d681775daa3d8cd17a777667] source-hash-49a96a4d38ed144f6d05a0d2d8a83c2cee52b304
git bisect good b8d4c2c363da2881d681775daa3d8cd17a777667
# bad: [2bd7d7ecf3c6ff844c9b8febae4e9ccfea958837] source-hash-214751e3cc5b154d90963f4abf0a9317733b001b
git bisect bad 2bd7d7ecf3c6ff844c9b8febae4e9ccfea958837
# first bad commit: [2bd7d7ecf3c6ff844c9b8febae4e9ccfea958837] source-hash-214751e3cc5b154d90963f4abf0a9317733b001b
Comment 6 Timur 2016-03-29 17:51:56 UTC
Looks like a dupe of Bug 82177?
Comment 7 Timur 2016-03-29 17:53:16 UTC
If proved otherwise, please just reopen.

*** This bug has been marked as a duplicate of bug 82177 ***