Created attachment 120739 [details] illustration of issue The style of the final row in a table also applies to penultimate row after saving as docx. I have found a workaround, and do not know whether this is a filesave issue (whether the issue is visible when opening file in Word) or a docx reading issue. Image illustrating issue is attached. I will also attach the odt and docx files. Hopefully someone with other office software can identify where the issue lies.
Created attachment 120740 [details] Original, correct file in odt format
Created attachment 120741 [details] Incorrectly displaying docx version
My results with LO 5.0.3.2, Win 8.1: attached odt file saved as docx with LO: -> reopened with LO = everything is fine -> reopened with Word = file content is corrupted and not correctly opened attached odt file saved as doc with LO: -> reopened with LO = everything is fine -> reopened with Word = file content is corrupted and not correctly opened opened the attached docx file with LO -> issue reproducible as shown in the attached png opened the attached docx file with Word -> table is fine
(In reply to parchd from comment #0) > Created attachment 120739 [details] > illustration of issue Unlike Andy, I reproduce and get the extra border. Win 7 Pro 64-bit, Version: 5.0.3.2 (x64) Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale: fi-FI (fi_FI) Version: 5.1.0.0.alpha1+ Build ID: f6bc5b79c31225c02e9500d0ced4bd26f998f82b Threads 4; Ver: Windows 6.1; Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2015-11-24_01:07:47 Locale: fi-FI (fi_FI)
Repro with: Version: 5.4.0.0.alpha0+ Build ID: 9cfb2f2f03b5ec086487fd483298466db0b09010 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-20_23:58:02 Locale: nl-NL (nl_NL); Calc: CL and with: Version: 4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0 but not with: Versie: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d8ae59e097b3fca29f071d1a792cdb98ad8139cf..42ced106ff6ed5688385a5d2b40d4b5caea68406
Regression introduced by: author Miklos Vajna <vmiklos@collabora.co.uk> 2014-04-03 11:35:04 (GMT) committer Miklos Vajna <vmiklos@collabora.co.uk> 2014-04-03 12:01:03 (GMT) commit 84c04d73e6f80120c2fc7d17dd12e3b68214a63b (patch) tree 43212bef2733aa6ffd6b7d7d7243a9bcc7b567df parent 5babf1b9037eb283798322eecd8334e6ff1db655 (diff) fdo#76979 DOCX export: a:srgbClr should be always an explicit color The brush color contains both the color itself and transparency as well. In case of DocxAttributeOutput::FormatBackground(), the sColor should contain the color part, and oAlpha the transparency part. In case of drawingML export of Writer TextFrames, an automatic color (0xFFFFFFF) shouldn't be recognized as "auto", as that's invalid: instead an explicit 0xFFFFFF with zero transparency should be written. Fix the problem by calling msfilter::util::ConvertColor() for the RGB color only. Adding Cc: to Miklos Vajna
So LO is incorrectly saving <w:insideH> entries in the border properties of the cells of the last rows, as below. <w:tc> <w:tcPr> <...> <w:tcBorders> <w:bottom w:val="single" w:sz="12" w:space="0" w:color="000000" /> <w:insideH w:val="single" w:sz="12" w:space="0" w:color="000000" /> </w:tcBorders> <...> </w:tcPr> <...> </w:tc> MS Word ignores the <w:insideH> entries set at that the <w:tc> cell-level as <w:insideH> "Specifies the border to be displayed on all interior horizontal edges of the cell. Note that this is mostly useless in the case of individual cells, as there is no concept of interior edge for individual cells. However, it is used to determine cell borders to apply to a specific group of cells as part of table conditional formatting in a table style, e.g., the inside edges on the set of cells in the first column." - ECMA-376, 3rd Edition (June, 2011), Fundamentals and Markup Language Reference § 17.4.24.
I wonder if there isn't some duplication between this and the other bugs reported on extra borders when saving to DOCX.
Fixed in 6.2 master *** This bug has been marked as a duplicate of bug 82177 ***