The ODF standard supports [1] six alignment settings for text in a paragraph: * start * end * left * right * center * justify At the moment, LO "supports" four of those, and actually - doesn't even really support those four: * There is no UI in the Paragraph Style / Paragraph Formatting dialog choosing Start or End alignment. * When choosing Left or Right, LO often (always?) actually chooses Start or End, in terms of what's written to the ODT file. For example, if you create a Writer document with four paragraphs: LTR,left-align, LTR,right-align, RTL,right-align and RTL,left-align (with the first one inheriting the page style), you get this in an FODT output: <style:style style:name="P1" style:family="paragraph" style:parent-style-name="Standard"> </style:style> <style:style style:name="P2" style:family="paragraph" style:parent-style-name="Standard"> <style:paragraph-properties fo:text-align="end" style:justify-single-word="false"/> </style:style> <style:style style:name="P3" style:family="paragraph" style:parent-style-name="Standard"> <style:paragraph-properties fo:text-align="end" style:justify-single-word="false" style:writing-mode="rl-tb"/> </style:style> <style:style style:name="P4" style:family="paragraph" style:parent-style-name="Standard"> <style:paragraph-properties fo:text-align="start" style:justify-single-word="false" style:writing-mode="rl-tb"/> </style:style> So, let's do the following: * Have the UI show all six options, at least when RTL support is fully enabled. * Save what the user has actually asked for, to the file. * Rework the four-button group of alignments into a six-group button, with the appropriate names, tooltips and help text. The dilemmas are: 1. What to do when RTL support is _not_ enabled - whether to maintain the "Use Start even though the user said Left" convention. 2. Whether to show the six buttons on the toolbar, only only the 4 buttons of S,E,J,C and keep the other off the toolbar by default. 3. What button images to use for proper Left and Right vs Start and End. [1]: ODF standard 1.4 schema, 20.223 fo:text-align. Available at: https://docs.oasis-open.org/office/OpenDocument/v1.4/csd01/part3-schema/OpenDocument-v1.4-csd01-part3-schema.html
Missing support for start/end is the root cause for bug 118350. I suggest we use that bug to track the parsing and layout changes, and re-target this bug to track needed user interface changes.
(In reply to Jonathan Clark from comment #1) > I suggest we use that bug to track the parsing and layout changes, and > re-target this bug to track needed user interface changes. While I might have partitioned things differently, but it would be a useless nitpicky argument, so let's go with your suggestion. Just please rephrase both bugs' titles so they reflect that arrangement.
With the fix for bug 118350, we now correctly handle Start and End paragraph alignment. Those alignment options are now available for use in the paragraph dialog, but otherwise everything works as it did previously. We can now discuss some UX changes to make using this feature easier. Eyal included some suggestions to consider in the original report. My suggestions: - We should make Start the default alignment. LTR-only users won't notice a difference, but it's conceptually pure and a nice improvement for RTL and mixed cases. - I think we should keep the four-button cluster as-is, but quietly make the Left and Right buttons apply Start and End alignment, instead. This should work in a smart, context-sensitive way; so, for example, clicking on the Right button would apply End alignment if the paragraph is LTR, but Start if RTL. Activation states should work in a similar smart way, and also show as activated if the absolute Left/Right values are used.
(In reply to Jonathan Clark from comment #3) > - We should make Start the default alignment. LTR-only users won't notice a > difference, but it's conceptually pure and a nice improvement for RTL and > mixed cases. I agree. But - this is not a trivial pill for people to swallow. Very few office suite users have heard of "Start alignment", or the distinction of "Start" from "Left". After all, we've never mentioned that before, and with MS Workd: https://static0.howtogeekimages.com/wordpress/wp-content/uploads/2025/04/the-alignment-drop-down-menu-in-microsoft-word-s-paragraph-dialog-box.png it's also Left-Right-Center-Justify. Probably any number of other apps which support text alignment (e.g. Inkscape, gimp etc.) So even though I'm still 100% sure we should do this, there is at least the question of how exactly; and whether we should take any measures to facilitate the transition of concepts for users. It might be that the answer is "no", of course. But - who can we ask? We should definitely have a design meeting agenda item about this, but those are just 3-5 people typically, and two of them will probably be us. Maybe a reddit thread? Mastodon poll/open question? And what about places where MS Office people congregate online? -------------------------------------------------- Now let's talk about the toolbar buttons, which already metonimize the difficulty of this conceptual transition. > - I think we should keep the four-button cluster as-is, but quietly make the > Left and Right buttons apply Start and End alignment, instead. This should > work in a smart, context-sensitive way; so, for example, clicking on the > Right button would apply End alignment if the paragraph is LTR, but Start if > RTL. Activation states should work in a similar smart way, and also show as > activated if the absolute Left/Right values are used. Some clarification/elaboration questions (to you and to everyone) about this option, including some I've asked in the opening question: * If we press the now-left-align button, then switch the direction, the active button will switch to the new-right-button? * Will the tooltips say 'Align Start' and 'Align End'? And change labels when we switch directions? * What will we see when the user chooses 'Align Left', e.g. via Format > Paragraph... or when opening a file which has that setting? i.e. will one of the 4 buttons be pressed? Two? None? * What buttons will the UNO commands for Align-Left and Align-Right have? Same look but without the switch on direction switch? Or something to distinguish them from Align-Start and Align-End even when static?
Commented on bug 169035 that a simple Start might be confusing and we better go with "Start (Left)" in case of LTR. Other than that I agree with the default.
(In reply to Heiko Tietze from comment #5) > Commented on bug 169035 that a simple Start might be confusing and we better > go with "Start (Left)" in case of LTR. And, if the direction is switched, should we then have it say: "Start (Right)"? Hmm... Also, suppose the style's direction is "inherit" rather than being set explicitly; how will you decide whether the alignment label says Start (Left) or Start (Right)?
(In reply to Eyal Rozenberg from comment #4) > (In reply to Jonathan Clark from comment #3) > > - We should make Start the default alignment. LTR-only users won't notice a > > difference, but it's conceptually pure and a nice improvement for RTL and > > mixed cases. > > I agree. But - this is not a trivial pill for people to swallow. Very few > office suite users have heard of "Start alignment", or the distinction of > "Start" from "Left". After all, we've never mentioned that before, and with > MS Workd: I also agree this might be confusing for users. That said, I think we should distinguish between how we want our GUI to work, and what we want our layout engine and XML files to be doing under the hood. Our GUI doesn't necessarily need to perfectly report exactly what we're doing; as long as we can provide enough information so curious or advanced users can understand what's happening, it's probably good enough. > Some clarification/elaboration questions (to you and to everyone) about this > option, including some I've asked in the opening question: > > * If we press the now-left-align button, then switch the direction, the > active button will switch to the new-right-button? Yes > * Will the tooltips say 'Align Start' and 'Align End'? And change labels > when we switch directions? I think the tooltips would always say "Align Left" and "Align Right". > * What will we see when the user chooses 'Align Left', e.g. via Format > > Paragraph... or when opening a file which has that setting? i.e. will one of > the 4 buttons be pressed? Two? None? If the caret is inside a paragraph aligned with the left margin, the align left toolbar button would always appear pressed. This would be true whether this is achieved via align Left, Start, or End. > * What buttons will the UNO commands for Align-Left and Align-Right have? > Same look but without the switch on direction switch? Or something to > distinguish them from Align-Start and Align-End even when static? Do we need to preserve the existing buttons? (In reply to Heiko Tietze from comment #5) > Commented on bug 169035 that a simple Start might be confusing and we better > go with "Start (Left)" in case of LTR. Other than that I agree with the > default. If we make these labels context-sensitive, what about just calling Start "Left" in the case of LTR, "Right" in the case of RTL, and then rename the prior fixed Left alignment something like "Force Left/Top"?
(In reply to Eyal Rozenberg from comment #6) > (In reply to Heiko Tietze from comment #5) > > Commented on bug 169035 that a simple Start might be confusing and we better > > go with "Start (Left)" in case of LTR. > > And, if the direction is switched, should we then have it say: "Start > (Right)"? Hmm... > > Also, suppose the style's direction is "inherit" rather than being set > explicitly; how will you decide whether the alignment label says Start > (Left) or Start (Right)? This would be a good excuse to fix the preview, which currently can't handle this case either.
(In reply to Jonathan Clark from comment #7) > If we make these labels context-sensitive, what about just calling Start > "Left" in the case of LTR, "Right" in the case of RTL, and then rename the > prior fixed Left alignment something like "Force Left/Top"? Don't think "Force Left" / "Start" is an improvement over "Left" / "Start (Left)". (In reply to Eyal Rozenberg from comment #6) > Also, suppose the style's direction is "inherit" rather than being set > explicitly; how will you decide whether the alignment label says Start > (Left) or Start (Right)? Inherited is worth a thought, much more if we can clarify what we inherit from. What bothers me with "Start" is that (western) users are familiar with the term "Left" and if they don't find it quickly...
(In reply to Heiko Tietze from comment #9) > (In reply to Jonathan Clark from comment #7) > > If we make these labels context-sensitive, what about just calling Start > > "Left" in the case of LTR, "Right" in the case of RTL, and then rename the > > prior fixed Left alignment something like "Force Left/Top"? > Don't think "Force Left" / "Start" is an improvement over "Left" / "Start > (Left)". It would be "Force Left" / "Left". > (In reply to Eyal Rozenberg from comment #6) > > Also, suppose the style's direction is "inherit" rather than being set > > explicitly; how will you decide whether the alignment label says Start > > (Left) or Start (Right)? > Inherited is worth a thought, much more if we can clarify what we inherit > from. What bothers me with "Start" is that (western) users are familiar with > the term "Left" and if they don't find it quickly... To clarify, with my last suggestion, Western users would click on the "Left" radio button to get Start alignment.
(In reply to Jonathan Clark from comment #7) > Our GUI doesn't necessarily > need to perfectly report exactly what we're doing; as long as we can provide > enough information so curious or advanced users can understand what's > happening, it's probably good enough. So, it's good that this view is also represented in our discussion. But - I partially disagree. That is, I would distinguish between the case of the GUI being a little more vague or inexplicit for the benefit of UX, and the case of the GUI saying something that's incorrect. The first - I would accept or reject on a case-by-case basis; I agree that it's something acceptable to only give a rough idea and let users dig if they want the details. But as for the second option - it frustrates users' legitimate expectations, and the longer-term effect of user miseducation and inability to trust what the app says exceeds the short-term gain of familiarly. For example: > > * If we press the now-left-align button, then switch the direction, the > > active button will switch to the new-right-button? > Yes I'm ok with this level of "fudging": Offering 4 buttons instead of 6, and kind of fudging the difference between Start/End and Left/Right for the purposes of a toolbar representation. But, > > * Will the tooltips say 'Align Start' and 'Align End'? And change labels > > when we switch directions? > I think the tooltips would always say "Align Left" and "Align Right". That is quite unacceptable, and would, in fact, be a bug: Since those buttons would align to Start, not to Left. We must not tell the user that they align one way, only for them to get incorrect alignment when they switch directions. And, of course, we will also have an actual Align Left button, even if it won't be on the toolbar by default; and we can't have that button have both the same image and the same tooltip as Align Start. -------------------------- > > * What will we see when the user chooses 'Align Left', e.g. via Format > > > Paragraph... or when opening a file which has that setting? i.e. will one of > > the 4 buttons be pressed? Two? None? > If the caret is inside a paragraph aligned with the left margin, the align > left toolbar button would always appear pressed. This would be true whether > this is achieved via align Left, Start, or End. I'm guessing you meant the "Align Start" toolbar button? If we only have the four buttons, "Align Left" won't be up there. Also, suppose I opted to put the four buttons on my toolbar: Start, End, Left, Right. You're suggesting that two of these should be pressed for any of the four alignment choice (other than Center or Justify)? > > * What buttons will the UNO commands for Align-Left and Align-Right have? > > Same look but without the switch on direction switch? Or something to > > distinguish them from Align-Start and Align-End even when static? > Do we need to preserve the existing buttons? UNO commands have buttons. And of course we need buttons for the different paragraph alignments. > (In reply to Heiko Tietze from comment #5) > > Commented on bug 169035 that a simple Start might be confusing and we better > > go with "Start (Left)" in case of LTR. Other than that I agree with the > > default. > If we make these labels context-sensitive, what about just calling Start > "Left" in the case of LTR, "Right" in the case of RTL, and then rename the > prior fixed Left alignment something like "Force Left/Top"? 1. Do you mean, in dialogs? Tooltips? Elsewhere? 2. Oh, no, that would make a pig's breakfast of everything. It will not just stunt the education of users about the different alignment values, and about Start/End vs Left/Right generally, but actively undo that education, because no users will see the app itself conflate the two terms. The only context in which this may be acceptable is when we have disabled full RTL-CTL support. And this is part of the reason we have not made a decision to just enable this support unconditionally, for all users: There are significant tradeoffs to consider between access to functionality and semantics, and simplicity for users who don't experience RTL content.
(In reply to Eyal Rozenberg from comment #11) > And of course we need buttons for the different paragraph alignments. Just to clarify - we need buttons, but not all of them need to be on the toolbar by default. We'll definitely have the 6 buttons _available_.
(In reply to Eyal Rozenberg from comment #12) > (In reply to Eyal Rozenberg from comment #11) > > And of course we need buttons for the different paragraph alignments. > > Just to clarify - we need buttons, but not all of them need to be on the > toolbar by default. We'll definitely have the 6 buttons _available_. In your suggestion, what would happen to the Align Start and Align End buttons when you switch between LTR and RTL contexts? Would they swap places on the toolbar somehow? Or would the icons only mirror?