Description: Sometimes text is well ordered in tables. I like text to start at the beginning of the table, especially with a thin black lower cell-border. When i have text with no indent in the cell and switch the lower line from unvisible to thin black, the text gets indented by 1 mm or so. This happens on both ends. Steps to Reproduce: 1. write text in a table 2. make sure there is no padding 3. make the lower line visible black Actual Results: the text gets indented by 1 mm Expected Results: make the lower line black, nothing else Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36
Created attachment 140565 [details] Screenshot
I confirm this with Version: 6.1.0.0.alpha0+ (x64) Build ID: d64ce643275e0b2b0dea9e532fc261391dc8793c CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-01_03:24:30 Locale: de-DE (de_DE); Calc: CL Steps to reproduce 1. write text in a table 2. make sure there is no padding 3. make the lower line visible black 4. text gets intended by 1mm on all sides 5. set cursor within the text => open table properties => padding shows 0,00cm 6. mark the whole cell => open table properties => padding shows 0,1cm Perhaps there is a reason why there is a difference between setting a curos in the cell and mark the cell, but I dont understand it.
(In reply to Dieter Praas from comment #2) > setting a curos setting the cursor
Thank you, at least a workaround,. The second point is also responsible for having trouble with changing the attributes on columns. LibreOffice is at this point a bit clumsy, compared to MS-Office
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
There is neither RESOLVED - FIXED nor RESOLVED - WORKSFORME, only RESOLVED. It is, indeed. But i won't change the status at this moment.
To be clear: the padding is no more 0,10 cm, it jumps to 0,05 instead, but i can change it to 0,00.
Reproduced in: Version: 7.2.0.0.alpha0+ (x64) Build ID: c0eee433e079d8e3413f4691607e075b99af92b0 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: en-US Calc: threaded
When I test it in version 3.3, there is padding same as I setted, but only when I make visible the bottom border. When I wisible all borders around the table, the padding increase again.... I don't know, if set version to OOo or it is regresion, because behavior is diffrent. LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
This behavior starts in LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
If I understand this correctly, this will be a WONTFIX. When I create a table without any borders, I can see that the padding in the table border properties is zero. As soon as I introduce a border, the padding changes to 0.05 cm. That is very intentional. When there is no border, then zero padding is what is actually happening - so that is correct. Normally, when people add a border, they won't want it touching the text, so by default a minimal padding is added by default when the borders are turned on. By default the padding is synchronized on all four sides. It is up to the user to adjust the settings from there as they see fit for their specific application. Those are very good default settings. I'm asking UX to mark as WONTFIX if they agree. Please correct me if I have misunderstood the bug report.
(In reply to Justin L from comment #11) > I'm asking UX to mark as WONTFIX if > they agree. Please correct me if I have misunderstood the bug report. cc: libreoffice-ux-advise@lists.freedesktop.org
Yes, now everything is fine. I would even say it is fixed.
(In reply to Frank from comment #13) > Yes, now everything is fine. I would even say it is fixed. No, it is not. Of course, if i would add a border, where there was none, text should have a distance from that border. The thing is, if i put the border UNDER the text, it would not need a distance ON THE LEFT. Libre Office is able to define the padding on all 4 sides, but changes them all at once.
Table > Insert > "Default Table Style" uses 0.10 cm padding. But neither "None" or the toolbar widget has such padding defined (and comes with no border). The dialog offers a couple of table styles. Likewise the Stylist does but has no UI yet, see bug 105933. The paragraph style "Table Contents" has no spacing/indentation defined. This sounds like good default settings to me.