Bug 96009 - FILESAVE: DOCX - Extra top border appears on last row of table
Summary: FILESAVE: DOCX - Extra top border appears on last row of table
Status: RESOLVED DUPLICATE of bug 82177
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Tables Table-Borders
  Show dependency treegraph
 
Reported: 2015-11-23 11:30 UTC by parchd
Modified: 2018-09-22 18:22 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
illustration of issue (11.06 KB, image/png)
2015-11-23 11:30 UTC, parchd
Details
Original, correct file in odt format (8.17 KB, application/vnd.oasis.opendocument.text)
2015-11-23 11:31 UTC, parchd
Details
Incorrectly displaying docx version (4.12 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-11-23 11:31 UTC, parchd
Details

Note You need to log in before you can comment on or make changes to this bug.
Description parchd 2015-11-23 11:30:20 UTC
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.
Comment 1 parchd 2015-11-23 11:31:25 UTC
Created attachment 120740 [details]
Original, correct file in odt format
Comment 2 parchd 2015-11-23 11:31:48 UTC
Created attachment 120741 [details]
Incorrectly displaying docx version
Comment 3 A (Andy) 2015-11-23 20:34:39 UTC
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
Comment 4 Buovjaga 2015-11-27 19:05:09 UTC
(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)
Comment 5 Telesto 2016-12-22 19:35:24 UTC
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
Comment 7 Xisco Faulí 2016-12-23 15:24:00 UTC
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
Comment 8 Yousuf Philips (jay) (retired) 2017-05-10 03:03:08 UTC
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.
Comment 9 Eyal Rozenberg 2017-12-28 22:09:02 UTC
I wonder if there isn't some duplication between this and the other bugs reported on extra borders when saving to DOCX.
Comment 10 Justin L 2018-09-22 18:22:34 UTC
Fixed in 6.2 master

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