Bug 99027 - [FORMATTING] Default table border width is useless
Summary: [FORMATTING] Default table border width is useless
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0
Keywords: needsDevEval, needsUXEval, topicUI
: 83427 (view as bug list)
Depends on:
Blocks: Cell-Border 107554 Table-Borders Writer-Tables-Enhancements
  Show dependency treegraph
 
Reported: 2016-04-01 13:55 UTC by Nicolas Mailhot
Modified: 2018-01-12 17:59 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Border Overview (338.81 KB, application/pdf)
2017-05-10 18:17 UTC, andreas_k
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Mailhot 2016-04-01 13:55:05 UTC
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.
Comment 1 Buovjaga 2016-04-09 18:22:46 UTC
UX: should the default be changed?
Comment 2 Heiko Tietze 2016-04-10 10:21:20 UTC
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 ;-)
Comment 3 Nicolas Mailhot 2016-04-11 14:36:34 UTC
Default table border width should be what users expect, ie the usual border width of a table in documents, without strange unusual air-thin styling. Around 1pt or so I think.
Comment 4 Michael Stahl (CIB) 2016-04-11 14:55:12 UTC
i believe the 0.05pt width is intended to be a "hairline" that is always 1 device pixel "thick".

there might be bugs in the handling of that, see for example bug 40289
Comment 5 V Stuart Foote 2016-04-11 15:41:51 UTC
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.
Comment 6 Nicolas Mailhot 2016-04-11 17:05:07 UTC
(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.
Comment 7 Yousuf Philips (jay) (retired) 2016-04-11 18:36:19 UTC
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.
Comment 8 Jean-Francois Nifenecker 2016-04-12 05:05:51 UTC
(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.
Comment 9 Yousuf Philips (jay) (retired) 2016-04-12 10:48:12 UTC
(In reply to Jean-Francois Nifenecker from comment #8)
> BTW, will table styles propose a hierarchy/inheritance?

Yes table styles will support inheritance as it is part of the ODF standard.
Comment 10 Nicolas Mailhot 2016-04-12 13:14:56 UTC
(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
Comment 11 Robinson Tryon (qubit) 2016-08-25 05:49:19 UTC Comment hidden (obsolete)
Comment 12 Buovjaga 2017-02-11 20:17:54 UTC
*** Bug 83427 has been marked as a duplicate of this bug. ***
Comment 13 andreas_k 2017-05-09 21:12:34 UTC
LaTeX: 
The default thicknes is 0.08 em (= 1.0 pt) for \toprule and \bottomrule and 0.05 em (= 0.6 pt) for \midrule.
Comment 14 andreas_k 2017-05-10 18:17:40 UTC
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.
Comment 15 Yousuf Philips (jay) (retired) 2017-05-11 18:29:07 UTC
(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.
Comment 16 andreas_k 2017-05-11 20:28:17 UTC
+1 for 1.0pt for default as the border is thick users will use them only when really needed and maybe make the padding larger so I am for 1.0pt as default.
Comment 17 Yousuf Philips (jay) (retired) 2017-05-12 09:44:43 UTC
@Cor, @Regina, @Sophie: Any recommendations on what you think the default table borders should be.
Comment 18 Cor Nouws 2017-05-12 13:39:53 UTC
(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.
Comment 19 Yousuf Philips (jay) (retired) 2017-11-06 22:30:43 UTC
(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
Comment 20 sophie 2017-11-07 10:41:57 UTC
(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
Comment 21 Commit Notification 2017-11-08 13:49:44 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bab20c21288ace0791cf4f43bc646d88c8712e8a

tdf#99027 Use 0.5pt border size with toolbar control

It will be available in 6.0.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.
Comment 22 Yousuf Philips (jay) (retired) 2017-11-08 20:07:40 UTC
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
Comment 23 Jim Raykowski 2017-11-09 09:18:39 UTC
(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
Comment 24 Yousuf Philips (jay) (retired) 2017-11-09 09:24:56 UTC
(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.
Comment 25 Jim Raykowski 2017-11-09 09:43:52 UTC
(In reply to Yousuf Philips (jay) from comment #24)
> (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.

Changing "lower" to 0.50 seems to work. I might be missing something?
Comment 26 Yousuf Philips (jay) (retired) 2017-11-09 11:07:08 UTC
(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.
Comment 27 Jim Raykowski 2017-11-09 18:04:27 UTC
(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>
Comment 28 Yousuf Philips (jay) (retired) 2017-11-10 22:30:38 UTC
(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?
Comment 29 Jim Raykowski 2017-11-11 00:24:26 UTC
Hi Jay,

I have had the same question about why this didn't work as expected.

Here is a code pointer to what happens when GtkSpinButton is parsed

https://opengrok.libreoffice.org/xref/core/vcl/source/window/builder.cxx#1296

It looks like what comes after the ":" is used as a pattern to define units.