Borders are not properly shown in table from attachment 104554 [details] from Bug 82553. Table looked differently in all LO versions, but it was fixed from 5.0 beta 3. What's left is that table borders are not applied correctly on Fileopen and some are missing. They were never fully OK, even in OO, 3.3.4/3.4.4/3.5.7 had borders but also a problem with merged cells, and then some were missing in 3.6 which is (after table itself was wrong) similar to current 5.0. So, 3.5.7 is closest but still not quite fine, because first 3 rows are always wrong. Table preview with MSO 2010 in attachment 112351 [details] shows how it should look like.
Confirmed. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: d56b125f6c6c18ac40712cefc3cec06530750e15 TinderBox: Win-x86@39, Branch:master, Time: 2015-06-13_07:08:43 Locale: fi-FI (fi_FI)
Still reproducible in Version: 5.4.0.0.alpha0+ Build ID: d3b5bd4a07a619db6bee1c39c32280ac3c620532 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
A screenshot of Expected vs Actual wouldn't hurt.
(In reply to Eyal Rozenberg from comment #3) > A screenshot of Expected vs Actual wouldn't hurt. There's a pdf of Expected in attachment 112351 [details] :)
A more simple case of border problems, which is likely to be part of this bug: If top and bottom borders are added to the first row of a table, then a DOCX version of the table will have borders for all rows. To reproduce: 1. Create a new table in Writer. 2. Select whole table -> Table properties -> Borders, and remove all borders. 3. Select first row of table -> Table properties -> Borders, and add top and bottom border. 4. Table now (correctly) has lines above and below first row, while the other rows are without border. 5. Save as DOCX. Found behaviour: When DOCX file is opened (in LO Writer or in MSO Word), all rows of the table have border, not just the first row. Expected behaviour: As 4. in list to reproduce: Only border for the first row. This only applies to DOCX format. If DOC format is used, the bug does not appear. A similar bug can be produced by selecting the first column and adding left and right border. This has been tested with LO 5.4.3 and the upcoming LO 6.0.0.1 with identical results. (Operating system was Windows 10, but the bug is not suspected to be related to operating system.)
Created attachment 142467 [details] Test case (odt file) of tables with borders Attachment contains Writer file (odt) with three standard tables, two of which have borders defined on the first cell in the table. By LO version 6.0.4.2, the table borders are still not correct when saved as DOCX: The borders of the first cell are copied to all cells of the table.
Additional information to comment 6: The problem of table borders sometimes becoming wrong when saved from LO Writer as DOCX is still present by version 6.0.4.2. But unlike my earlier comment 5, the problem does not seem to relate to the first ROW of the table, but instead specifically the first CELL of the table. My new finding (see attachment 142467 [details]) is that the borders of the first cell are copied to the rest of the table when saved as DOCX (but not as DOC). This goes for both horizonatal and vertical borders. The behaviour has been tested with DOCX as "Microsoft Word 2007-2013 XML (docx)" and as "Office Open XML text document (docx)" with identical results. Loading is identical in MS Word and LO Writer.
(In reply to Lars Jødal from comment #7) Also seeing the same thing (with 6.0.4.2): If I set a first cell's borders and save to DOCX, I get them all over the table. Way to go Lars! You narrowed down the location of the bug without having to look at the code - that's great! I wonder if it's going to end up being some real easy one-liner fix...
I'm increasing the importance to at least medium. And I suggest it be raised to Major. Why? Because of users who: 1. Use tables with non-uniform borders 2. Interact with people who need DOCX files rather that ODT - so they open DOCX'es and save DOCX'es to send back Because those people send files to their collaborators with messed-up tables - which means that the final version has to be produced in MS-Word and have its borders fixed. The intersection of these two groups is quite large; but what's more, it severely hampers advocacy efforts for LO writer in MS-Office environments, since the person who starts using it either needs to do twice the work (fix things him/herself in MS-Office), or they start sending out messed-up documents. It should be the case that you can tell your colleagues: "Hey, just try LO for a while, you can still send DOCX'es like before, it's easy" - and this is a glaring part of the reason it's not. So this should be more important and get developer attention sooner IMHO. On an unrelated note: The possibly-dupe bug 93234 has 5.0.0.5 as its first manifestation version. Is this the case here as well?
(In reply to Eyal Rozenberg from comment #9) > I'm increasing the importance to at least medium. And I suggest it be raised > to Major. Why? Because of users who: Eyal: you raised the severity, which means the relative badness of the effect on working. The priority was already medium. Priority is a clue for devs regarding how pressing something is. The reporter himself set severity to minor. Please see https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
(In reply to Buovjaga from comment #10) > (In reply to Eyal Rozenberg from comment #9) > > I'm increasing the importance to at least medium. And I suggest it be raised > > to Major. Why? Because of users who: > > Eyal: you raised the severity, which means the relative badness of the > effect on working. The priority was already medium. Priority is a clue for > devs regarding how pressing something is. The reporter himself set severity > to minor. Please see > https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart. > jpg From the flowchart, the bug fits this description: "Does the bug prevents user from making professional quality work, including exchanging files with other office suites?" This gives it a setting "MEDIUM -> NORMAL". If I understand correctly, this means medium priority and a normal severity? In any case, higher than "minor". A typical example from my own use of LO: Among other things, I use LO for writing scientific papers. The papers very often contain tables with data, and a common convention is to format tables with borders at top and bottom of the first row (headline), and the bottom of the last row (end of table). I.e., not borders in the interior of the table. However, most of my co-authors use MS Word, so I share in docx format (or both docx and odt). But before sending the docx file I have to open it in MS Word and go through all tables to correct the borders, as the docx file from LO Writer has horizontal borders (copied from the first cell) all over all tables. Very annoying, and definitely making a switch entirely to LO very difficult.
Created attachment 144753 [details] onlyInsideVH.docx: exaggerated example, seen when round-tripping since this is an export bug.
There is only one way to fix this that I can see, and that is to get rid of the table properties (when it isn't grab-bag copied from a style). Doing that depends on bug 119760.
proposed fix at https://gerrit.libreoffice.org/60989
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d4c6ee89ef6302db08c23bbe2d3fb4d7de3b1a3 tdf#92026 docxexport: eliminate fake tblBorders 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.
I can't even see what the problem is from comment 0, but I confirmed fix when documents in comment 6 and comment 12 are round-tripped.
Using LibreOfficeDev 6.2.0.0.alpha0+ master from 2018-10-01, I can confirm that the problem is fixed. Tested with the examples from this thread, as well as one of my own real-life examples. Well done!
Just a thought: Is there any reason not to push this fix to the 6.1.x line, rather than wait for 6.2.0? It is a bug fix, not a new feature, and the 6.1.x line is still in the "fresh" phase.
At least in my workflow, there were about 4 or 5 patches that led up to this fix, and at least one of them is essential, with all of them contributing in some way to various fake table border info. I'm not at all interesting in causing regressions, so I'm very happy to *not* backport this batch of fixes, but to give them the full time for QA testing in case some other magical properties were assigned to the table-level borders.
Attached odt file Test case saved as docx works good in: Version: 6.2.0.0.alpha0+ (x64) Build ID: 89a60912bba7ffd6f65ea99f4664f343c5025c95 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-01_03:18:33 Locale: bs-BA (bs_BA); Calc: threaded OS:Win 7 unlike docx file saved in LO 6.1.0.3 where has all borders instead just one cell