* If you're in a left-aligned RTL paragraph, and press Ctrl+RShift - you get right-alignment. * If you're in a right-aligned (or justified, or centered) RTL paragraph, and press Ctrl+RShift - nothing happens. * If you're in a left-aligned LTR paragraph, and press Ctrl+RShift - you get a direction change to RTL and right-alignment. * If you're in a right-aligned (or justified, or centered) LTR paragraph, and press Ctrl+RShift - you get a direction change to RTL. The possible inconsistency in the above set of responses is in what happens when you start with RTL+Left-alignment or LTR+Right-alignment. Consider the first of these. If you first Ctrl+RShift, then Ctrl+LShift - you may expect to end up in the same state you started in: These are the typical key combinations for switching direction back and forth. In fact, you will have switched the alignment, but gone back to the original direction. It's the same for the other state, when you press Ctrl+LShift, then Ctrl+RShift, losing the right-alignment. I am not sure whether to suggest that these keys never affect alignment. But I would like to get some thoughts on whether that's a good idea or not.
If we were to comprehensively resolve bug 131192, this would probably be resolved, since we would need to define the intended behavior of these keys in all of Left, Right, Start and End. And since most of the time, the user would actually choose to align-start or align-end, then Ctrl+RShift and Ctrl+LShift would naturally keep the conceptual alignment while switching it back and forth between right and left, depending on where the start and end lie.
We discussed the topic in the design meeting. Ctrl+l/r-shift are not effective as long CTL/CJK is not enabled. Otherwise it changes the text direction from RTL to superordinate object setting (might depend on the actual scenario). Latin-only users may argue that shortcuts must not be hard-coded and the commands are available individually (ctrl+shift+a/d for LTR/RTL) so consequently to remove the code. RTL users are however familiar with the shortcut. The expectation is, for LTR text, that pressing ctrl+l-shift a) aligns left and b) keeps/sets the superordinate direction, and ctrl+r-shit a) right aligns and b) changes the text direction to RTL; and vice versa for RTL source. Removing the code might be reasonable after bug 163675 (or bug 131192) about an additional start/end alignment is introduced.
(In reply to Heiko Tietze from comment #2) > We discussed the topic in the design meeting. We (= Heiko and myself) did, but apparently I did not take care to properly phrase my part of the minutes, and so some of Heiko's comment does not reflect what I thought we were saying... First, this bug is not about the hard-coding of the shortcut. That's a separate issue, and if someone opens a bug I'll talk about it there. Now, > RTL users are however familiar with the shortcut. The expectation is, for > LTR text, that pressing ctrl+l-shift a) aligns left and b) keeps/sets the > superordinate direction, and ctrl+r-shit a) right aligns and b) changes the > text direction to RTL; and vice versa for RTL source. Not really... RTL users _certainy_ expect: Ctrl+LShift to change the direction to LTR and Ctrl+RShift to change the direction to RTL this is written in stone. Everyone always expects that. The alignment is where expectations get messy. Typically, when one switches away from LTR, Left-aligned text, one wants to also change the alignment to Right (and vice-versa when starting with RTL Right-aligned text). This is because in the typical case, we want to align text to the _start_ of the paragraph - and since we don't have that possibility, we use either Left or Right alignment as the case may be; and we need to flip the alignment along with the direction. But - sometimes, that's not what we wanted, and we really do mean to keep the alignment we set; and that's the case where current behavior frustrates our intent, by intricating the direction and alignment change. And then there is the case of inconsistency, and the back-and-forth direction switch which effectively discards the choice of alignment. > Removing the code might be reasonable after bug 163675 (or bug 131192) about > an additional start/end alignment is introduced. Not removing the code, but rather - removing the alignment-flipping effect of the direction switch; because in that future - we will longer need this "assist", we will express what we want directly.
Silly of me not to notice that this issue is exactly the same with the direction switch buttons, it's not limited to just the keyboard shortcuts. They too force both Right and Left alignment to one of the two options based on the new paragraph direction.
With recent LO 26.2 nightlies: Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: cf56ab4c9e29cb076c3f986a75ade58d997cb43c CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: CL threaded we have entered the age of explicit support for Start and End alignment (as foreseen in comment 1; except we haven't resolved _all_ Start & End issues, just some of them). We now expect Left-aligned and Right-aligned paragraphs to _not_ switch, ever, when the direction changes. That switch is a sort of an emulation of the missing Start and End - which now are no longer missing.
Ok, Jonathan, now that we (read: you)'ve changed the defaults in templates and switched the toolbar buttons etc. - I believe it is time to stop performing alignment switching when the direction changes. What do you think?
(In reply to Eyal Rozenberg from comment #6) > Ok, Jonathan, now that we (read: you)'ve changed the defaults in templates > and switched the toolbar buttons etc. - I believe it is time to stop > performing alignment switching when the direction changes. > > What do you think? I can be convinced otherwise, but I'm worried that doing it too soon might be a problem for people who are working with existing documents that use Force Left/Right.
(In reply to Jonathan Clark from comment #7) > I can be convinced otherwise, but I'm worried that doing it too soon might > be a problem for people who are working with existing documents that use > Force Left/Right. Actually, we have already banged them over the head with the fact that they'll work on their documents and see that none of the alignment buttons are in the pressed state, and will get confused. Given that, I would actually want to encourage them to switch to Start/End alignments. And disabling the non-sensical auto-alignment-switch on direction switch would do that. Also, I would rather people not have to go through _two_ separate version updates with significant behavior changes, i.e. have to adapt to how things are twice and get a feeling that "every time it's some new schtick". Ideally - and perhaps even practically - we should probably have some detection logic which, when someone using RTL first upgrades to 26.8, they will get a pop-up with some guidance about the change. And that is not something we're going twice about this slate of RTL-relatec changes, I think.
(In reply to Eyal Rozenberg from comment #8) > Also, I would rather people not have to go through _two_ separate version > updates with significant behavior changes, i.e. have to adapt to how things > are twice and get a feeling that "every time it's some new schtick". Fair enough. Worst case, I guess users will see the wrong alignment after a direction change, and end up with Start alignment when they try to fix it.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8b08d755f202f10242768fc38e7466399baa778c tdf#165206 Do not change alignment after direction change commands It will be available in 26.8.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.