Bug 154116 - When switching RTL slide from 1-content to 2-content, old content placed on left
Summary: When switching RTL slide from 1-content to 2-content, old content placed on left
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.5.1.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: RTL-CTL
  Show dependency treegraph
 
Reported: 2023-03-10 15:23 UTC by Eyal Rozenberg
Modified: 2023-04-28 18:25 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
Presentation with a single RTL slide and 1 content item (14.04 KB, application/vnd.oasis.opendocument.presentation)
2023-03-10 15:23 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2023-03-10 15:23:53 UTC
Created attachment 185895 [details]
Presentation with a single RTL slide and 1 content item

To reproduce this bug:

1. Create a new presentation. 
2. Set the first slide direction to RTL
3. Enter some text in the (single) content object, e.g. "Content"
4. On the menus, choose Slide | Layout | Title and 2 Content .

Expected result:

Existing content is placed on the right half of the slide, new content placeholder on the left (i.e. the opposite order as for an LTR slide).

Actual result:

Existing content is placed on the left half of the slide, new content placeholder on the right (i.e. the same order as for an LTR slide).

Attaching a presentation to save you the trouble of steps 1...3
Comment 1 Stéphane Guillou (stragu) 2023-04-28 11:38:24 UTC
Are there aspects of slide layouts that do change depending on if the slide is set to RTL vs LTR?
Or is this a more general request to make layouts aware of such a slide property, mirror the elements they contain?
I'm unsure of the mechanics of switching layouts when there already is content on the page. But even if there is no pre-existing content, the slide is already RTL, and the layout is changed, Shape 2 will be on the left and Shape 3 on the right.
Comment 2 Eyal Rozenberg 2023-04-28 12:34:33 UTC
(In reply to Stéphane Guillou (stragu) from comment #1)
> Are there aspects of slide layouts that do change depending on if the slide
> is set to RTL vs LTR?

I'm not sure I understand your question. Do you mean, other than the bug?

> Or is this a more general request to make layouts aware of such a slide
> property, mirror the elements they contain?

This is a bug report, not a request.

> I'm unsure of the mechanics of switching layouts when there already is
> content on the page. But even if there is no pre-existing content, the slide
> is already RTL, and the layout is changed, Shape 2 will be on the left and
> Shape 3 on the right.

So, that's the bug. Shape 2 must be at the _start_, and shape 3 at the _end_. For an LTR slide, these pairs coincide; for an RTL slide, they're opposite.
Comment 3 Stéphane Guillou (stragu) 2023-04-28 13:10:13 UTC
So I think this is the same issue as described in bug 114194: layouts should change depending on slide orientation. Meaning, in my example, Shape 2 should be on the right and Shape 3 should be on the left when Slide Properties > Slide > Text Orientation is RTL.

If that's implemented, not sure about the side-effect of:
1. Slide in LTR
2. Content in both boxes
3. Slide changed to RTL -> boxes switch sides

But let's continue the conversation in bug 114194

*** This bug has been marked as a duplicate of bug 114194 ***
Comment 4 Eyal Rozenberg 2023-04-28 13:59:52 UTC
These two issues are  related - but are really not duplicates:

* Keyboard navigation order is one thing, and placement on the slide is another thing;
* Static situation is one thing, and effects of transforming a slide are another thing.
Comment 5 Stéphane Guillou (stragu) 2023-04-28 15:18:59 UTC
But two issues can have the same source cause. My understanding is that resolving bug 114194 would resolve this too, and having duplicates can attract attention to the issue.
But I don't think I can help further here, I'll un-CC myself.
Comment 6 Eyal Rozenberg 2023-04-28 18:25:08 UTC
(In reply to Stéphane Guillou (stragu) from comment #5)
> But two issues can have the same source cause.

They can, but that does not make them dupes: It makes them co-dependent on the bug for that common cause (or perhaps co-blocking it, depends on how you look at things).

Anyway, the "common cause" lies in how LO does not consistently distinguish between Start and Left, and between End and Right. So you may also want to have a look at bug 131192.