Created attachment 111399 [details] RTL Spaces Positioning When typing in Arabic (right-to-left), Writer incorrectly places spaces that follow Arabic words in at least two scenarios: A) WHEN THERE IS ONLY ONE ARABIC WORD IN LINE (PARAGRAPH) Steps to reproduce: 1. Switch to RTL mode (shift-command-D) and make sure Nonprinting Characters are hidden. 2. Type one Arabic word, e.g. اختبار 3. Press space bar and notice how spaces are placed before the word! 4. View Nonprinting Characters (command-F10) and the spaces are correctly placed, i.e. after the word. B) WHEN ENGLISH WORDS ARE PRECEDED BY ARABIC ONES Steps to reproduce: 1. Switch to RTL mode (shift-command-D) and make sure Nonprinting Characters are hidden. 2. Type some Arabic words, e.g. هذا اختبار 3. Press space bar then type some English words, e.g. Test Two 4. Notice how the Writer does not put the space between Arabic and English text 5. View Nonprinting Characters (command-F10) and now the space appears in the correct position between the two texts. The two attached screenshots visualize this bug.
Created attachment 111406 [details] sample file Hi Mansour, Thanks for the bug report. I created the following sample document on linux and it works fine for me on 4.3 and master on linux and windows. Version: 4.3.6.0.0+ Build ID: ddcf6367240d564e7daf4078e0a4caf0adde9043 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:libreoffice-4-3, Time: 2014-12-12_16:47:22 Version: 4.5.0.0.alpha0+ Build ID: e570cd7a293ceee175949dcc9656cdf776ae3c37 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-12-12_18:49:54 Can you provide your sample document, so we can confirm if this issue effects all OSes or just OSX.
CCing the Mac team for them to test also.
Created attachment 111407 [details] Mac OS X Sample for RTL Spaces
Hi Jay, This bug is relatively recent. I tested an older version of LibreOffice (forgot the number) and the bug was not there. I did not continue using LibreOffice because the fonts appear too blurry on Mac then. I attached three files. 87767-Sample-2.odt is correctly rendered on one of the OOo clone (as you can see in 87767-Sample-2-OOo.pdf produced by that app). But the same document does not appear right in LibreOffice 4.3.5.2 as you can see in the 87767-Sample-2-LibreOffice.pdf. Thank you.
Thanks mansour for the sample file, but unfortunately i wasnt able to reproduce the problem on windows or linux, so this likely is an OSX only problem. Version: 4.3.5.2 Build ID: 430m0(Build:2) Version: 4.5.0.0.alpha0+ Build ID: 57626f2132f73e4e42b31e364b25c5867336e718 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-12-26_09:28:24 Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5 Version: 4.5.0.0.alpha0+ Build ID: f11863d43d96c4bcad9ae43ceb25c05d9a94307d TinderBox: Win-x86@42, Branch:master, Time: 2014-12-23_23:35:47
Not a critical bug -> lowering to normal and trying to get someone to reproduce it on OSX. Thanks
Just tested with ver. 4.4.0.1 on OSX and no bug found.
Fixed in master 4.5.0 alpha
Confirmed on 4331 OSX 10.10.1 so was broken, but now working
closing as wfm as the commit having fixed the problem is unidentified
Lets see if its bibisectable and backportable.
Suspect duplicate of bug 85806, which was fixed in 440 beta and master, but not backported to 4.3
4.3 is EOL, removing "backportrequest"
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]