Bug 88208 - EDITING: Double borders (specific?) inconsistent between dialog preview and rendered document
Summary: EDITING: Double borders (specific?) inconsistent between dialog preview and r...
Status: RESOLVED DUPLICATE of bug 75260
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, regression
Depends on:
Reported: 2015-01-08 17:24 UTC by Frank
Modified: 2016-10-07 15:35 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

How to reproduce bug 88208 in two different Writer versions (74.13 KB, application/vnd.oasis.opendocument.text)
2015-01-08 23:08 UTC, Frank

Note You need to log in before you can comment on or make changes to this bug.
Description Frank 2015-01-08 17:24:25 UTC
Not sure when this first appeared as I haven't used non-default table borders for a while, but I don't recall seeing this behavior earlier.

I'm using Ubuntu 64 bit 14.04 LTS with LibreOffice Version:
Build ID: 9bb7eadab57b6755b1265afa86e04bf45fbfc644

When doing Table Format - Borders, if I choose any doulbe line Style, the display in the dialog shows just a really fat border, although the border displays properly in the document. The problem with the display in the dialog box doesn't seem like it has anything to do with my own graphics, since the lines display fine in the drop-down box.

But wait - it gets better!

If I save the document and then reload it, any table lines that were originally double lines (of at least several flavors - I obviously haven't attempted every permutation) show up as blank.

As far as I can tell, the color used doesn't seem to make a difference, and I've tried several different point sizes.

I've located several bugs that appear similar (although not identical) but they've all been marked as Fixed.
Comment 1 tommy27 2015-01-08 17:33:46 UTC
try latest LibO release and revert status to UNCONFIRMED if issue persists.
Comment 2 Joel Madero 2015-01-08 17:50:29 UTC
Also when you reply please give a test document and clear reproducible steps, preferably enumerated. Lastly, please keep it to 1 bug per report, even if they are similar, if there are separate issues (as there appear to be in this bug), please separate them into multiple reports.

Please see: https://wiki.documentfoundation.org/QA/BugReport#Good_Reports for more information. Thanks
Comment 3 Frank 2015-01-08 23:08:07 UTC
Created attachment 111982 [details]
How to reproduce bug 88208 in two different Writer versions

Thanks for the responses. Sorry you were unable to follow my earlier description; I hope the attached document contains enumerated instructions that are easier to follow.

I've fiddled with this behavior some more, and there doesn't seem to be any doubt that it is reproducible using whatever techniques I could come up with to do it differently. I would have tried other Writer versions, but those referenced in the document ( and are the only ones I have loaded, although I can't normally use the 4.4 because of some of its bugs clobber my documents significantly.

If you still can't reproduce the behavior I described, just close it, as it's not that hard to avoid using alternate table borders, and I realize there are certainly more serious bugs to work on.

- Frank
Comment 4 Cor Nouws 2015-01-13 11:03:51 UTC
Hi Frank,

I can confirm this on Ubuntu 32 bits.

The specific table border setting that you described, does show in the document, but after closing and reopening, it has gone.
  thick over thin
  all borders
  all other settings default

tested in and 4.4.0. beta2

When reopening the file in beta2 and looking at the tab Border, the line styles are all huge fat: width is set to 9 pt, instead to 0,05

When applying thin over thick line (and the rest the same) only horizontal borders are applied, and single line.
closing and reopening, shows a different boarder style on all sides: double even, 0,15 pt.
(both in and 4.4.0. beta2)

thanks for filing and explaining.

Some more testing needed.
Really looks as if every setting is changed on opening?

Comment 5 Robinson Tryon (qubit) 2015-12-14 05:32:36 UTC Comment hidden (obsolete)
Comment 6 Joel Madero 2015-12-17 17:20:15 UTC
A few points on this bug:

(1) This bug is pretty hard to bibisect as it's two separate issues....so this bibisect is specific only to the loss of border (not to the type of line as far as I can tell that's not a regression - thus the suggestion to split the bug...)

(2) Furthermore, some wonky behavior happened in between that makes the bibisect even harder to nail down....
(*) It seems like the specific style (bold on top, thin on bottom) was never retained - I tested this all the way back to 3.3
(*) At some point applying the style actually completely made the border blank immediately, then closing/reopening the file showed the border (basically the opposite of current behavior)

I've done two bibisects:
1) At some point borders just completely disappeared when you set them to this style -> first bibisect identifies this
2) At some later point a border is applied but upon reopen it goes away (this bug report)


