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.
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
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
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
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
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.
Migrating Whiteboard tags to Keywords: (bibisected, filter:docx) [NinjaEdit]
*** Bug 98355 has been marked as a duplicate of this bug. ***
*** Bug 104356 has been marked as a duplicate of this bug. ***
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
*** Bug 118753 has been marked as a duplicate of this bug. ***
*** Bug 119061 has been marked as a duplicate of this bug. ***
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.
The table from comment 12 already shows those border in bibisect-43all, so likely this bug is inherited from OOo
<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]
Created attachment 144437 [details] tdf82177_outsideCellBorders.docx: only outside cell borders saved by Word 2003
proposed export fix at https://gerrit.libreoffice.org/59600 tdf#82177 docx export: no inside borders on outside cells. Import patch still needed.
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
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.
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.
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).
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.
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.
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.
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!!
*** Bug 96009 has been marked as a duplicate of this bug. ***
*** Bug 119171 has been marked as a duplicate of this bug. ***
*** Bug 101157 has been marked as a duplicate of this bug. ***