Bug 112285 - FILESAVE DOCX "Merge adjacent line styles" for table borders gets reactivated after deactivating
Summary: FILESAVE DOCX "Merge adjacent line styles" for table borders gets reactivated...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
: 124378 (view as bug list)
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2017-09-08 08:40 UTC by Gabor Kelemen (allotropia)
Modified: 2020-06-03 11:52 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file from LO 5.3 (8.82 KB, application/vnd.oasis.opendocument.text)
2017-09-08 08:40 UTC, Gabor Kelemen (allotropia)
Details
Same file exported to docx (13.66 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-09-08 08:40 UTC, Gabor Kelemen (allotropia)
Details
The two files in LO 5.4 side by side (137.07 KB, image/png)
2017-09-08 08:42 UTC, Gabor Kelemen (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Kelemen (allotropia) 2017-09-08 08:40:01 UTC
Created attachment 136111 [details]
Example file from LO 5.3

LibreOffice loses the “no borders” horizontal cell border property of a single cell or a subset of cells if the surrounding cells of the same table have borders when the document is saved as DOCX. Furthermore, the „Merge adjacent line styles” option is always turned on in DOCX files, regardless of what the setting originally was during the editing process. This might be caused by LibreOffice forcing the „Merge adjacent line styles” function when exporting the document as a DOCX file.

Steps to reproduce:
1. Create a new document in LibreOffice Writer.
2. Insert a 3 column wide, 3 row high table.
3. Select all cells of the table, and uncheck the “Merge adjacent line styles” option on the Borders tab in the Table Format window and press OK.
4. Select the 3 cells in the middle column.
5. Change the Line Arrangement with the „Set No Borders” button to borderless.
6. Save the file both as ODT and DOCX.
7. Reopen both files.

Actual results:
All cells have horizontal borders in the DOCX file, but not in the ODT file. Furthermore, the “Merge adjacent line styles” option in the Table Format window is active in the DOCX file, but inactive in the ODT file.

Expected results:
The files should look identical.
Comment 1 Gabor Kelemen (allotropia) 2017-09-08 08:40:27 UTC
Created attachment 136112 [details]
Same file exported to docx
Comment 2 Gabor Kelemen (allotropia) 2017-09-08 08:42:44 UTC
Created attachment 136113 [details]
The two files in LO 5.4 side by side
Comment 3 Buovjaga 2017-09-11 06:06:05 UTC
Repro.

In 3.6, it gives border colour to the top and bottom borders, but not to the middle ones. Still wrong, so changing version field.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: 09122a537318f7ada075820f3b1ef83a64e56751
CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on September 10th 2017

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 4 Eyal Rozenberg 2017-12-28 17:19:12 UTC
A very painful issue when exchanging files with MS-Word users...

have seen it on multiple versions, for a long time - just got around to filing it and I found this issue. 

So, specifically, reproduced with LO 6.0.0.0.beta2 on Linux Mint 18.3.
Comment 5 Justin L 2018-09-24 06:18:55 UTC
Visually, this is fixed in 6.2 from bug 82177.

This bug could be left open to investigate "Merge adjacent line styles", but Word/Writer handle cell border quite differently, and that is probably a Writer specific setting with no corresponding MSO property.
Comment 6 Eyal Rozenberg 2018-09-24 12:37:34 UTC
(In reply to Justin L from comment #5)
> Visually, this is fixed in 6.2 from bug 82177.

It seems to be only _partially_ fixed. With the example file, the lack-of-borders is preserved for the borders between consecutive cells of the middle column, but is _not_ preserved for the top border of the top cell and bottom border of the bottom cell of the middle column, i.e. the external border of the entire table is complete when loading the exported DOCX file.

I tested using: 

Version: 6.2.0.0.alpha0+
Build ID: d8860e492ea8a22804750eeb6dd80f0c009365c9
CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-23_23:54:34
Locale: en-US (en_IL); Calc: threaded
Comment 7 Xisco Faulí 2019-04-30 09:09:20 UTC
*** Bug 124378 has been marked as a duplicate of this bug. ***
Comment 8 Justin L 2020-06-03 11:36:45 UTC
(In reply to Eyal Rozenberg from comment #6)
> It seems to be only _partially_ fixed. With the example file, the
> lack-of-borders is preserved for the borders between consecutive cells of
> the middle column, but is _not_ preserved for the top border of the top cell
> and bottom border of the bottom cell of the middle column, i.e. the external
> border of the entire table is complete when loading the exported DOCX file.

Please test again.  I don't see any lines at the top or bottom of the table.
Comment 9 Buovjaga 2020-06-03 11:52:12 UTC
I confirm what Justin said. Changing summary per his idea.

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: bfbf745470cb6f99532523fdeffca061b37d8393
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 31 May 2020