Bug 87767 - Incorrect Spaces Positioning in RTL
Summary: Incorrect Spaces Positioning in RTL
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.3.5.2 release
Hardware: All Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest
Depends on:
Blocks: RTL-CTL
  Show dependency treegraph
 
Reported: 2014-12-27 15:43 UTC by Mansour
Modified: 2015-12-17 08:42 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
RTL Spaces Positioning (540.25 KB, application/x-zip)
2014-12-27 15:43 UTC, Mansour
Details
sample file (8.04 KB, application/vnd.oasis.opendocument.text)
2014-12-27 19:20 UTC, Yousuf Philips (jay) (retired)
Details
Mac OS X Sample for RTL Spaces (33.75 KB, application/zip)
2014-12-27 19:48 UTC, Mansour
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mansour 2014-12-27 15:43:10 UTC
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.
Comment 1 Yousuf Philips (jay) (retired) 2014-12-27 19:20:13 UTC
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.
Comment 2 Yousuf Philips (jay) (retired) 2014-12-27 19:21:45 UTC
CCing the Mac team for them to test also.
Comment 3 Mansour 2014-12-27 19:48:14 UTC
Created attachment 111407 [details]
Mac OS X Sample for RTL Spaces
Comment 4 Mansour 2014-12-27 19:48:39 UTC
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.
Comment 5 Yousuf Philips (jay) (retired) 2014-12-27 22:07:28 UTC
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
Comment 6 Joel Madero 2014-12-30 19:29:31 UTC
Not a critical bug -> lowering to normal and trying to get someone to reproduce it on OSX. Thanks
Comment 7 Mansour 2014-12-31 01:52:06 UTC
Just tested with ver. 4.4.0.1 on OSX and no bug found.
Comment 8 Alex Thurgood 2014-12-31 10:12:19 UTC
Fixed in master 4.5.0 alpha
Comment 9 Alex Thurgood 2014-12-31 10:13:56 UTC
Confirmed on 4331 OSX 10.10.1

so was broken, but now working
Comment 10 Alex Thurgood 2014-12-31 10:14:44 UTC
closing as wfm as the commit having fixed the problem is unidentified
Comment 11 Yousuf Philips (jay) (retired) 2014-12-31 10:15:51 UTC
Lets see if its bibisectable and backportable.
Comment 12 Alex Thurgood 2014-12-31 10:35:36 UTC
Suspect duplicate of bug 85806, which was fixed in 440 beta and master, but not backported to 4.3
Comment 13 Michael Stahl (CIB) 2015-09-15 15:57:41 UTC
4.3 is EOL, removing "backportrequest"
Comment 14 Robinson Tryon (qubit) 2015-12-17 08:42:40 UTC
Migrating Whiteboard tags to Keywords: (bibisectRequest)
[NinjaEdit]