For the sake of translators understanding, please let's improve the terms used in the recent manual break developments: "Restart location" -> "New line restart location" "[None]" -> "Next line" "Right" -> Next clear line on right "Left" -> Next clear line on left "Next full line" -> "Next Full Line" https://help.libreoffice.org/master/en-US/text/swriter/01/04010000.html?&DbPAR=WRITER&System=UNIX
In what scenario is the restart location available? Looking at SwBreakDlg::CheckEnable() in sw/source/ui/chrdlg/break.cxx makes it not clear to me.
Does the Help page link in Description helps?
It does not. The ui file contains a dropdown with the mentioned content but I have no idea under what circumstances it is shown.
New feature, apparently not in master when I built.
Feel free to tweak the strings if it helps UX. I hope that the blog post explains what the none, left, right and all cases do: it's a challenge to describe all of these with a few words. But I'm not emotionally attached to the current UI strings. :-)
(In reply to Olivier Hallot from comment #0) > "Restart location" -> "New line restart location" > "[None]" -> "Next line" > "Right" -> Next clear line on right > "Left" -> Next clear line on left > "Next full line" -> "Next Full Line" Since the feature was implemented mainly for compatibility reasons we should care about at least similar wording. What I found is [1] with the same nomenclature as used now, [2] is not really informative. So how is it implemented/named in MSO? [1] http://officeopenxml.com/WPtextSpecialContent-break.php [2] https://www.officetooltips.com/word_365/tips/line_breaks_in_a_word_document.html
MSO only has UI to insert the clear=all case. The ribbon has a Layout tab, which has a Page Setup group, part of that is a Breaks dropdown. Inside that, there is a Page Breaks section, and one item there is Text Wrapping. (If you find it confusing that they present a line break inside a page break section, you're not alone.)
How about: "Restart location" - keep it; short and precise "[None]" -> "Next line"; much better than [None] and sounds familiar to the common LB "Right" -> keep; short and precise enough with the title caption "Left" -> keep "Next full line" -> keep; short and makes the difference to "Next Line" clear Seth, what do you think? Code pointer: sw/uiconfig/swriter/ui/insertbreak.ui
(In reply to Heiko Tietze from comment #8) > How about: > "Restart location" How about: Restart position - because command is used to position text in relation to objects > "[None]" -> "Next line" Concur. Also in OP > "Right" -> keep; > "Left" -> keep Undecided. Diverges from OP. See question 3 below. > "Next full line" Concur. Also in OP. Observations and questions. 1. In a "normal" text paragraph, all 4 options give exactly the same result. (correct?) => Help page should indicate that "Line break" "Next line" is sufficient for introducing a line break in a text-only paragraph. 2. => Help should emphasize that the other options are only relevant when positioning text in relate to embedded objects. 3. Are Left and Right really needed? Place a shape or frame in the middle of a text. Place cursor in text to right of shape. LB - "Next line" and LB - "Right" give same result. LB - "Next full line" and LB - "Left" give same result. I also tried two shapes (next to each other, with cursor in between) and with cursor after the two shapes. Miklos' blog gives impression that Left and Right might be useful when there are shapes on the right side of the canvas? So far it seems like everything that can be done with Left and Right, can also be done with Next Line (none) and Next Full Line. What am I missing (in my first encounter with LB, Left, Right, etc.)?
> 3. Are Left and Right really needed? See the URL of this bug, I created screenshots to show how the left/right/all cases differ when you have multiple images intersecting with a line of text.
@Miklos -- I was hoping you would tell me something like the following: Left = Start next full line after ALL objects (anchored to paragraph) that have some part horizontally to the left of current cursor position. (If no parts of objects are left of the cursor position, then break to next line). Right = Start next full line after ALL objects (anchored to paragraph) that have some part horizontally to the right of current cursor position. (If no parts of objects are right of the cursor position, then break to next line). Does that give a complete and accurate description of the expected behavior? (only tested with anchor "to paragraph" Do these rules also apply with ”to character” anchors?)
This sounds correct. This is meant to work with any kind of fly frames, so anything other than as-char should work.
Created attachment 179527 [details] test file to experiment with Left and Right Have attached a test file (a paragraph with four shapes) that can be used for testing. How to play the game. Place your cursor ANYWHERE in the paragraph. Use line break, with LEFT or RIGHT. Before clicking OK, predict what will happen. Meanwhile ... started to think about what labels to use for "Left" and "Right". If my rules are correct then the Restart position is: Left = After all objects to left of cursor position Right = After all objects to right of cursor position ---- Would the following be minimally acceptable in the dropdown box? Left objects Right objects In the context of the dialog box, you have chosen "Line break" and then click in the "Restart position" dropdown box. The "cue" of "Left objects" is to remind/highlight: Objects to the left of the cursor position. The assumption is that after you have read the excellent help page and understand how it works (or now I have more or less written possible extended tooltips), then (a) you place your cursor in the paragraph where you want the break, and (b) choose "Left objects", which reminds you -- all objects to the left of the cursor. Left/Right alone seems too minimal, because it does not remind that left/right is about "objects in relation to cursor" I guess that is my opinion for now.
Type o Line Break Position of next line in paragraph: Next line After all objects After all objects to right of cursor After all objects to left of cursor ------------------- From reading BZ entries, one learns that (some? many?) Eve users want the UI to be "intuitive" or "self-explaining" -- without having to read the help. Here is a proposal that might satisfy Eve users and maybe not too bad for Benjamin. And I believe it would be easier to write accurate "help" pages in relation to these options.
(In reply to sdc.blanco from comment #14) Don't get the difference between "After all objects" and "After all objects *" from reading the options. Sounds like "superordinate object". Would go with a shorter "Left/Right after object" and defer to the (online) help.
(In reply to Heiko Tietze from comment #15) > Don't get the difference between "After all objects" and "After all objects > *" from reading the options. Yet another Eve user who expects immediate understanding from words alone. ;-) Please try the following. Open the attachment. Place the cursor on the word "law" or "nervously" (you will find them between the two trapezoids). Then make line breaks from that word using: (Next Full Line) After all objects (Right) After all objects to right of cursor (Left) After all objects to left of cursor And maybe also try with the word "pulled" in the upper right corner. I would strongly encourage you, before hitting OK each time, to predict where the line break will appear. After that experience, it should be easier to discuss the situation.
(In reply to sdc.blanco from comment #16) > (In reply to Heiko Tietze from comment #15) > > Don't get the difference ... from reading the options. > Please try the following. ... before hitting OK each time It's "Save Changes" :-). My comment was based on the idea to understand a function from reading the label and the fact that your proposal is quite long. As always, no need to follow my input. What you do is usually well thought out and I just add ideas for consideration.
(In reply to Heiko Tietze from comment #17) > It's "Save Changes" :-). I take this to mean that you have come to appreciate that the behavior of the line breaks is complex. It might be an advantage to have accurate descriptions, even if a bit long and not fully obvious from reading alone, because once you understand the "logic" of the breaks, then I believe my proposal gives the right "memory cue" to be able to predict/remember accurately what will happen. (should also make it easier to write accurate help pages) Will wait to hear from others, especially from OP...
(In reply to sdc.blanco from comment #18) > a bit long and not fully obvious from reading alone... Not a blocker for your proposal, just to note: Keep localization in mind. And the UI scales according to the largest content.
(In reply to Heiko Tietze from comment #19) > Keep localization in mind. Proposal in comment 14 seems translation-friendly in terms of understanding (i.e., familiar nouns and adjectives, simple prepositions, no special grammatical demands). > And the UI scales according to the largest content. The Spanish translation might be pretty long. In that connection....to gain some more room in the "to" field ... Could the Vertical and Horizontal control widths be reduced? At present, there is a least a cm of white space in the drop down menu. Also the "by" field could probably be reduced a little. And there is already bug 148512 to address the "to" field. (and ftr, such UI adjustments are beyond my possibilities. Presumably it is preferred that these changes are achieved before July string freeze.)
As an "RTL/CTL guy", I'd like to remind everyone to make sure and distinguish between the left edge of a line, and the start of line. In LTR direction they are the same, while in RTL they're the opposite of each other, with lines starting on the right. (LO in general doesn't properly support Start/End vs Left/Right, see https://bugs.documentfoundation.org/show_bug.cgi?id=131192) So, ideally, there would be separate Start, End, Left and Right options; but at the very least - please decide whether you really mean Start and End rather than Left and Right, i.e. think of what these breaks are supposed to do in an RTL paragraph.
In RTL there is currently bug 148291 and in CTL bug 148289. Eyal, do you know an application with a similar feature which works for RTL? Then please add the observed behavior there to bug 148291.
We discussed the topic in the design meeting. To summarize, me prefers a simple solution (comment 8), Seth proposes a more verbose solution (comment 14), and Eyal commented to better use Start/End. What we not discussed but might be the best solution is to show a thumbnail that illustrates what "Start (Left)" and "Full Line Next" means.
(In reply to Heiko Tietze from comment #23) > Eyal commented to better use Start/End. Let me expand my comment and go beyond what I said in the design meeting. First, I have to say that this feature is difficult to understand. Even looking at the help page, it's difficult to understand. Yes, a preview would help (I don't have a nightly with that right now), but it still feels like a complicated niche situation which takes a lot of explaining for a user to understand. It took me quite a while to manage to differentiate a "Right" from a "Left" case on the attached document. And this is regardless of the nomenclature. Now, I would claim that all items in the list box other than [None] are not line breaks. A line break is when you stop the current line and start on the next line. It's a very simple thing. The other options are involve breaking the line, vertical space, and one-time indentation or in-line horizontal space. It's true that they're within the same paragraph, but we should simply get rid of the dichotomy of "it's either a paragraph break or a line break". It's another kind of break in the flow of text. That would make the phrase "restart location" more sensible. After a line break, there is no "restarting". The line simply ends. There's the next line, but it's not being "restarted". Now, the choices must also better illustrate what is supposed to be clear, and clear of what objects. Are we talking about objects intersecting the current line? A potential next line like with a regular line break? Everywhere in the line? Only to the right or to the left or the horizontal position of the break? "Left"/"Right" doesn't tell me that (although there is arguably some merit in being intentionally vague - you won't be assuming you know exactly what it means without checking). "Next clear line on right/on left" also doesn't tell me that. And what is a "clear line on right" or "clear line on left"? I don't get it at all. And finally: The behavior right now is _not_ Left vs Right, it's Start vs End. See this by flipping your paragraph direction, e.g. in the attached document.
(In reply to Eyal Rozenberg from comment #24) > Now, I would claim that all items in the list box other than [None] are not > line breaks. A line break is when you stop the current line and start on the > next line. It's a very simple thing. The other options are involve breaking > the line, vertical space, and one-time indentation or in-line horizontal > space. It's true that they're within the same paragraph, but we should > simply get rid of the dichotomy of "it's either a paragraph break or a line > break". It's another kind of break in the flow of text. This potential rename of "any such break other than [None]" can *not* help anyone. Neither user to have it understood on have their work done, nor to show the underlying Writer concept. This is just pushing one's perfectionism together with a single person's understanding of the "whole world" terminology. > That would make the phrase "restart location" more sensible. After a line > break, there is no "restarting". The line simply ends. There's the next > line, but it's not being "restarted". This is just pushing the wrong understanding of "restart" to mean "restart the line", while in fact it means "restart the text flow". The line ended, but not the text flow. The "restart" term is OK in any case.
(In reply to Mike Kaganski from comment #25) > This is just pushing the wrong understanding of "restart" to mean "restart > the line", while in fact it means "restart the text flow". Well if it said "restart text flow" or "restart flow", then fine. But it doesn't.