The default writer table border width (0,05pt) is so small it is useless.
It seems to work fine when viewed on-screen and rounded to one pixel, but as soon as you try to print the result you realise all the tables lines are air-thin and not presentable.
Many users, afters having to restyle all their tables after the first print test, will conclude the application is not ready.
Hair-thin print borders are no substitute for proper table line shadows when pi-mode is engaged.

The minimum printable width depends on the resolution, and 0.05pt is somewhat about 1200dpi. If we change the default to let's say 0.1pt, it would still require a good printer (setting) of 600dpi. The better solution is to have a user-definable setting which defaults to 0.1pt or 0.2pt. And we should consider what users actually intend with hairlines - the minimum possible size? Is so, it could mean to adopt the value according the printer setting. Sounds weird to me, however ;-)

Sorry don't see any issue with the minimal "hairline" value used as default when tables are created. It is certainly not "useless".
On creation and during editing table border style is fully configurable from the Table Properties dialog found on the Table menu and the Table toolbar.
Using the device minimum setting as default is more commonly useful for composing tables where the border width is only providing a visual que to cell content. Anything more than device minimum becomes a style best applied from the dialog to change from default. In other words the default is correct and useful as is.
Since its setting to .05pt is not a valid value--perhaps it would be less confusing if actually relabeled "hairline" or "minimal" on the dropdown list--beyond that see no no reason to change the UI, or the defaults.

