Created attachment 140887 [details] Wrong rendering + Correct rendering (RTL mark explicitly added) Hi, 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.
The image you posted does not correspond to your reproduction instructions.
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 6.0.3.1 on GNU/Linux Mint 18.3
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) LTR 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: LTR English – עברית. English - العَرَبِيَّة. RTL 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.
Bug still manifests in Impress, with : Version: 6.1.1.2 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
Created attachment 145215 [details] testdoc Test doc based on reproduction sequence described in the bug.
*** Bug 122278 has been marked as a duplicate of this bug. ***
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 https://wiki.documentfoundation.org/RTL_Bugs, I guess it's also possible we're hitting https://bugs.documentfoundation.org/show_bug.cgi?id=103492?
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.
Additional information thus far: - there is only the one Windows (10) machine NOT exhibiting the problem - that machine is running 5.2.5.1 - installing 5.2.5.1 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.
Dear Idan Miara, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I use Libreoffice 7.2.1.2 on Kubuntu and still I see this issue.
Not surprised. Computers inherently carry within them the essences of colonialism and imperialism. These things will never rise to a level of importance that someone would adress them in anything resembling a timely manner as compared to other issues.
Don't take the issue somewhere else. Understanding RTL is not easy for those who have only seen LTR whole of their life. Let's have respect for each and every contribution to the project. We can have out own part in reporting the issue and encourage those who can understand the issue to help with the solution.
You're right of course. It's just frustrating sometimes. Can't think of a project off the top of my head whose primary purpose is to deal with text in one way or another and which doesn't have issues with something basic about handling RTL or non-latin scripts.
Can no longer reproduce this, with an LO 7.5 nightly. Or to be more exact: The "main" part of this bug, which manifests for both Hebrew and English, and doesn't manifest in Writer - I can no longer reproduced. The Arabic letters beying laid out on top of each other is still an issue, but I'm pretty sure that's a separate bug. Idan, others, can you reproduce this? See also my upcoming screenshot.
Can no longer reproduce this, with an LO 7.5 nightly. Or to be more exact: The "main" part of this bug, which manifests for both Hebrew and English, and doesn't manifest in Writer - I can no longer reproduced. The Arabic letters being laid out on top of each other is still an issue, but I'm pretty sure that's a separate bug. Idan, others, can you reproduce this? See also my upcoming screenshot.
Created attachment 181759 [details] Test doc content in LO 7.5 nightly - Writer vs Impress
Can no longer reproduce even the second(ary) issue with recent nightlies. That may have something to do with Khaled Hosni's https://git.libreoffice.org/core/+/3901e029bd39575f700e69a73818565d62226a23 anyway, marking as FIXED for now.
Indeed it is fixed (using LO 7.3.6.2 on MacOS), Thanks Eyal.