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.
UX: should the default be changed?
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 ;-)
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.
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
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 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.
(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
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
*** Bug 83427 has been marked as a duplicate of this bug. ***
LaTeX: The default thicknes is 0.08 em (= 1.0 pt) for \toprule and \bottomrule and 0.05 em (= 0.6 pt) for \midrule.
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.
+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.
@Cor, @Regina, @Sophie: Any recommendations on what you think the default table borders should be.
(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
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.
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
(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 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?
(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?
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.
It's seem also happen with Calc. But if in Calc you got 0.05pt when using border toolbar and got 0.75 when using Format - Cell menu.
LibreOffice Impress 7.0 beta1+ also has had this issue. Default Table Border width is too thin (0.05 pt) using border toolbar. Making this invisible when printed.
The "Default" border line is 0.5pt - we updated the TS some time ago and might have fixed it back then.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c84ec0b1debb9b72f05ffc1d669608afc454cec2 tdf#99027 Set default table border width to 0.5pt It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/9237cce9ac9d339f179585f722a8ef0e88be64e3 tdf#99027 Set default table border width to 0.5pt It will be available in 7.3.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.