(In reply to V Stuart Foote from comment #5)
> Using the device minimum setting as default is more commonly useful for
> composing tables where the border width is only providing a visual que to
> cell content.
And there is already a setting in LO to show cell border shadows when creating tables with no border. It's not on by default (which is not smart, competition has it on by default), but it exists.
> Anything more than device minimum becomes a style
Well it *is* a formatting setting so it should be useful as a setting, not "let's pick the worst default so everyone is angry and gets to change it". I defy you to find real-world documents with .05pt table borders. Except as art experiment or LO-produced mistakes.

So lets see what the default is with other apps.
0.5pt - MS Word, WPS/Kingsoft Writer, Abiword
1pt - Google Docs, WordPerfect
2pt - Calligra Words
2pt looks horrible visually on the rendered page, so i can only guess how it would look on a printed page. At 100% on my 1600x900 resolution, i couldnt see a rendering difference in LO between 0.05pt, 0.25pt, 0.5pt or 1pt and at 200% there was no difference between 0.05pt, 0.25pt, 0.5pt. So i think using 0.25pt, 0.5pt or 1pt would be a good default and it should be decided based on how it looks when printed and what values we expect users to change the border to. I dont have a printer, so i'll leave it up to those with a printer to decide. :D
(In reply to Heiko Tietze from comment #2)
> The better solution
> is to have a user-definable setting which defaults to 0.1pt or 0.2pt.
Once table styles are done, users will be able to modify the default in the default template.

(In reply to Yousuf (Jay) Philips from comment #7)
>
> Once table styles are done, users will be able to modify the default in the
> default template.
BTW, will table styles propose a hierarchy/inheritance? I deeply miss page styles inheritance and I would very much like that such a drawback doesn't affect the newer table styles functionality.

(In reply to Yousuf (Jay) Philips from comment #7)
> 2pt looks horrible visually on the rendered page, so i can only guess how it
> would look on a printed page.
Rendered is misleading, LO rounds up to the nearest pixel multiple. Since a lot of screens are still stuck in Windows 96dpi hell that tends to exaggerate thickness.
The *actual* line width on a high-dpi medium such as a laser printout is very very very thin for 0,05pt (and if your printer's ink is almost used up, too thin to appear the right color). 1pt is about right (similar width as 11pt sans serif letter stems). 2 pt starts to be heavy

Created attachment 133220[details]
Border Overview
I'll make some tests about border thickness I have 3 test scenarios
1. Look good on the printout and after scanning
2. Look good on the screen when export as pdf
3. Look good on the screen in LibreOffice
attached you have 3 pages 1st is the exported pdf, 2nd is the scann and 3rd a screenshot from the screen.
my result is
------------
1 pt Header row and Total row thickness
+ cause it look thicker on the screen LO and the print show also the separation
+ LaTeX use 1pt and other programms
+ work fine not only for line tables also for background colored table
0,25pt for the other borders
+ There is a visual difference between 1pt and 0,25pt
+ 0,05pt could be a problem on older printers or ink jet printing
+ 0,50pt is the difference between header not that much
If you need I have additional documents.

(In reply to andreas_k from comment #13)
> LaTeX:
> The default thicknes is 0.08 em (= 1.0 pt) for \toprule and \bottomrule and
> 0.05 em (= 0.6 pt) for \midrule.
Well we need a single default thickness for when borders are turned on, so i guess LaTeX is recommending 1.0pt.

(In reply to Yousuf Philips (jay) from comment #17)
> @Cor, @Regina, @Sophie: Any recommendations on what you think the default
> table borders should be.
I would choose one that is visible with printing, and still nicely thin on the screen. Be it 0.5 or 1.0 pt - fine for me.

(In reply to Cor Nouws from comment #18)
> I would choose one that is visible with printing, and still nicely thin on
> the screen. Be it 0.5 or 1.0 pt - fine for me.
So we are going with 0.5pt, as will be used it in the default table style (bug 107554), common default width used in other word processors, and it was the second listbox option found in LO 3.3.
Use 0.5pt with the border toolbar control
https://gerrit.libreoffice.org/44369

(In reply to Yousuf Philips (jay) from comment #19)
> (In reply to Cor Nouws from comment #18)
> > I would choose one that is visible with printing, and still nicely thin on
> > the screen. Be it 0.5 or 1.0 pt - fine for me.
>
> So we are going with 0.5pt, as will be used it in the default table style
> (bug 107554), common default width used in other word processors, and it was
> the second listbox option found in LO 3.3.
>
> Use 0.5pt with the border toolbar control
> https://gerrit.libreoffice.org/44369
+1 on my side too - Sophie

(In reply to Yousuf Philips (jay) from comment #22)
> Can anyone think of any other places this needs to be fixed? The only thing
> that comes to my mind is that if a table has border disabled and they open
> the table properties dialog's borders tab, the width field is at 0.05pt.
>
> Tried altering the spinbox id from linewidthmf:0.00pt to linewidthmf:0.50pt,
> but it would then appear as 9.0050pt in the dialog. Also using
> linewidthmf:0.01pt would turn into 1.001pt.
>
> Jim can you have a look at this?
>
> https://opengrok.libreoffice.org/xref/core/cui/uiconfig/ui/borderpage.ui
> https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/border.cxx
Jay,
The width spin uses the GtkAdjustment 1 object properties. Adjust these values to what you want.
borderpage.ui
6 <object class="GtkAdjustment" id="adjustment1">
7 <property name="lower">0.050000000000000003</property>
8 <property name="upper">9</property>
9 <property name="step_increment">0.25</property>
10 <property name="page_increment">1</property>
11 </object>
GtkAdjustment 2 is used by the padding spins
GtkAdjustment 3 is used by the distance spin

(In reply to Jim Raykowski from comment #23)
> The width spin uses the GtkAdjustment 1 object properties. Adjust these
> values to what you want.
>
> borderpage.ui
> 6 <object class="GtkAdjustment" id="adjustment1">
> 7 <property name="lower">0.050000000000000003</property>
> 8 <property name="upper">9</property>
> 9 <property name="step_increment">0.25</property>
> 10 <property name="page_increment">1</property>
> 11 </object>
Hi Jim,
I'm aware of those entries and adjusting them wont give the wanted result as none of them mention what the initial width should be, which the 0.00pt of linewidthmf:0.00pt is being used to do so. It is something that needs to be looked into in the code.

(In reply to Jim Raykowski from comment #25)
> Changing "lower" to 0.50 seems to work. I might be missing something?
Changing that would mean that a user can no longer set it to 0.05pt, which is wrong as many tables have this set to this value.

(In reply to Yousuf Philips (jay) from comment #26)
> (In reply to Jim Raykowski from comment #25)
> > Changing "lower" to 0.50 seems to work. I might be missing something?
>
> Changing that would mean that a user can no longer set it to 0.05pt, which
> is wrong as many tables have this set to this value.
Ahhh right, the "value" property is what we need for initialization.
<object class="GtkAdjustment" id="adjustment1">
<property name="value">0.50</property>

(In reply to Yousuf Philips (jay) from comment #22)
> Tried altering the spinbox id from linewidthmf:0.00pt to linewidthmf:0.50pt,
> but it would then appear as 9.0050pt in the dialog. Also using
> linewidthmf:0.01pt would turn into 1.001pt.
Maxim: Any thoughts on this?