Bug 82177 - FILEOPEN: DOCX - Cell top border is visible when <w:insideH> node is present
Summary: FILEOPEN: DOCX - Cell top border is visible when <w:insideH> node is present
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.0.beta1
Hardware: Other All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:6.2.0
Keywords: bibisected, bisected, filter:docx, regression
: 96009 98355 101157 104356 118753 119061 119171 (view as bug list)
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2014-08-05 06:13 UTC by Yousuf Philips (jay) (retired)
Modified: 2020-06-03 10:06 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
tableOutsideBordersLO60: 4*5 table with only outside borders opens fine in Word2003. Created by LO 6.0.6, but re-loads with one extra inside left and bottom border (4.43 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-08-25 09:33 UTC, Justin L
Details
tdf82177_outsideCellBorders.docx: only outside cell borders saved by Word 2003 (7.70 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-08-25 18:25 UTC, Justin L
Details
tdf82177_onlyInsideVH.docx: table Definition wrongly exports insideVH as bottom/right outside edges (11.46 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-09-08 04:43 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-08-05 06:13:07 UTC
Steps:
1) Open attachment 103982 [details]
2) Notice the header has a table in it with a right cell with a border at the bottom
3) Save it as a docx
4) Open the saved docx
5) Notice that the cell now also has a border at the top

This effects 4.3.1 and master, but not 4.2.5. Tested on Linux Mint.
Comment 1 ign_christian 2014-08-05 14:46:51 UTC
Reproduced with LO 4.3.0.0.beta1 - Ubuntu 12.04 x86

Not reproduced with 4.2.7.0.0+ Time: 2014-07-30_13:16:10
Comment 2 Xisco Faulí 2014-08-05 16:07:30 UTC
bibisected:

2bd7d7ecf3c6ff844c9b8febae4e9ccfea958837 is the first bad commit
commit 2bd7d7ecf3c6ff844c9b8febae4e9ccfea958837
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon May 12 07:48:28 2014 +0000

    source-hash-214751e3cc5b154d90963f4abf0a9317733b001b
    
    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
        call.
    
        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 3 Michael Stahl (allotropia) 2014-08-08 22:28:09 UTC
extra border is gone when reverting the export parts of this commit:

commit ae61569eea0719a882010cfbb260a1a0d690d974
Author:     Jacobo Aragunde Pérez <jaragunde@igalia.com>
AuthorDate: Thu Apr 3 16:27:37 2014 +0200

    oox: Do not overwrite table style properties
Comment 4 Björn Michaelsen 2014-10-16 14:59:08 UTC Comment hidden (obsolete)
Comment 5 Jorendc 2015-05-17 21:05:14 UTC
It is indeed since the start of the commit mentioned in comment 3
Problem 1: But we just render the table border incorrectly when <w:insideH> is set.
Removing all <w:insideH ...> nodes result in a correct rendering.

Opening the roundtripped file in Word 2010 doesn't show the top border (with the insideH tag). And that seems plausible to me. We only have 1 row, so there can't be a 'inside horizontal border'.

Problem 2: Otherwise I can't find the <w:insideH> node into the original file, so maybe we just have to make sure we don't export it.

LibreOffice problem only.
Comment 6 Robinson Tryon (qubit) 2015-12-14 00:44:41 UTC Comment hidden (obsolete)
Comment 7 Timur 2016-03-29 17:53:16 UTC
*** Bug 98355 has been marked as a duplicate of this bug. ***
Comment 8 Timur 2016-12-14 18:00:03 UTC
*** Bug 104356 has been marked as a duplicate of this bug. ***
Comment 9 Yousuf Philips (jay) (retired) 2017-10-31 07:45:36 UTC
As Jorendc mentioned in comment 5, this is a fileopen issue, as opening the saved .docx in Word 2007 shows it correctly.

Justin, Mike: thoughts?

Version: 6.0.0.0.alpha1+
Build ID: 60a03d97bc35c02cb1eff0e4a02b6f37fd1a6a34
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 10 Justin L 2018-08-24 17:27:42 UTC
*** Bug 118753 has been marked as a duplicate of this bug. ***
Comment 11 Justin L 2018-08-24 17:57:15 UTC
*** Bug 119061 has been marked as a duplicate of this bug. ***
Comment 12 Justin L 2018-08-25 09:33:45 UTC
Created attachment 144420 [details]
tableOutsideBordersLO60: 4*5 table with only outside borders opens fine in Word2003. Created by LO 6.0.6, but re-loads with one extra inside left and bottom border

