This bug is a "clone" of bug 80292. In that bug I found that when create a HTML document in libreoffice and insert a table, it's always a "one-column" table. But after further investigation, I find it's not "one-column", it's many columns as expected but without left and right borders so it looks like one-column. Steps: 1. Start LibreOffice; 2. File - New - HTML Document; 3. Table - Insert - Table: 8 rows 8 columns Current Result: A table with 8 rows and 8 columns was inserted, but there is no left and right borders for the cells. When save the file and view HTML source, I see the following for each <td> tag: <td width="13%" ... border-right: none;...> So maybe the "border-right: none" caused the problem. When you insert a table, it should never by default to set top-bottom borders to 1px but left-right borders to none. Reproduce with: 4.2.5.2, 4.3.0.1 Ubuntu 14.04 x86
Added the cc list in bug 80292 to this one.
Confirmed in Linux Mint in 4.0.6, 4.1.6, 4.2.5 and 4.3.0. Worked correctly in 3.3.0 and 3.6.7. The table is not visible at all in 4.0 and 4.1, while in 4.2 and above, the left and right borders of each cell are missing. Included below is the html code of the first cell in various versions. = LibO 3.3 = <TD WIDTH=13% STYLE="; border-top: 2.60pt double #808080; border-bottom: 2.60pt double #808080; border-left: 2.60pt double #808080; border-right: none; padding-top: 0.04in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in"> = LibO 3.6 = <TD WIDTH=13% STYLE="border-top: 1px double #808080; border-bottom: 1px double #808080; border-left: 1px double #808080; border-right: none; padding-top: 0.04in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in"> = LibO 4.0 to 4.3 = <td width="13%" style="border-top: 1px double #808080; border-bottom: 1px double #808080; border-left: 1px double #808080; border-right: none; padding-top: 0.04in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in"> So after looking over this html code, it seems there is nothing wrong with the html code, its just that LibO is not rendering it properly, as opening the 4.0 html file in 4.2 shows the top and bottom borders.
I believe the problem is just the rendering of the line style of the table. Go to table->table properties->borders and change the "Style" of the line from the fourth-last to the second entry and it renders well, back to the fourth-last and the vertical lines disappear
Yes that will do fix it, but LibO should be setting these things incorrectly.
Priority: Minor - slows down professional quality work but does not prevent it High - regression + easily visible 221bf5c0db153e24c67ff29fe614af7cc010a356 is the first bad commit commit 221bf5c0db153e24c67ff29fe614af7cc010a356 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 04:33:50 2012 +0000 source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74 commit 9210b95bcfd65ae558f445666d9b880e794d4c74 Author: Kohei Yoshida <kohei.yoshida@gmail.com> AuthorDate: Thu Nov 15 16:31:49 2012 -0500 Commit: Kohei Yoshida <kohei.yoshida@gmail.com> CommitDate: Thu Nov 15 18:07:17 2012 -0500 Make GetParent() const-correct. const method should return const pointer if it points to an object held internally & prefer taking const pointer as a method argument if possible. Change-Id: I4dc8c31d55aa0054ea6db521be9ad45fefef8d07 :100644 100644 738578ee72c5b929f6609df9971137caf4a49dd2 26157d38356b3591abc92ee949953d37ac93201f M autogen.log :100644 100644 5f2a44c5e7ce0c7653b5834e1f4a329791243ae2 5f3674b08eed2ed4a5a89db302b5a9c11e5cc33e M ccache.log :100644 100644 e1b88a7fa01b6f2a281894d7f6849ab2330aab76 1b372eb248c5d4846b8e34b67c97c86ee2137d7a M commitmsg :100644 100644 33209181930196bebdc405c8ca66e9169724b348 fe6de78bab06d66b4dcc7daf3e8da0a9bd028bcd M dev-install.log :100644 100644 1260d21415e7d260c7b6a1ca81cde42fee4ecbaa 15080cbc9084e133603b9c0a387bc9f590c8e05b M make.log :040000 040000 fa33c45cc461aca44e2b41f25b965b8dc089ba34 af9223892695b7550d228ad3a89f09d98ffb9e44 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28 # bad: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af git bisect bad d65a58c31c8da044ef66ae4517fa2fe74cec0019 # bad: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73 git bisect bad 79e02001f27d33b3b478324ab6fba5683413b4d9 # good: [183a576d94de9a9439d580c8b81f335ab57cdbdc] source-hash-a599f5b4b51848e3b397d471c9d12b373caadcef git bisect good 183a576d94de9a9439d580c8b81f335ab57cdbdc # good: [a67b874d60de1f1a44bef57a53a7b8a84db0ba58] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 git bisect good a67b874d60de1f1a44bef57a53a7b8a84db0ba58 # bad: [221bf5c0db153e24c67ff29fe614af7cc010a356] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74 git bisect bad 221bf5c0db153e24c67ff29fe614af7cc010a356 # good: [46f9a799a00ba869957d7aa7650cae7fd2501394] source-hash-a43a76cd5aa2f145f2cb43fcdbc8f21fb6c89af0 git bisect good 46f9a799a00ba869957d7aa7650cae7fd2501394 # first bad commit: [221bf5c0db153e24c67ff29fe614af7cc010a356] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Regression introduced by author Kohei Yoshida <kohei.yoshida@collabora.com> 2014-03-03 22:58:11 (GMT) committer Kohei Yoshida <kohei.yoshida@collabora.com> 2014-03-05 03:02:37 (GMT) commit 2c62596cf264ef10749d8bfdb2bb2ebef2d98fbc (patch) tree 1311156cb36884d0dde2b022467d7d0de6d799df parent fb052ae6174e4c96157ef6973f02c1d3cd4d9ba2 (diff) fdo#75260: Correctly draw double lines for both Writer and Calc. Fix all sorts of incorrect double line handling in drawinglayer in order to draw thick-thin double line types correctly. Also change handling of border lines in writer tables. There are still some outstanding issues but it's much better than how it was before. Also realized that Word and Excel handle simple thin double lines differently; Word varies widths of all of the lines and the gap whereas Excel only has one fixed size for its double line. For this reason I decided to add Adding Cc: to Kohei Yoshida
Still a repro with: Version: 5.4.0.0.alpha1+ Build ID: 274ecb49b70b3f01d47546e3b44317946c106042 CPU threads: 4; OS: Windows 6.2; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-05_22:45:07 Locale: nl-BE (nl_NL); Calc: single
No repro with: Version: 6.0.0.0.alpha0+ Build ID: cac5c9f6081590b0548d3116bc4cd4a2509ec576 CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-01_00:41:48 Locale: it-IT (nl_NL); Calc: CL Probably because of: https://cgit.freedesktop.org/libreoffice/core/commit/?id=74d9b711d71cbaf4f853559211f6525db4a4b5db
Dear Kevin Suo, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
In recent version (7.0) the cell borders for tables are default to be none, so we need to manually set borders, and if manually set the borders are fine. Mark as worksforme.