Created attachment 168131 [details] Writer file showing problem with bottom padding Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded 1. Open the attached file. Open "Heading 1 (paragraph style) > Borders" and verify that changing the bottom padding works as expected: with "Synchronise" ON or OFF. 2. Now Open "Heading 2 (paragraph style) > Borders" and do the same. There are no borders but the padding should still affect the Area. EXPECTED RESULT: Bottom Padding should move the area colour outwards: whether "Synchronize" is OFF or ON. ACTUAL RESULT: Bottom padding doesn't affect Area when "Synchronise is OFF (unticked).
I can't confirm this with Version: 7.2.0.0.alpha0+ (x64) Build ID: 315c7570c4a72f4c834086082825533b1e50d1bf CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded Works as expected (with synchronise on and off) ould you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ or with a master build from http://dev-builds.libreoffice.org/daily/master/current.html? You can install master alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
Dear R. Green, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: c703b2d22c3f45825d9c9d790c3b5a4b6f97e776 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-17_00:44:32 Calc: threaded The bug is still there in this version. If "Set no borders" is selected, the BOTTOM PADDING value is non-functional (but Top, Left and Right Padding work as expected).
Bibisected with linux-64-6.3 to https://git.libreoffice.org/core/commit/ba5eaf86a84212ab70424fc83464acec5b0d51a0 Resolves: tdf#122914 missing save_value
I don't think this is a dialog issue. I think "Resolves: tdf#122914 missing save_value" by removing the extra unwanted shadow setting might have just made this apparent oddness more obvious. My feeling is that the issue is how "merge with next paragraph" works. If the left and right padding is the same, then the "Heading 2" paragraph matches the next one. Likewise the previous "Default Paragraph Style" matches the following "Heading 2" paragraph. The bottom padding is not used when it matches the next para and the top padding is not used if it matches the previous paragraph (because of that ones "merge with next paragraph" setting. And once left or right is set then it doesn't "match" anymore and the top/bottom padding gets used.
Created attachment 180041 [details] smaller reproducer to illustrate what I mean So in this case, Heading 2 starts off with top 1cm, bottom 2cm, left and right of 0 and there is no use of the top/bottom because of the "matching" idea. if heading 2, "merge with next paragraph" is turned off then the bottom is used. if the "merge with next paragraph" of "default paragraph style" is unset then the top of the heading 2 text padding is used. if instead I just change left or right of "heading 2" then it doesn't match anymore and both top and bottom are used.
It is complicated, see the specification of attribute style:join-border. https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#property-style_join-border
yeah, looks tricky but I think this is basically working as it is supposed to. And the dialog was tweaked in the identified commit to not add extra properties not selected by the user which stopped it making the border/spacing properties not "match" the following paragraph.
Created attachment 180498 [details] Demonstration of need for left or right padding to get bottom padding, without using border In testing the behavior of padding, with an eye to improving the documentation, encountered this ticket. Like R. Green, have sometimes experienced that bottom padding is added when a border is turned on, otherwise not (which makes me uncertain about the "expected" behavior to be documented). Meanwhile -- attachments demonstrate: 1. adding "left" or "right" padding together with "bottom" padding DOES give bottom padding (without use of border) (attached here) 2. bottom padding alone, without border, gives no padding, UNLESS paragraph is EOD. (attached in next comment) Also -- using "small reproducer" (attachment 180041 [details]) -- if the "left padding" in H2 "Borders" paragraph is set to 0, then the bottom padding disappears. Tests using 7.2.6.2 and 7.4.0.0.alpha1+ No claims made about "expected" behavior. Rather -- seeking advice/insight about "expected" behavior in order to evaluate whether the following sentence about "padding" (from online help [1]) is accurate: Specify the amount of space that you want to leave between the border and the contents of the selection. [1] https://help.libreoffice.org/7.4/en-US/text/shared/01/05030500.html?&DbPAR=WRITER
Created attachment 180499 [details] Demonstration that bottom padding is shown at EOD, otherwise not for paragraphs without borders Demonstration of EOD effect for bottom padding, as discussed in previous comment.
(In reply to Caolán McNamara from comment #5) > And once left or right is set then it doesn't "match" anymore and the > top/bottom padding gets used. I guess this is the "wheel" that I have rediscovered? as demonstrated in attachment 180498 [details]. strange behavior imo. Maybe NeedsUXEval?