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?

(In reply to Jonathan Clark from comment #13)
> (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?

I see two ways to handle this.

One is a boolean control which modifies the sense of the (existing) alignment Left and Right buttons, to be direction-sensitive. When it's off, things are like now; when it's on, the buttons choose Start or End according to the direction of the paragraph. Then we don't have to switch directions or mirror anything, and we can also translate back from the style of an existing paragraph to the state of buttons on the toolbar.

The other -- less elegant, but probably easier to do, and I thought of it first, so I might as well record it here -- is to put the Start/End buttons in a toolbar sub-menu (like the one for spacing). Then we only need to show them with a specific paragraph as context, so we can pick the right icon; and we're free to position them one above the other, so no need to switch places.

(In reply to Shai Berger from comment #14)
> I see two ways to handle this.
> 
> One is a boolean control which modifies the sense of the (existing)
> alignment Left and Right buttons, to be direction-sensitive. When it's off,
> things are like now; when it's on, the buttons choose Start or End according
> to the direction of the paragraph. 

I would say that the suggested boolean control is a non-sequitur. I mean, of course it's technically feasible if we force an app to behave a certain way, but - that's not how LO toolbar buttons work, generally: A button corresponds to a(n UNO) command. We have 6 commands for the 6 kinds of alignment. Without breaking the the toolbar code with special-casing of these particular buttons, a button will only do one thing, which is trigger one of these 6 commands.

Also, even if this would not be technically inadvisable - it would still be meaningless, because a selection may have multiple paragraphs, with different directions.

Finally, "things are like now" will not an acceptable default; and whatever is not the default - will be what almost-everybody users, since very few people play with advanced settings. 

If I focus on your "when it's on" suggestion - this needs to be "fleshed out" as a suggestion, by answering the questions I posed at the bottom of comment 4.

> The other -- less elegant, but probably easier to do, and I thought of it
> first, so I might as well record it here -- is to put the Start/End buttons
> in a toolbar sub-menu (like the one for spacing). Then we only need to show
> them with a specific paragraph as context, so we can pick the right icon;
> and we're free to position them one above the other, so no need to switch
> places.

So, for this alternative - are you suggesting the toolbar have the four buttons it has now, plus a kind of a menubutton? Or - just a menubutton always?

Also, I don't see why we would only need to show them "with a specific paragraph as context" - the selection could encompass multiple paragraphs.

(In reply to Eyal Rozenberg from comment #15)
> (In reply to Shai Berger from comment #14)
> > I see two ways to handle this.
> > 
> > One is a boolean control which modifies the sense of the (existing)
> > alignment Left and Right buttons, to be direction-sensitive. When it's off,
> > things are like now; when it's on, the buttons choose Start or End according
> > to the direction of the paragraph. 
> 
> I would say that the suggested boolean control is a non-sequitur. I mean, of
> course it's technically feasible if we force an app to behave a certain way,
> but - that's not how LO toolbar buttons work, generally: A button
> corresponds to a(n UNO) command. We have 6 commands for the 6 kinds of
> alignment. Without breaking the the toolbar code with special-casing of
> these particular buttons, a button will only do one thing, which is trigger
> one of these 6 commands.

This can be easily solved by creating two new commands (context-sensitive-align-left and context-sensitive-align-right), which these buttons will always perform. These commands can look at some application state, controlled by the boolean, and choose which of the relevant (other) four to apply to each paragraph.

> 
> Also, even if this would not be technically inadvisable - it would still be
> meaningless, because a selection may have multiple paragraphs, with
> different directions.
> 

If the boolean is off, it's OK. If it's on, they would apply alignment to each paragraph separately. This leaves us without a command "take this set of paragraphs and align each according to its direction", granted.

> Finally, "things are like now" will not an acceptable default; and whatever
> is not the default - will be what almost-everybody users, since very few
> people play with advanced settings. 
> 

I think "on" should be the default on new documents. On existing documents, according to the selection or the paragraph the user is in (this would handle correctly old LO docs, new LO docs, and imported docs).

> If I focus on your "when it's on" suggestion - this needs to be "fleshed
> out" as a suggestion, by answering the questions I posed at the bottom of
> comment 4.
> 

Just to be clear: I'm assuming the "on" state in all of the below:

> * If we press the now-left-align button, then switch the direction, the active button will switch to the new-right-button?

Yes (because the choice of active button is according to the style of the selected paragraph)

> * Will the tooltips say 'Align Start' and 'Align End'? And change labels when we switch directions?

No, they'll always say "Align Left" and "Align Right". The tooltip to educate users is the toggle's tooltip.

> * 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?

Not sure about Format > Paragraph, it's a dialog and we can adapt it to cover the options. However, the active buttons (including the toggle) can be chosen according to selected/current paragraph. 

* 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?

Something to deter users from including them directly. They should be essentially deprecated.

> > The other -- less elegant, but probably easier to do, and I thought of it
> > first, so I might as well record it here -- is to put the Start/End buttons
> > in a toolbar sub-menu (like the one for spacing). Then we only need to show
> > them with a specific paragraph as context, so we can pick the right icon;
> > and we're free to position them one above the other, so no need to switch
> > places.
> 
> So, for this alternative - are you suggesting the toolbar have the four
> buttons it has now, plus a kind of a menubutton? Or - just a menubutton
> always?

Four plus menu.

> 
> Also, I don't see why we would only need to show them "with a specific
> paragraph as context" - the selection could encompass multiple paragraphs.

I, indeed, neglected the case of multiple paragraphs being selected -- in both suggestions -- because I was focusing on Jonathan's question about needing to change UI in a uniform context. But I don't think that's a major issue. The boolean in the first suggestion can be a "tri-state", and the icons in the menu in the second suggestion could fall back to a default (e.g. according to interface language).

(In reply to Shai Berger from comment #16)
> (In reply to Eyal Rozenberg from comment #15)
> 

Actually,

> If it's on, they would apply alignment to each paragraph separately.

So, 

> This
> leaves us without a command "take this set of paragraphs and align each 
> according to its direction", granted.

No, I confused myself with the answer to one of the questions. Actually, this is exactly what this command will do.

> > * Will the tooltips say 'Align Start' and 'Align End'? And change labels when we switch directions?
> 
> No, they'll always say "Align Left" and "Align Right",
> 

They'll say "Align Left" and "Align Right" if all paragraphs in the selection share the same directionality. Otherwise, one will say "Align Start" and the other "Align End", and which will be which should be defined by the directionality of the interface language.

(In reply to Jonathan Clark from comment #13)
> 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?

Neglected to answer this.

I'll first say that, regardless of how we place the 4 icons, we should add a direction indication to some or all of them.

We already have some sort of direction indication in icons - for the bulleted and numbered lists, and for the increase and decrease indent, and even for the line spacing icons, which flip (albeit not always correctly) when we're in an RTL paragraph. The direction indication I suggest here will reflect the paragraph direction (or - will not be present for multi-direction selections); and I suggest we use a filled arrow or triangle, that indicates the direction of text, and is place at the start of the first line shown in the icon. So, a similar idea to these:

https://github.com/eyalroz/bidimailui/blob/master/src/chrome/skin/classic/light/ltr-main-bar-24x24.png
and these:
https://github.com/eyalroz/bidimailui/blob/master/src/chrome/skin/classic/light/rtl-main-bar-24x24.png

but more in line with the actual LO icon theme. This would help the user interpret the button meaning. It would also help in one of two ways:

* If we only decorate Align Start and End with direction indication - it would help distinguish Align Start from Align Left for LTR paragraphs and from Align Right for RTL paragraphs (and similarly for Align Left).
* If we decorate all 6 buttons - it would help the user better understand what the alignment will mean in terms of where the text will progress from, and to where.

Now back to the actual question.

When I got down to writing this answer, I was sure I was going to say "let the button positions be flipped on direction change", i.e. for LTR, the buttons would be:


[Start]  [ Center ] [  End  ]   [Justify]

|>----      |>--      |>----    |>------
-------   --------   -------    --------
-----      ------      -----    --------
---         ----         ---    --------
  
and in RTL, they would be:

[ End ]  [ Center ] [ Start ]  [Justify]

----<|      --<|      ----<|    ------<|
-------   --------   -------    --------
-----      ------      -----    --------
---         ----         ---    --------


but I have to admit that this suffers from similar issues to those I criticized Shai's suggestion for: 

* Currently, I don't know that we have the capability of rearranging the toolbar on direction change. It's not as hard as having commands-with-changing-semantics, but still.
* Not clear what to do with paragraphs with differing directions.

and there's another point: Even now, the 4 direction buttons are not "in order": Justify has no "correct" place among Left-Center-Right. So why should we even insist on a visual ordering of Left-Center right?

That's why it may be the opposite answer that this the better alternative:

* Never switch places
* Drop pretense of a visual order among the alignments.

In this alternative, we will always have:

[Start]  [  End  ] [ Center ] [Justify]

|>----     |>----    |>---    |>------
-------  --------   -------   --------
-----      ------    -----    --------
---          ----     ---     --------

in LTR and

[Start]  [  End  ] [ Center ] [Justify]

 ----<|    ----<|    ---<|    ------<|
-------  --------   -------   --------
  -----    ------    -----    --------
    ---      ----     ---     --------

in RTL. 

-----

Finally - I think perhaps we should to prepare some sort of comparison table between the 3 or 4 different suggestions we've collected, and add it as an attachment. Since we now have lots of intertwined comments.

(In reply to Eyal Rozenberg from comment #18)

Whoops, I mis-drew the last ASCII art quartet!

So: Not switching places, in RTL, would be:


[Start]  [  End  ] [ Center ] [Justify]

 ----<|  ----<|      ---<|    ------<|
-------  --------   -------   --------
  -----  ------      -----    --------
    ---  ----         ---     --------


In addition to these two quartets, we would also have the quartets for vertical, and the triangles we place there would point either up or down - and would be placed either on the left row or the right row depending on the order in which lines add up on the page.

We discussed the topic in the design meeting.

It boils down to the three questions
a) make Start the default for new documents/templates, 
b) how to label the items, and 
c) what to do with toolbar buttons

a) is not controversial and should be done. Pure LTR users wont be affected much and RTL users are likely aware of the issue and understand Start vs Left/Right.

b) change Left/Top to "Force Left/Top" was an idea; to better illustrate the option we could show icons next to the labels and/or improve the preview

c) one idea is to show all six items another to show Start/Center/End/Justify and have Force Left/Right available for customization (meaning to add these buttons but hide it be default); the icon adopts to the writing direction and rotates at 90° for vertical text, for example; we should create new icons for the options Force Left/Right and use the existing for Start/End

Everyone is encouraged to share ideas for icons.

Created attachment 203766 [details]
Force Left

(In reply to Eyal Rozenberg from comment #18)
> [Start]  [ Center ] [  End  ]   [Justify]
> |>----      |>--      |>----    |>------
> -------   --------   -------    --------
> -----      ------      -----    --------
> ---         ----         ---    --------

I understand directional information as arrow to the target. If the alignment is from left my arrow points toward the text starts.

(In reply to Heiko Tietze from comment #21)
> I understand directional information as arrow to the target. If the
> alignment is from left my arrow points toward the text starts.

You did say that at the design meeting. However:

* Look at other arrows we have on the formatting toolbar, like the RTL/LTR buttons, or even increase/decrease indent: The arrow is the direction of movement.
* The interpretation disagrees with the rows on the icon, and you will need to resolve that disagreement.
* You'll quickly get used to it, since the behavior will immediately disagree with that understanding.

Jonathan Clark committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1fe134353a7146a0288ec486f1f9a2c8eb249560

tdf#165507 Add para align start and end toolbar and menu buttons

It will be available in 26.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.

The preceding commit adds the uno commands for start/end alignment. Pending the graphics work discussed above, the uno commands provisionally reuse the icons that are currently used for left/right alignment.

Jonathan Clark committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/64c914fc26eb3348f1530d988c85e5205173f26c

tdf#165507 Rearrange para align dialog for start/end alignment

It will be available in 26.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.

Eyal, you can already test this in master. The six elements are here already.

In the Customize dialog, I see two commands called 'Start':

1.
Command: .uno:CommonAlignStart
Tooltip: Start

2.
Command: .uno:StartPara
Tooltip: Align Start

and the same for End. Should I see that? What's the difference between them?

(In reply to Eyal Rozenberg from comment #27)
> In the Customize dialog, I see two commands called 'Start':
> 
> 1.
> Command: .uno:CommonAlignStart
> Tooltip: Start
> 
> 2.
> Command: .uno:StartPara
> Tooltip: Align Start
> 
> and the same for End. Should I see that? What's the difference between them?
We have separate uno commands for aligning paragraphs (e.g. .uno:LeftPara), objects (e.g. .uno:ObjectAlignLeft), and commands that do both for use in static menus (e.g. .uno:CommonAlignLeft).

.uno:StartPara is like .uno:LeftPara.

.uno:CommonAlignStart is like .uno:CommonAlignLeft.

(In reply to Jonathan Clark from comment #28)

So, I split this matter off into a separate bug, as it's not specific to the Start/End situation. Plus there are 4 commands! I forgot about .uno:AlignLeft.


Now, next issue... the alignment behavior when we switch direction. It is currently the case, that switching paragraph direction also makes LO change the text alignment. Now that we have Start and End alignments, we need to stop doing that; because otherwise, we are mixing the semantics of Right/Left and Start/End, and confusing users.

I believe there is more than one bug mentioning or regarding this behavior. Partial list:

* Bug 165206: Direction switch commands (RTL/LTR) effect on alignment - inconsistent?
* Bug 135350: Weird direction & alignment issues in new documents when switching to RTL

but I'm sure there was this other bug asking specifically for this behavior, which was fixed by introducing it, and I later complained about it having been the wrong call. I forget the bug number right now...

(In reply to Eyal Rozenberg from comment #29)
The bug I was remembering is bug 40496, but it wasn't actually about alignment.  So, ignore the last paragraph in the previous comment.

Also, bug 135350 has actually now become mostly-INVALID: It is appropriate for left-aligned paragraphs to _not_ switch alignments when we change the direction. We just need that to happen consistently.