Download it now!
Bug 116641 - RTL text that starts with LTR character rendered incorrectly without explicit RTL mark
Summary: RTL text that starts with LTR character rendered incorrectly without explicit...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
: 122278 (view as bug list)
Depends on:
Blocks: RTL-CTL
  Show dependency treegraph
Reported: 2018-03-26 18:24 UTC by Idan Miara
Modified: 2019-09-24 11:40 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Wrong rendering + Correct rendering (RTL mark explicitly added) (34.15 KB, image/png)
2018-03-26 18:24 UTC, Idan Miara
Screenshot: Bug manifests with Impress, not with Writer (113.01 KB, image/png)
2018-03-26 22:43 UTC, Eyal Rozenberg
140894: Screenshot: Bug manifests with Impress, not with Writer (135.98 KB, image/png)
2018-03-26 22:59 UTC, Eyal Rozenberg
testdoc (13.22 KB, application/vnd.oasis.opendocument.presentation)
2018-09-27 13:59 UTC, Lior Kaplan
Screenshot: similar or same (?) bug in Calc (107.44 KB, image/png)
2019-09-19 13:25 UTC, J. R. Schmid

Note You need to log in before you can comment on or make changes to this bug.
Description Idan Miara 2018-03-26 18:24:15 UTC
Created attachment 140887 [details]
Wrong rendering + Correct rendering (RTL mark explicitly added)


Following steps to reproduce the bug (Hebrew or Arabic examples):
1. Create a new Impress file.
2. set RTL mode.
3. write the following text examples (without quotes):
"English - עברית." or "English - العَرَبِيَّة."
that is [LTR letters]+[ - ]+[Hebrew/Arabic]+[.]
4. the rendered text is incorrect. if you write the same in Writer it renders OK. it also renders OK on Impress if you add an RTL Mark character at the beginning.

This bug can be reproduced at least as early as LO 3.5 (and tested also on 5.2, 5.4, 6.0.1) tested on Windows, Debian, Ubuntu.
Comment 1 Eyal Rozenberg 2018-03-26 22:36:57 UTC
The image you posted does not correspond to your reproduction instructions.
Comment 2 Eyal Rozenberg 2018-03-26 22:43:03 UTC
Created attachment 140894 [details]
Screenshot: Bug manifests with Impress, not with Writer

This is the result of following the reproduction instructions (with both text strings) one in Impress, once in Writer.

Taken with LO on GNU/Linux Mint 18.3
Comment 3 Eyal Rozenberg 2018-03-26 22:59:25 UTC
Created attachment 140895 [details]
140894: Screenshot: Bug manifests with Impress, not with Writer

... and of course I managed to mess things up with my last screenshort. Sorry, it was just LTR. I was thrown off since the Arabic was messed up already in that state.

So, now here's a screenshot of the English+Hebrew and the English+Arabic strings, in RTL and in LTR, in Impress and in Writer.

Reproduction for my screenshot - Impress:
1. Open Impress.
2. Edit the slide title (I used the title and set the slide layout to title-only but that's not necessary
3. Type the following text (copy the next three lines)
English – עברית.
English - العَرَبِيَّة.
4. Now copy the entire title box; place the copy under the original
5. Edit the bottom copy's text
6. Replace the word "LTR" on the first line with "RTL"
7. Set the bottom copy's direction to RTL

Reproduction for my screenshot - Writer:
1. Create a new document.
2. Type in the following text:
English – עברית.
English - العَرَبِيَّة.
English – עברית.
English - العَرَبِيَّة.
3. Set the top 3 one-line-paragraphs  to LTR, and the bottom 3 one-line-paragraphs to RTL.
4. Set a large starting indent on the 3 top paragraphs, so that they start close to whether the bottom 3 paragraphs are rendered rather than the far end of the page.
Comment 4 Eyal Rozenberg 2018-09-17 19:19:09 UTC
Bug still manifests in Impress, with :

Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; 
Locale: en-GB (en_GB.UTF-8); Calc: group threaded
Comment 5 Lior Kaplan 2018-09-27 13:59:09 UTC
Created attachment 145215 [details]

Test doc based on reproduction sequence described in the bug.
Comment 6 Alex Thurgood 2019-01-21 15:01:47 UTC
*** Bug 122278 has been marked as a duplicate of this bug. ***
Comment 7 J. R. Schmid 2019-09-19 13:25:54 UTC
Created attachment 154293 [details]
Screenshot: similar or same (?) bug in Calc

We're seeing some problem in Calc that might or might not be the same. I'll happily create a separate bug for it, but thought I'd comment here first. Unfortunately, you don't really get used to reading that way; it'll always slow you down. Also, in that screenshot, I already added U200F after each of the colons, which didn't change anything about the rendering of the Arabic text, though. Looking at, I guess it's also possible we're hitting
Comment 8 J. R. Schmid 2019-09-19 13:27:56 UTC
Forgot to say that one colleague still has LibreOffice 5 installed and everything gets rendered correctly for him in the same spreadsheet, same cell. The rest of us (who are experiencing the problem) all have one version or another of LibreOffice 6 on either Windows 10, Solus OS or Linux Mint.
Comment 9 J. R. Schmid 2019-09-24 11:40:05 UTC
Additional information thus far:

- there is only the one Windows (10) machine NOT exhibiting the problem
- that machine is running
- installing on any of the linux machines exhibits the same problem

On both Windows and Linux, AOOO 4.1.7 renders all cell just fine, irrespective of combination of text direction, font, or any other setting we played with.