(In reply to Yousuf Philips (jay) (retired) from comment #9)
> As Jorendc mentioned in comment 5, this is a fileopen issue, as opening the
> saved .docx in Word 2007 shows it correctly.
Important point. Also important is to test this with a larger table, since it seems to me like this is only happening on the last row (and thus on a one or two row table it looks like it is happening everywhere). Similarly right borders also add one inside border on the last column.
Comment 13 Justin L 2018-08-25 10:05:29 UTC
The table from comment 12 already shows those border in bibisect-43all, so likely this bug is inherited from OOo
Comment 14 Justin L 2018-08-25 18:23:23 UTC
<w:tcBorders>
  <w:bottom w:val="single" w:sz="2" w:space="0" w:color="000001"/>
  <w:insideH w:val="single" w:sz="2" w:space="0" w:color="000001"/>
</w:tcBorders>

Since these are CELL borders (and not table borders) this inside valueH value is moot on a single cell - it only can apply to a cluster of cells.

17.4.25 insideV (Table Cell Inside Vertical Edges Border)
This element specifies the border which shall be displayed on all interior vertical edges of the current group of table cells. [Note: Although individual table cells have no concept of an internal edge, which would render this
property useless in most cases, it is used to determine the cell borders to apply to a specific group of cells as part of table conditional formatting in a table style, for example, the inside vertical edges on the set of cells in the header row. end note]
Comment 15 Justin L 2018-08-25 18:25:50 UTC
Created attachment 144437 [details]
tdf82177_outsideCellBorders.docx: only outside cell borders saved by Word 2003
Comment 16 Justin L 2018-08-25 19:46:58 UTC
proposed export fix at https://gerrit.libreoffice.org/59600 tdf#82177 docx export: no inside borders on outside cells.

Import patch still needed.
Comment 17 Justin L 2018-08-27 18:45:01 UTC
import patch https://gerrit.libreoffice.org/59674

and since the more I look at this insideV/H stuff, the more useless it seems, a followup patch effectively reverts the first export patch, and then gets rid of the whole mess completely by never writing insideV/H. (But by keeping them separate, the second can be reverted and the first fix will still remain). https://gerrit.libreoffice.org/59675 tdf#82177 docx export: eliminate redundant insideV/H borders
Comment 18 Commit Notification 2018-08-31 15:59:52 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cecf71c18da5430c10daa8522d38d5144edefc14

tdf#82177 docx export: no inside borders on outside cells

It will be available in 6.2.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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2018-09-03 08:44:45 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4b5fcd417587cfb9e6d8b61ecb037ab165eeb5b9

tdf#82177 ooxmlimport: ignore direct insideV/H cell borders

It will be available in 6.2.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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Justin L 2018-09-08 04:43:03 UTC
Created attachment 144750 [details]
tdf82177_onlyInsideVH.docx: table Definition wrongly exports insideVH as bottom/right outside edges

On Export, the grabbag handles it OK for the cell styles, but the implementation on table properties is completely wrong. Since every cell is explicitly assigned every border, the wrong table properties are hidden. Probably better not to write anything into the table properties than wrong information (except that normally the information LOOKS correct since inside borders normally match outside borders, and outside borders tend to exist before inside borders).
Comment 21 Commit Notification 2018-09-10 08:02:14 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d934fe802c228d5478cea228b84ba56b6c9b9241

tdf#82177 docx export: eliminate invalid tcPr insideV/H borders

It will be available in 6.2.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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Commit Notification 2018-09-14 07:08:22 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=65c43d97f3f03e944c6bc35eb44a1ebcde31094e

tdf#82177 docx export: eliminate invalid tbl insideV/H borders

It will be available in 6.2.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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 23 Justin L 2018-09-14 07:16:23 UTC
This particular part of the wider table borders bug is fixed. Bug 92026 is closely related - dealing with the outside borders defined by the tblBorders auto-filling empty borders using cell A1 as the template.
Comment 24 Xisco Faulí 2018-09-18 16:15:40 UTC
Verified in ( along with its duplicates )

Version: 6.2.0.0.alpha0+
Build ID: 2419fa71d8b2223a50f596d5db7721f6213d4f87
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

@Justin Luth, Thanks for fixing this!!
Comment 25 Justin L 2018-09-22 18:22:34 UTC
*** Bug 96009 has been marked as a duplicate of this bug. ***
Comment 26 NISZ LibreOffice Team 2019-12-18 08:38:24 UTC
*** Bug 119171 has been marked as a duplicate of this bug. ***
Comment 27 Justin L 2020-06-03 10:06:18 UTC
*** Bug 101157 has been marked as a duplicate of this bug. ***