Created attachment 60818 [details] problematic document The attached document was created in a hebrew version of MS Word, and anonymized in a French version of MS Word 2003. It does not contain any single non-latin/european character (and never did), but its import is all wrong: - Parentheses are not around the right text, are in the wrong place and direction (opening instead of closing and vice-versa). - Text is justified to the right instead of to the left. It looks like a RTL/LTR (right-to-left/left-to-right) writing direction confusion. Compare to the result given by MS Word itself.
Created attachment 60819 [details] MS Word print as PDF
[Reproducible] with "LibreOffice 3.5.3.2 (RC2) German UI/Locale [Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80] on German WIN7 Home Premium (64bit) Neither MS WORD Viewer nor AbiWord 2.9 show that problem. That never worked with LibO, problem already visible with LibO 3.3.3, and was already in OOo 3.3, so inherited from OOo @Cédric: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
The docx import bug was already fixed in Bug 43093. The attached document opens correctly (RTL left aligned) in recent master. But still the document doesn't look the same as in MS Word. Further investigation showed that there is a difference in how LO shows RTL left aligned text, and it's not related to docx. Steps to reproduce: 1. Open a new document in Word 2. Set paragraph direction to RTL, and alignment to left. 3. Write '1 Test' 4. Repeat the same in LO 5. Compare results The solution is to insert LTR mark (Insert->Formatting Mark->Left-to-right mark between '1' and 'Test'), but it can't be applied automatically to imported files. Bug 61795 and Bug 69109 are related.
Restricted my LibreOffice hacking area
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Confirmed there is still a problem: note in the PDF, 1st page there is "4.5. AA.. 3:10". In LibO, the same line is "AA.. 3:10 .4.5" Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Still happens 5.4.1.
When RTL is enabled, LO treats numbers, periods, and colons as CTL encoded text, resulting in them not having the correct position relative to english text that follows it, when they dont have english text proceeding it. Typed Displayed =========================== '1 Test' -> 'Test 1' 'A 1 Test' -> 'A 1 Test' '. 1 Test' -> 'Test 1 .' 'A. 1 Test' -> 'A. 1 Test' This is similar to the issue being addressed in bug 69109.
Tested in: Version: 5.4.2.2.0+ Build ID: 1:5.4.2-3~bpo9+1 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk2; Locale: en-US (en_US.utf8); Calc: group OS: Debian 64bit Stretch (Debian 9.2, with some backported packages) 1. Parentheses seem to be around the right text, in the right place and direction. 2. Text is now left-justified. However, the numbers are to the right of the paragraph text instead of to the left.
Created attachment 137432 [details] PDF export showing the remaining bug in version 5.4.2 This PDF file demonstrates both bug fixes and remaining bug in version 5.4.2.
The remaining “issue” is how bidirectional text algorithm works, setting the paragraph right to left means “this is primarily a RTL text” and this has implications on how characters with weak directionality (e.g. numbers) or neutral (directionality) punctuation are handled. I’m not sure what is the real use case here, but it is really bogus to set LTR text RTL and left align it and then expect it to behave as if was set LTR.