The 8th from the top for me is not a solid line, but a two-line style. Can you show a screenshot of how it looks like in the selector?

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.2.3.3
Build ID: 5.2.3-1
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group

Created attachment 128820 [details]
Requested Screenshot

Request: "The 8th from the top for me is not a solid line, but a two-line style. Can you
show a screenshot of how it looks like in the selector?"

See screenshot - 8th from the top - NOT counting "none".

Ok, so this is about the difference between the toolbar button display and the dialog display. I confirm the problem.

Jay: I can't find an existing report, but I have a vivid memory of there being one for this. Somehow I think you were involved.

Wasn't in the meta bug either https://bugs.documentfoundation.org/showdependencytree.cgi?id=103100&hide_resolved=1

No no, I'm afraid it's not at all about that (although I DO think that the menu selection for border styles should numbered, as it is very confusing to remember what style is what - but that is a secondary issue).

This bug is about this: When you make a table, and set the border style of that table to number 8 (see above), then save that file, then copy/paste the file into a new folder, then open that NEW (result-of-a-paste) file, the border style in this new document will be visually different. It will be a two line border.

See screenshot. 

Thanks.

Created attachment 128831 [details]
Screenshot of table border after file has been pasted into another folder

(In reply to mkflan from comment #4)
> No no, I'm afraid it's not at all about that (although I DO think that the
> menu selection for border styles should numbered, as it is very confusing to
> remember what style is what - but that is a secondary issue).
> 
> This bug is about this: When you make a table, and set the border style of
> that table to number 8 (see above), then save that file, then copy/paste the
> file into a new folder, then open that NEW (result-of-a-paste) file, the
> border style in this new document will be visually different. It will be a
> two line border.
> 
> See screenshot. 
> 
> Thanks.

No, no, no :P The bug is about this: when you do all that border jazz *with the toolbar button*, then save, then reload, the border changes to the two line style. There is no need to copy & paste the file anywhere.
When you use the table properties dialog, the 8th style is double already in the selector and what you see is what you get - no need to reload.

I have a distinct memory of testing this before and I tried a hundred different ways of searching through our reports, but unfortunately nothing turned up.

Hoping Jay has experience with this.

Ah yes! I see what you're saying now. I didn't know about that table properties dialog. I was just using the thing at the bottom.

I still think the borders should be numbered, though (my 2 cents) - there's a lot of them.

Thanks!

(In reply to Buovjaga from comment #3)
> Jay: I can't find an existing report, but I have a vivid memory of there
> being one for this. Somehow I think you were involved.

Buovjaga: Dont remember anything like this and unable to reproduce it with master. The only bug the comes to mind relates to calc (bug 79787).

(In reply to mkflan from comment #7)
> I still think the borders should be numbered, though (my 2 cents) - there's
> a lot of them.

They should be labelled similar to how draw line styles are labelled (bug 101886).

If the issue is about which entries are shown in the toolbar versus the ones shown in the dialog, there isnt a problem there, as the toolbar one has to show more as you cant adjust the line width in the toolbar, but if you set the 1pt solid line entry 8 in the toolbar and then open the dialog, the same list will appear in the dialog.

(In reply to Yousuf Philips (jay) from comment #9)
> If the issue is about which entries are shown in the toolbar versus the ones
> shown in the dialog, there isnt a problem there, as the toolbar one has to
> show more as you cant adjust the line width in the toolbar, but if you set
> the 1pt solid line entry 8 in the toolbar and then open the dialog, the same
> list will appear in the dialog.

No, it's about entry 8 selected from the toolbar appearing as a solid line and changing to a double line after save and reload.

(In reply to Buovjaga from comment #10)
> No, it's about entry 8 selected from the toolbar appearing as a solid line
> and changing to a double line after save and reload.

Can you give the steps to repo this, as i couldnt repo it, and the summary needs to expressly mention this issue as now it isnt clear.

(In reply to Yousuf Philips (jay) from comment #11)
> (In reply to Buovjaga from comment #10)
> > No, it's about entry 8 selected from the toolbar appearing as a solid line
> > and changing to a double line after save and reload.
> 
> Can you give the steps to repo this, as i couldnt repo it, and the summary
> needs to expressly mention this issue as now it isnt clear.

I'll quote the description modifying it a bit:

1. create document
2. create table and select all of it
3. apply border style using the toolbar button - specifically the SOLID LINE border style that is eighth from the top (not counting "None")
 - this border style is a solid line
4. save the document
5. reload it
the table style is now a two-line style

So this issue happens to the following toolbar control entries

1) entry 5: 1.00pt dialog style 9 which reopens as 1.55 pt dialog style 7
2) entry 7: 1.00pt dialog style 11 which reopens as 2.35 pt dialog style 7
3) entry 8: 1.00pt dialog style 12 which reopens as 1.50 pt dialog style 7
4) entry 10: 1.00pt dialog style 14 which reopens as 2.35 pt dialog style 7

LO 3.5 has a different set of styles in the border style toolbar control.

I still can reproduce it with

Version: 6.2.0.0.alpha1+ (x64)
Build ID: 8274c4c62df5b937b3f0bec9e1eeca85f3b219d4
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-22_01:47:50
Locale: en-US (de_DE); Calc: CL

Still present in

Version: 7.2.1.2 (x64) / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

My previous commnt was too quick. We have the following situation:

1. create document
2. create table and select all of it
3. move cursor over the eighth border style using the toolbar button (not counting "None") => First problem: toolbar shows a solid line, but toolbar says "Thick, Thin, Small Gap"
4. Apply that border => table gets a solid line (confirmed in border tab in table properties dialog: Solid line, but tooltip "Thick, Thin, Small Gap")
5. Save the document
6. Reload it

Actual result:
Table has a double line (see border tab in table properties dialog)

Expected result:
Solid line or "Thick, Thin, Small Gap"

Additional observation
Same result with table properties dialog. => I changed bug summary

Bug still present in

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL threaded