Simple request: make line end (shift enter) work the same as paragraph end with last line setting 'left' for alignment justified. Just looks much better. (Or would that not be conform ODF specifications?)
I'd like to back this report. The line before a line break should be considered a "last line" too. Otherwise this renders horribly. Reproduction: - Have a line with 2 words justified; - add a line break (shift enter). Result: the 2-word line gets expanded (1 word completely left, the other completely right), which is terrible. Expected result: this 2-word line should follow the "last line" rule of your style (left by default).
Adding needsUXEval to discuss that with the design team to get this bug out of the Sleeping Beauty sleep.
@Regina: Is the ODF specification saying something about this behavior?
Created attachment 153073 [details] one picture says more than a thousand words :) have a good meeting today - I'm busy with other tasks, sorry
What is the *intended* use case for the line break? It's often used as a means for moving a word to next line (e. g. to keep with next word) without actually breaking paragraph. One could argue that non-breaking space should be used for that - but NBS has a property being fixed width, while normal space widens in justified alignment, so the line break in some cases is inevitable here to achieve good formatting. IMO, the feature specifically exists for augmenting the automatic line break (when its results don't satisfy user), maybe especially in case of hyphenated paragraphs. In this case, the justification of the broken line should not change. OTOH,it's often used in lists, to add a non-numbered intermediate "paragraph". And it's a bad usage, as there exists a dedicated unnumbered entry. Which is fully suitable for the task (unlike the previous case). There exist many documents, that would break if this is implemented.
I'm in favor of the change that this bug report requests because of many incidents in my own work with LibreOffice especially in lists as Mike said in comment 5. My question is how could it be achieved that the user can do a now normal behavior with justified last line if he wants that after the change regarding this bug?
(In reply to Thomas Lendo from comment #6) Please look at Format->Lists->Insert Unnumbered Entry, which is *specifically* designed for the task. Internally, it creates multiple *proper* paragraphs under a single list item markup. And all the paragraphs have all necessary paragraph formatting options; have proper indents (dependent on the list settings), etc. So - I want to stress it again: as the "manual line break" is explicitly a feature complementing "automatic line break" happening normally when a paragraph needs to continue on a new line, it must follow the behavior on the automatic line break (including the alignment), and only differ in the manual application; and using is to fake paragraphs is *wrong* (just use the proper tool for the task). INVALID IMO (since it tries to *break* the intended usage, trying to make it suitable for a *hack* that shouldn't be used actually).
When I enter a line break in LibO still or master it is left aligned. The same happens with MSO365. Maybe the issue was fixed long time ago?
The issue is still there for me, but I haven't seen a new nightly build since July This seems to be the same issue as in bug 126895, so I'm going to mark that as a duplicate Version: 6.4.0.0.alpha0+ Build ID: 54028dc503fc08eb12e287919d5e2850cff05b73 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-07-31_01:48:19 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
*** Bug 126895 has been marked as a duplicate of this bug. ***
(In reply to Bob from bug 126895 comment #0) > New paragraph was created with Shift-Enter, the only way I know to start > a new paragraph in an outline without it striking a new outline number. I want to repeat once more: the whole thing is because of using wrong tool tof the task. Manual line break feature *is not* starting new paragraphs: it's just a manual override for *automatic line break*, and must behave identically to that automatic line break (except for manual application), just like manual hyphenation (e.g. using soft hyphen) compared to automatic hyphenation, etc. There is a *proper, dedicated* tool for the said task: Insert Unnumbered Entry (available in menu Format=>List, on Bullets and Numbering toolbar, and available for customization like assigning a keyboard shortcut). It inserts the unnumbered *paragraph* *into the list*, which properly follows the indents of the list.
(In reply to Mike Kaganski from comment #11) Oh by the way: there is already available shortcut for the said function: when you pressed Enter and are now in the beginning of a new *numbered* entry which you need to be *unnumbered*, you just press Backspace. It will become unnumbered, still being part of the same list; and when you finished the paragraph and press Enter, you will get the next numbered entry (which you may turn into unnumbered again). Pressing Backspace twice at that stage would turn numbering off.
Yes, there is this 'Unnumbered entry' command for lists that nobody knows. Seems this is a field for enhancements. So I don't speak about shift+enter in lists anymore. But what's with the reasonableness of justification at the line of a paragraph with a shift+enter line break? Are all people doing it wrong who are suggesting a change of the actual behavior?
(In reply to Thomas Lendo from comment #13) > So I don't speak about shift+enter in lists anymore. > > But what's with the reasonableness of justification at the line of a > paragraph with a shift+enter line break? Are all people doing it wrong who > are suggesting a change of the actual behavior? ... and isn't this trying to discuss something undefined? We already found out that doing that in lists is not correct; personally I don't remember other reasons to use it in context on *this* issue - but if they exist, we need first to hear them to judge. As to "reasonableness": please remember that Shift+Enter is just a *line* break - only *manual* one; and the line breaks happen all the time in paragraphs when text doesn't fit into the line, usually *automatically*; and it's that line break that is the *primary element at which the justification is applied*: the text from one line break to another line break is justified (i.e., whitespaces are enlarged to allow words to start and end at the paragraph boundaries). The *manual line break* is a tool to allow user to *override automatic line break*; the tool allows user to explicitly say that user wants the break happen here, not there; it's not about destroying justification of the text between two line breaks (when one of them is manual).
The ticket went back to sleep for two more years. Point is that a line break in lists is not recommended. No other use case was added - could imagine compatibility to HTML for <P> vs <BR>. Anyway, the request was to "make line break work like paragraph break" and do not justify the text. This is not gonna work as Mike explains in comment 11.