In bug #89714, the comments discussed some improvements to the UI. The UI is confusing. When you create a new Style or try to edit an existing one, the Widow and Orphan controls are checked, which causes the "Do not split paragraph" to be grayed out. Users not paying attention to the semantics of the Widow and Orphan controls (or who just don't understand the metaphor and are simply looking to protect the paragraph from breaking) cannot instantly figure out why that checkbox is disabled. Since there are mutual exlusions in the UI, it should use radio buttons. To apply radio buttons to complex mutual exlusions, we must identify the situations that are exclusive, rather than specific flags: The situations that are exclusive is that we have three ways of controlling paragraph splitting: (1) None, (2) Do not split and (2) Widow + Orphan settings with parameters. Thus: Split prevention: (*) None ( ) Do not split ( ) [ ] Widow Control [ ] Lines [ ] Orphan Control [ ] Lines Nothing is confusingly disabled in the UI. You can activate the radio button at any time. If you select None or Do not split, the checkboxes for Widow and Orphan will clear. If you select the third radio button, the behavior might be that the checkboxes get checked. You then clear the one you don't want. If you clear them both, then the radio button jumps to None. The user should never see an invalid combination like None or Do Not Split, together with the Widow/Orphan boxes being checked. Another possibility: don't show the Widow/Orphan checks and list boxes unless the radio is on the third choice: Split prevention: (*) None ( ) Do not split ( ) Limited split Then: Split prevention: ( ) None ( ) Do not split (*) Limited split: [X] Minimum "Widow" [2 ] Lines [X] Minimum "Orphan" [2 ] Lines If you uncheck the two, radio goes to None, and the Orphan/Widow controls disappear. Orphan and Widow are some kind of typesetting jargon whose metaphor not everyone might understand: (*) Limited split: [X] Minimum top to keep together: [2 ] Lines [X] Minimum bottom to keep together: [2 ] Lines
Kazinator, for me your proposal is confusing, because what is the meaning of "none"? There can be only two possibilities: splitting the paragraph or not not splitting the paragraph. So what happens, if you select "none"? But let's ask design team.
(In reply to Dieter from comment #1) > Kazinator, for me your proposal is confusing, because what is the meaning of > "none"? There can be only two possibilities: splitting the paragraph or not > not splitting the paragraph. So what happens, if you select "none"? > But let's ask design team. Thanks for your comments. None means there is no split prevention. The paragraph breaks abruptly wherever the page (or other container) ends. Then the radio has two choices for how to prevent splits. Keep the paragraph all together, or use widow/orphan controls. I agree that the proposed wording could be improved because it perpetrates semantic double negatives, which is confusing. The entire category is "split prevention" which is a kind of negative: how not to do something, not to split. So then "none" constitutes a double negative. Do not not split: i.e. split arbitrary. It made sense to me at the time, but I also had to think about it for a moment. A somewhat verbose alternative: Allow paragraph to split across page breaks? (*) Split freely at any line of the paragraph. ( ) Do not split; keep entire paragraph together. ( ) Split, keeping some lines together, as specified: [ ] Minimum Top Fragment [ ] Lines [ ] Minimum Bottom Fragment [ ] Lines
Radio buttons are a good way to show the mutual dependency. But Dieter has a point with his questions as "[ ] Do not split" meaning splitting is allowed has no direct consequence to orphan and widow settings (and I'd definitely keep the common terms). It means essentially this (o) Do not split paragraph ( ) Do split paragraph [ ] Orphan control [ ] [ ] Widow control [ ] [x] Keep with next paragraph and I'm not sure it improves usability. The term "Do split paragraphs" is just odd (or in other words the current checkbox is very clear). What we could do is to show the orphan/widow options indented under the split paragraph setting. And we have to invert the logic so split enabled orphan/widow. [x] Split paragraph [ ] Orphan control [ ] [ ] Widow control [ ] [x] Keep with next paragraph
The problem is why these options are considered mutually exclusive. They are not. And they even make sense when used together (at least widows) - in case the paragraph is longer than a page. But the checkboxes were mutually exclusive in the UI already in LO 3.3.
(In reply to Heiko Tietze from comment #4) > Radio buttons are a good way to show the mutual dependency. But Dieter has a > point with his questions as "[ ] Do not split" meaning splitting is allowed > has no direct consequence to orphan and widow settings (and I'd definitely > keep the common terms). > > It means essentially this > > (o) Do not split paragraph > ( ) Do split paragraph > [ ] Orphan control [ ] > [ ] Widow control [ ] > [x] Keep with next paragraph I apologize. I have exclusively focused the discussion on the mutually exclusive elements, and neglected to make any remarks on the "Keep with next paragraph". This option is currently sandwiched between the two settings that are mutually exclusive sets of checks. So the very placement of that is bad. I've used "Keep with next paragraph", but am not sure of the exact semantics, and how it interacts with the split controls. I see you've added the checkbox and simplified my radio button proposal to two choices. The choice to just split the paragraph freely (break it wherever it is physically convenient for the page break to occur). Indeed, the behavior can be obtained by adjusting the Orphan and Widow controls down to one line. I think when we have pared down three choices down to two, we can revert back to a checkbox: [x] Allow paragraph to be split [ ] Orphan control [ ] [ ] Widow control [ ] [x] Keep with next paragraph Uncheck the Allow... and it means do not split. Since we have enable checkboxes already on Orphan and Widow, why have another parent enabler? [ ] Allow paragraph split with [ ] orphan lines [ ] Allow paragraph split with [ ] widow lines [ ] Keep with next paragraph If the widow and orphan checkboxes are not checked, then the paragraph is not split. The logical polarity of "Keep with" could be aligned with the other two. Here is what the defaults would be: everything on, with 2 lines: [x] Allow paragraph split with [ 2] orphan lines [x] Allow paragraph split with [ 2] widow lines [x] Allow break between this and next paragraph Don't want splits and breaks, uncheck things. Nothing is exclusive.
(In reply to Kazinator from comment #6) > I think when we have pared down three choices down to two, we can revert > back to a checkbox: > > [x] Allow paragraph to be split > [ ] Orphan control [ ] > [ ] Widow control [ ] > [x] Keep with next paragraph This looks good to me. It's easy hackable, keeps the UI familiar, and allows to disentangle the options later, as suggested by Mike in comment 4. Code pointer: cui/uiconfig/ui/textflowpage.ui cui/source/tabpages/paragrph.cxx
(In reply to Samuel Mehrbrodt (allotropia) from bug 156795 comment #0) > "Orphan" and "Widow" are typesetter terms which are well known in the > typesetting sphere, but unknown and confusing to the average user. > > Instead of using these terms, we should use descriptive terms. Note that > Word, InDesign avoid using the terms "Orphan" and "Widow" too. > > I would suggest reorganizing/renaming the options as follows: > ... > - Beginning of paragraph : _2_ lines > - End of paragraph: _2_ lines Removed the re-position idea to focus on terminology. My take: orphan/widow is common and changing it would be more disturbing to our users.
*** Bug 156795 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from Bug 156795 comment #2) > (In reply to m.a.riosv from comment #1) > > Sounds fine, but I think better maintain between parenthesis the original > > words. > > +1 for retaining them in parenthesis, and there will need to be adjustment > to the help article(s).
Fixed this as part of the renaming/reorganizing in bug 156795: https://gerrit.libreoffice.org/c/core/+/155769
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/47edf86a62784aa275de7cc89df01a4fcd4e90c8 tdf#156795, tdf#156109 Avoid typesetter language: orphan, widow control It will be available in 24.2.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.