Created attachment 143074 [details] rtl odt created by ms office 2016 in attachment a test odt file generated by MS office 2016 which is RTL, however, when I open it in writer is displayed as LTR. see the screenshot.
Created attachment 143075 [details] screen shot
I opened the attachment in each of the following builds. I wasn't able to reproduce the problem. (Windows 8.1) Version: 6.0.5.2 (x64) Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 CPU threads: 4; OS: Windows 6.3; UI render: GL; Locale: en-US (en_US); Calc: CL and Version: 6.2.0.0.alpha0+ Build ID: b1740fba0d1e6e3d69c3781734509317f42a0e4f CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-06-15_08:49:04 Locale: en-US (en_US); Calc: CL
Created attachment 143080 [details] Writer in windows
(In reply to Susan Gessing from comment #2) > I opened the attachment in each of the following builds. I wasn't able to > reproduce the problem. (Windows 8.1) > > Version: 6.0.5.2 (x64) > Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 > CPU threads: 4; OS: Windows 6.3; UI render: GL; > Locale: en-US (en_US); Calc: CL > > and > > Version: 6.2.0.0.alpha0+ > Build ID: b1740fba0d1e6e3d69c3781734509317f42a0e4f > CPU threads: 4; OS: Windows 6.3; UI render: GL; > TinderBox: Win-x86@42, Branch:master, Time: 2018-06-15_08:49:04 > Locale: en-US (en_US); Calc: CL You may not notice the direction. It is Right in Word and left in Writer. I have tested the doc in windows and I can reproduce it. Version: 6.0.5.2 (x64) Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 CPU threads: 1; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group See the attached screen shot and please confirm.
Created attachment 143081 [details] word 2016 screen shot to be clear here is how it looks in word 2016
You are correct. I retested in the 2 builds and the text in LibreOffice DOES incorrectly display as left to right. Sorry I misread.
I can reproduce it back to LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 the question is: is it a LibreOffice problem or a MS Office problem not following the ODF standard ? Could you please explain how the document was created?
(In reply to Xisco Faulí from comment #7) > I can reproduce it back to > > LibreOffice 3.3.0 > OOO330m19 (Build:6) > tag libreoffice-3.3.0.4 > > the question is: is it a LibreOffice problem or a MS Office problem not > following the ODF standard ? > Could you please explain how the document was created? There is no special way I followed in creating the test. Just I opened word then I write in it and I add some footnote and format the text to be RTL. Now in writer, the direction of the text is changed to be Left as seen in the screenshot.
For me the file from Word looks good. It has paragraph attributes: fo:text-align="start" style:writing-mode="rl-tb" style:language-complex="ar" style:country-complex="OM" and for the character "space" a script-type="complex" I do not find any code in LibreOffice, that handles fo:text-align for import in Writer. But you know the code base is huge. A Writer expert should look at it. For me it looks like an error in LibreOffice.
See also bug 37128.
(In reply to Regina Henschel from comment #10) > See also bug 37128. You are right. The rtl ODT created in Writer will show left alignment in words. Right now I can't use odt format to exchange documents. Ironically, Doc format is better here.
(In reply to Regina Henschel from comment #9) > I do not find any code in LibreOffice, that handles fo:text-align for import adjushdl.cxx?? It contains SvXMLEnumMapEntry<style::ParagraphAdjust> const pXML_Para_Adjust_Enum[] = { { XML_START, style::ParagraphAdjust_LEFT }, { XML_END, style::ParagraphAdjust_RIGHT }, { XML_CENTER, style::ParagraphAdjust_CENTER }, { XML_JUSTIFY, style::ParagraphAdjust_BLOCK }, { XML_JUSTIFIED, style::ParagraphAdjust_BLOCK }, // obsolete { XML_LEFT, style::ParagraphAdjust_LEFT }, { XML_RIGHT, style::ParagraphAdjust_RIGHT }, { XML_TOKEN_INVALID, style::ParagraphAdjust(0) } };
Dear Fahad Al-Saidi, 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 tested with libreoffice 7.2 & the bug is still present
(In reply to Regina Henschel from comment #9) Let us also node that if we open the document and clear all DF, applying the style "عادي" (which means Normal in Arabic) sets the direction to LTR, even though that paragraph style has direction RTL when we "Edit Style..." Something fishy is happening here :-(