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 :-(
LibreOffice does not currently implement fo:text-align "start" or "end". These attribute values are faked at the parser level by always treating them as left and right, respectively. This faking is approximately correct for documents that only contain LTR paragraphs, but mirrors the alignment of any RTL paragraph. Microsoft Word produces ODTs that correctly use fo:text-align "start" for RTL paragraphs. In order to fix this bug, we need to implement fo:text-align "start" and "end". The attached file behaves as I would expect with respect to paragraph direction. Only paragraph alignment seems to be an issue.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5d1b2baaa96fce2cc283e4d383bcfca70651b2da tdf#118350 [API CHANGE] Implement start and end paragraph alignment It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This change implements start and end paragraph alignment. Documents will now render correctly, and the new alignment options can be used from the paragraph dialog. We may want some user interface changes to make this easier to use. Tentatively, that effort will be tracked by bug 165507.
(In reply to Jonathan Clark from comment #18) > This change implements start and end paragraph alignment. Documents will now > render correctly, and the new alignment options can be used from the > paragraph dialog. This is great! Thanks so much! What about the default paragraph styles in all of our bundled templates, and in the hard-coded default, to Start rather than Left? IIANM, that's not been changed. Would you say that should happen on another bug?
(In reply to Eyal Rozenberg from comment #19) > What about the default paragraph styles in all of our bundled templates, > and in the hard-coded default, to Start rather than Left? IIANM, that's not > been changed. Would you say that should happen on another bug? I've left this alone intentionally for now. The toolbar items for alignment only signal status when the alignment is specifically left or right. In local testing I found it confusing. It's not going to be difficult to change, but we should decide what we're doing with the UX first. Yes, this should happen on another bug.
(In reply to Jonathan Clark from comment #20) > Yes, this should happen on another bug. And that will be bug 169035.