221bf5c0db153e24c67ff29fe614af7cc010a356 is the first bad commit
commit 221bf5c0db153e24c67ff29fe614af7cc010a356
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue Dec 11 04:33:50 2012 +0000

    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


4a7f15df32bc9d3c05991413724e64651a7fc337 is the first bad commit
commit 4a7f15df32bc9d3c05991413724e64651a7fc337
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sun May 11 20:41:38 2014 +0000

    commit eb847b33f7ea5b5e103886da7eb5dd1cc3061422
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Wed Mar 5 10:56:47 2014 +0000
    Commit:     Gerrit Code Review <gerrit@gerrit.libreoffice.org>
    CommitDate: Wed Mar 5 05:05:26 2014 -0600
        Updated core
        Project: help  d17b89d10487e87000998056c30f9ecfa8b1a86a

:100644 100644 744c6d0093985d1efdb5174ccdbb6937964dbe18 695fc699905ca16c25f66ce34aae61d8a56adace M	ccache.log
:100644 100644 2419d91cb771a988bb66395e49d06896f051a5dd e9e6f86c61d97c0d3bc10a7a44d1affe707288ed M	commitmsg
:100644 100644 d1de4b5886c91f90c212f3663cfe87288b6ae36a d6f003cfcdb89af7d573bdcbb2c012afd2f24019 M	make.log
:040000 040000 82feaf9bf41c1b265a0ff75c13d214c866df031e 45ed53b68f7f56351da54c15c5cd4ef8a96b7f82 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
# bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb
# good: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b
git bisect good e1d0365cd2b073a859f59ad0a4584385a66dc611
# skip: [8f55938c891ee3e4c252b193dba9419f130537bc] source-hash-93f3f72d18e551c8edd6a010cb78d9cbe404f8ef
git bisect skip 8f55938c891ee3e4c252b193dba9419f130537bc
# good: [7518fcaf863962bf4f6f3cdf84f6e42f0f59225f] source-hash-ab1f5eab4830f00dbbd7c883b98b59975ecd3bb1
git bisect good 7518fcaf863962bf4f6f3cdf84f6e42f0f59225f
# bad: [56a3b3c781fc2eb55f46641d89a866a91119a8a3] source-hash-21e6fd2b2dfdb806db320f699e434e6f2351a7b6
git bisect bad 56a3b3c781fc2eb55f46641d89a866a91119a8a3
# good: [1b1974dec96ab21a79c3f574f3654a9515fed9d0] source-hash-51f74e362b364e51f13f3abaa00df1aa01c81cef
git bisect good 1b1974dec96ab21a79c3f574f3654a9515fed9d0
# bad: [2f040759edbb7bb8e7a41cf06bac2a2a0fb50c73] source-hash-76fe205d7e0fe0a73616453209d8094cab9ce79f
git bisect bad 2f040759edbb7bb8e7a41cf06bac2a2a0fb50c73
# bad: [4a7f15df32bc9d3c05991413724e64651a7fc337] source-hash-eb847b33f7ea5b5e103886da7eb5dd1cc3061422
git bisect bad 4a7f15df32bc9d3c05991413724e64651a7fc337
# first bad commit: [4a7f15df32bc9d3c05991413724e64651a7fc337] source-hash-eb847b33f7ea5b5e103886da7eb5dd1cc3061422
Comment 7 Timur 2016-05-04 13:01:09 UTC
Table lines lost on reload not reproduced since 5.1.
Double line reproduced but isn't it a duplicate of Bug 75260?
Comment 8 Xisco Faulí 2016-10-07 12:36:27 UTC

*** This bug has been marked as a duplicate of bug 88827 ***
Comment 9 Xisco Faulí 2016-10-07 15:35:19 UTC

*** This bug has been marked as a duplicate of bug 75260 ***