Description: With mixed values, Format menu > Paragraph dialog sets paragraph margins to about 100 yards and First Line to about a yard on 8.5"x11" paper. Steps to Reproduce: 0. Either use the attachment with this topic and skip to step 5; or do the following. 1. Create or open a letter that uses letter-size paper, has all margins at 1", uses one font (I use DejaVu Serif) and one font size (I use 13 pt), and has Line Spacing at single. I don't name styles. 2. Set the body paragraph/s to have indents thus: Before Paragraph, 0" (zero); After Paragraph, 0"; First Line .75"; Above Paragraph, 0.08"; Below Paragraph, 0". 3. Just before the body, have one paragraph, like the line that says "Dear So-and-so", with First Line at 0", but with other settings like those for the body. 4. Just after the body, have one paragraph, like the line that says "Yours truly" or "Sincerely", with First Line at 4", but with other settings like those for the body. 5. Now decide on a new value for Above Paragraph for the whole letter, say, 0.04". Select All and expect to set the new value. (The same thing will happen if you select either the greeting paragraph and the first body paragraph or, on the other hand, the last body paragraph and the closing paragraph. It won't happen if you select only one paragraph or part of one or if you select only consecutive paragraphs that have the same style.) Actual Results: Indent before text is -3,936.61″, which is about 100 meters or yards. Indent after text is -3,936.61″, which is about 100 meters or yards. First Line is -39.37″, which is about a meter, or a little over a yard. If you click OK, it carries out what's in the dialog's fields. (If you don't like the result, you can undo.) Expected Results: Indent Before Text and First Line to be blank, since values are mixed and mixed values are not displayed. Indent After Text to be zero, since it's zero for all selected paragraphs. Reproducible: Always User Profile Reset: No Additional Info: Reproducibility is likely always. I don't seem to have a User Profile reset or an OpenGL option. With version 6.3, I had a similar experience (I didn't get around to submitting a bug report yet). However, with a document saved in LO 6.3 and opened in LO 7.0, the indent before or after text was -3,930.41', which is about 0.2% different from the actuality reported above.
Created attachment 167922 [details] Document for testing.
Created attachment 167923 [details] Image of erroneous dialog.
Created attachment 167924 [details] Image of result of clicking OK in dialog.
I can't reproduce this. I tried with bibisect-linux-x64-7.0 on oldest and last70onmaster. The steps I took were 1.) Open Test-Doc.odt 2.) Ctrl-A to select all 3.) Format - Paragraph properties. At this point, the top three items are completely blank (since they have differing values in the selected paragraphs). Above Paragraph says 0.37 line. If I change Above Paragraph to 0.04, then everything looks as expected.
I can't either, and I'm the original reporter. I newly tested on version 7.0.4.2. However, while at first I thought maybe this was fixed in between versions, perhaps as an unnoticed side effect of some other change, and was going to set the status as resolved/worksforme, I encountered another version of the problem. I now think there's a predicate condition I haven't identified. Something needs to be added to the STR, but I don't know what it is. This time, I found that with mixed unnamed styles and Select All I got values of -24.51" before and after text, -39.27" for the first line, 3.94" above and below paragraphs. The before and after should have been zeros and the others should have been blank. That's a lot less crazy than the previous version of the problem, but it's still pushing text off the page. I'm uploading an image of the Format > Paragraph dialog. Then I tried something else, twice. I created a new document, wrote a word as a paragraph (thus a one-line paragraph), cut and pasted the paragraph to go into 2 pages, Selected All, and found Format > Paragraph was as expected. Then I set the first paragraph only for Before Paragraph to 1" and Selected All. This time the dialog had blank values for Before Paragraph (that's correct) and for After Paragraph and First Line (those are wrong). Whether I had saved the document didn't matter; I tried both ways. (I didn't keep images of this.) I don't know how to diagnose this further.
Created attachment 168543 [details] Screenshot (with two lines of my address redacted as irrelevant).
Hi Nick. I played with it a little bit more again, and still couldn't reproduce. Can you provide your Linux distribution and desktop? (I am testing with Ubuntu 20.04 and Cinnamon desktop.) Copy/paste from help about is: Version: 7.2.0.0.alpha0+ Build ID: 32df28ba6c81a9ff29dfbeb39f2d83917dd69b33 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Something strange things happen because of an old profile. In a terminal, run: rename "s/libreoffice/libreoffice.corrupt/" ~/.config/libreoffice/
Fedora 33 Linux, kept evergreen, including the Gnome 3.38.2 desktop. LO: About: Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 2; OS: Linux 5.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded The terminal command yielded: bash: s/libreoffice/libreoffice.corrupt/: No such file or directory On a lark, I tried the same command with sudo and that got: sudo: s/libreoffice/libreoffice.corrupt/: command not found I have a machine with the same Ubuntu version kept evergreen, albeit LTS, running Gnome 3.36.8. It had the same problem, even though this time Writer used the default font and fontsize (my Fedora machine has those custom-set because I prefer DejaVu Serif 13). On the Ubuntu platform, even though kept evergreen, LO About says this: Version: 6.4.6.2 Build ID: 1:6.4.6-0ubuntu0.20.04.1 CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US; Calc: threaded I logged out of my account on the Ubuntu platform, changed from Ubuntu to Ubuntu on Wayland, logged into the same account, and replicated the problem. (Then I changed back from Ubuntu on Wayland.) I didn't find a way to change my desktop environment, even when warm-booting and checking the one-time boot menu. I may not have another DE now. When I've tried others in the past, and I think I've tried all that were installed with any recent Linux distro, including Cinnamon, I quickly came back to Gnome, and I guess most users of these distros use Gnome, so if Cinnamon makes a difference we should find out why and bring that difference into Gnome. You're running a later LO version, albeit alpha, so maybe it's been cured between my version and yours.
(In reply to Nick Levinson from comment #8) > The terminal command yielded: > bash: s/libreoffice/libreoffice.corrupt/: No such file or directory :-) You need to paste the entire line in the terminal. rename "s/libreoffice/libreoffice.corrupt/" ~/.config/libreoffice/ But since you are able to replicate this on a different computer, it isn't likely to be the profile after all. > You're running a later LO version, albeit alpha, so maybe it's been cured > between my version and yours. I also tried earlier with I tried with bibisect-linux-x64-7.0 on oldest (aka 6.4.0) and last70onmaster. I just tried again with LO 7.0 on gnome, and couldn't replicate the problem. Since you are able to replicate the problem on another computer as well, can you confirm exactly what actions you are doing to replicate it?
I did paste the whole line. I did it again and got this (ellipsizing account & machine names): [. . . ~]$ s/libreoffice/libreoffice.corrupt/ ~/.config/libreoffice/ bash: s/libreoffice/libreoffice.corrupt/: No such file or directory [. . . ~]$ sudo s/libreoffice/libreoffice.corrupt/ ~/.config/libreoffice/ [sudo] password for . . .: sudo: s/libreoffice/libreoffice.corrupt/: command not found [. . . ~]$ The test on the Ubuntu machine was as described in comment 5, in the paragraph that starts with "Then". The default Format > Paragraph values for before, after, and first line were zeros until I changed the before for the first paragraph only.
(In reply to Nick Levinson from comment #5) > This time the dialog had blank values for Before Paragraph (that's > correct) and for After Paragraph and First Line (those are wrong). There is nothing wrong with showing blank values for all three. Internally, all three are stored as a single "item", and so if you change any of the three, this "item" becomes different from the "item" in the other paragraphs.
That's valid for the programming, but it's bad for the UI. The blank for a field should mean that values are mixed for what that field represents, not that some other field is involved and has mixed values. It's confusing to a user. Sometimes, I search a whole document trying to diagnose a result that differs from my knowledge of characteristics I already assigned. When I can't find it, I likely think the software is malfunctioning. I don't know if the better solution is to separate the values in the underlying item or to separate the information from the item before it gets to the dialog UI.
(In reply to Nick Levinson from comment #12) > That's valid for the programming, but it's bad for the UI. The blank for a > field should mean that values are mixed for what that field represents, not > that some other field is involved and has mixed values. It's confusing to a > user. Sometimes, I search a whole document trying to diagnose a result that > differs from my knowledge of characteristics I already assigned. When I > can't find it, I likely think the software is malfunctioning. > > I don't know if the better solution is to separate the values in the > underlying item or to separate the information from the item before it gets > to the dialog UI. Let's ask UX team. Otherwise I guess there is nothing actionable in this report.
(In reply to Nick Levinson from comment #12) > The blank for a field should mean that values are mixed for what > that field represents, not that some other field is involved and > has mixed values. Yes, that's true. Just to advertise the new feature: you get insights to the styles with the Styles Inspector at the sidebar. Mike, the three PS differ only in Para First Line Indent but the properties dialog has empty fields for before/after text and first line and line spacing. I guess we just don't break down the attributes, right?
(In reply to Heiko Tietze from comment #14) > Mike, the three PS differ only in Para First Line Indent but the properties > dialog has empty fields for before/after text and first line and line > spacing. I guess we just don't break down the attributes, right? Yes, as seem at https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/paragrph.cxx?r=8aec73d7&mo=14578&fi=402#493 - unfortunately all three get reset to blanks together in case SID_ATTR_LRSPACE state is less than SfxItemState::DEFAULT. The "combined" items in our internal model, corresponding to multiple user-visible properties, is a plague that affects us in multitude of ways. See also bug 106984 comment 10, where *the same* root cause results in inability to search for some attributes sensibly.
So let's fix it.
Fixed in LO 7.6 by commit db115bec9254417ef7a3faf687478fe5424ab378 Author: Michael Stahl on Tue Feb 14 18:03:55 2023 +0100 tdf#78510 sw,cui: split SvxLRSpaceItem for SwTextNode, SwTextFormatColl
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1349f140fcc49e5da78482ca3db09663ccdae0a9 tdf#138726 LRSpaceItem ooxmlexport12: don't test implementation It will be available in 7.6.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.