Bug 132898 - FILEOPEN DOCX: merged cell missing edge border in table
Summary: FILEOPEN DOCX: merged cell missing edge border in table
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.1.0
Keywords: filter:docx
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2020-05-09 22:22 UTC by Alvaro Segura
Modified: 2020-07-20 19:09 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample file where this behavior appears (41.67 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-05-09 22:24 UTC, Alvaro Segura
Details
Comparison of MSWord vs Writer rendering (6.35 KB, image/png)
2020-05-09 22:30 UTC, Alvaro Segura
Details
Some edge cases to check when fixing this (13.33 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-06-05 07:13 UTC, Szabolcs Toth
Details
Problem with the proposed fix (35.06 KB, image/png)
2020-06-05 08:18 UTC, Szabolcs Toth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alvaro Segura 2020-05-09 22:22:52 UTC
Description:
A document contains a table with borders (some cells are joined vertically). Loading it in Writer does not show one of the bottom borders.

BTW, horizontal borders look quite fuzzy, like being two gray pixels thick, instead of one black pixel.

After investigating more, I found that in Word, the bad cell area has top and bottom borders, but no middle border. If I enable the middle border then it shows up. But this still makes no sense because the missing border is the bottom one, and there is no middle border because the bad cell spans all the table vertically.

Steps to Reproduce:
Thoroughly explained in the description. Sample attachment coming.

Actual Results:
Explained above. And in coming attachments.

Expected Results:
Explained above.


Reproducible: Always


User Profile Reset: No



Additional Info:
-
Comment 1 Alvaro Segura 2020-05-09 22:24:50 UTC
Created attachment 160580 [details]
Sample file where this behavior appears

The table in the page header misses one border in Writer, and renders borders quite fuzzy.
Comment 2 Alvaro Segura 2020-05-09 22:30:55 UTC
Created attachment 160581 [details]
Comparison of MSWord vs Writer rendering

The border below "logo" is missing in Writer.

Also the horizontal borders look like thick gray lines. This is not apparent at high zoom, so it might be related to altialiasing or something like that (the line not fitting pixels exactly but being in-between, so to say).
Comment 3 Alvaro Segura 2020-05-09 22:32:02 UTC
This may be related to Bug 104345 (even though that was about paragraphs and this is about tables)
Comment 4 Xisco Faulí 2020-05-11 10:26:30 UTC
Reproduced in

Version: 7.0.0.0.alpha1+
Build ID: 86bc13248c1d9f63b10aac304bdf0361d1dcc47f
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

in previous versions, the table is no even imported
Comment 5 Justin L 2020-06-04 07:41:51 UTC
A similar situation was handled in bug 129452 for LO 7.0. That one added the "table properties" border.  This document doesn't have a border from the table properties, but just the last merged cell itself.
Comment 6 Justin L 2020-06-04 15:59:04 UTC
proposed fix at https://gerrit.libreoffice.org/c/core/+/95528
Comment 7 Szabolcs Toth 2020-06-05 07:13:20 UTC
Created attachment 161637 [details]
Some edge cases to check when fixing this
Comment 8 Szabolcs Toth 2020-06-05 08:18:51 UTC
Created attachment 161644 [details]
Problem with the proposed fix
Comment 9 Justin L 2020-06-05 11:53:23 UTC
(In reply to Szabolcs Toth from comment #8)
> Problem with the proposed fix

Oh, wow. Great find.
The problem is because of the gridspan. So nCell==4 in the second last row is the same column as nCell==5 in the last row.  Now how to handle that will be NASTY!
Comment 10 Justin L 2020-06-05 17:53:54 UTC
The underlying code needs a fundamental shift, so proposed patch is not adequate.
Comment 11 Justin L 2020-06-29 16:39:25 UTC Comment hidden (no-value)
Comment 12 Justin L 2020-06-30 12:08:52 UTC
http://gerrit.libreoffice.org/c/core/+/97432 tdf#129452 writerfilter: preserve gridBefore longer than currentRow

http://gerrit.libreoffice.org/c/core/+/97433 tdf#129452 writerfilter: preserve gridSpans longer than currentRow

http://gerrit.libreoffice.org/c/core/+/97434 tdf129452 writerfilter: use column, not cell when comparing rows

http://gerrit.libreoffice.org/c/core/+/95528 tdf#132898 writerfilter: use last merged cell's bottom border
Comment 13 Commit Notification 2020-07-16 16:43:39 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/03803de58bd426eb0b726437dc205d92383e8e2e

tdf#132898 writerfilter: use last merged cell's bottom border

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 BogdanB 2020-07-20 19:09:27 UTC
Resolved.
Verified in
Version: 7.1.0.0.alpha0+
Build ID: abea0d6647c7f1f7e76c73c26cb80e6a67dc5111
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded