Created attachment 123523 [details] Wine Configration-1 Hi. Look for this site: https://www.winehq.org/docs/wineusr-guide/config-wine-main I copy/past it's contents by LibreOffice & save as odt. file (Wine Configration-1) Then I open odt file to see the contents. Every thing are good with correct orientation (align to left). Now I try to make docx. file from odt. file by using (from menu of odt. file while opened) the following: file ----> save as ------> odt Look now for attached file 2. It has same contents but with wrong orientation (align to right) while correct is "align to left" as it in site & odt
Created attachment 123524 [details] Wine Configration-2
Thanks for reporting Yousif. I cannot reproduce the problem with 5.0.5.2 and 5.1.1.1 on Ubuntu.
Not reproduced. 64-bit, KDE Plasma 5 Build ID: 5.1.1.3 Arch Linux build-1 CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; Locale: fi-FI (fi_FI.UTF-8)
Hi all!! I get the error on windows 7 SP1 X 64 bit. I did not test it on Linux. But please note the following: many bugs in LibreOffice that existing on windows OS not existing on Linux. Please test windows OS(s). Best.
Can not confirm, the copy/paste unformatted and paste as HTML (without comments) both format correctly into an .ODT docuemnts. And, also when Save copy as OOXML -- .docx On Windows 10 Pro 64-bit en-US with Version: 5.1.1.3 (x64) Build ID: 89f508ef3ecebd2cfb8e1def0f0ba9a803b88a6d CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) I notice on your "Wine Configuartion-2" that your user profile looks to have some unusual styles defined that appear to include an CTL font--and so you receive Right justified formatting for that OOXML document. Perhaps clear you user profile and see if you have a more reasonable result in filter export/save-as in OOXML.
Cant confirm on windows 7 by saving attachment 123523 [details] to .docx. Version: 5.2.0.0.alpha0+ Build ID: 6d5eeb6af585ae525645d844cbbd56e76678a0af CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-02-22_00:12:04 Locale: en-US (en_US)
Yousif, If you could paste the version information from Help > About LibreOffice, that may assist us further.
Hi friends. Sorry for my delay in response. Dear I forget to mention some thing vital: this bug limited to odt. files created by Linux then converted by LibreOffice to docx. on windows. Sorry from forgeting to inform you that. File "Wine Configration-1" is created by LibreOffice pre-insattaled on Linux Mint version 17.3 xfce X 64 bit. Version information from Help > About LibreOffice is: Version: 5.0.3.2 Build ID: 1:5.0.3~rc2-0ubuntu1~trusty2 Locale: en-US (en_US.UTF-8) File "Wine Configration-2" is created (from conversion of "Wine Configration-1" file) by LibreOffice version 5.1.1 Fresh release on windows 7 SP1 X 64
(In reply to yousifjkadom from comment #8) > File "Wine Configration-2" is created (from conversion of "Wine > Configration-1" file) by LibreOffice version 5.1.1 Fresh release on windows > 7 SP1 X 64 Please provide the about information.
About information for Linux Mint 17.3 pre-installed LibreOffice I already gave you! Take this attach screen shot (Linux-Mint-LibreOffice-about) to see, isn't it??
Created attachment 123598 [details] Linux-Mint-LibreOffice-about
If you mean about information of windows version of LibreOffice take this screen shot: Windows-7-LibreOffice-about
Created attachment 123602 [details] Windows-7-LibreOffice-about
*** Bug 98136 has been marked as a duplicate of this bug. ***
I can not confirm with Version: 5.2.0.0.alpha0+, win7. Used your file " Wine Configration-1 ". For the test, could you rename your LibreOffice directory profile (see https://wiki.documentfoundation.org/UserProfile) and give it a new try?
Hi. I perform what you command me to do. I re-name user profile & problem is the same. By the way, please notice that my environment is as following: - Windows 7 X 64 bit SP1 OS (English USA not Arabic user interface) - Windows 7 system locate is Arabic (UAE) - Windows 7 OS input language: is English USA - LibreOffice version 5.1.1 (fresh release) windows version. - LibreOffice language setting are as follow: - user interface: Arabic (Sudi Arabia) - local setting: default - Arabic UAE - default language for western documents: default - English USA - Complex Text Layout (CTL): default - Arabic (UAE) - default direction of text in libreOffice /file, formating, page/ is "from right to left" Are these conditions could be related? Also, you say version 5.2.0.0 alpha !! But I report bug on version 5.1.1.3 Fresh release. So, you have to test bug on version 5.1.1.3 if existing, then confirm it & that it is fixed in a way or other in version 5.2.0.0 alpha !
Lots of folks not being able to repro on 5.1.1, so no need to get agitated..
(In reply to yousifjkadom from comment #16) > - LibreOffice language setting are as follow: > - user interface: Arabic (Sudi Arabia) > - local setting: default - Arabic UAE > - default language for western documents: default - English USA > - Complex Text Layout (CTL): default - Arabic (UAE) > - default direction of text in libreOffice /file, formating, page/ is > "from right to left" > > Are these conditions could be related? Yes, as you are creating a CTL document in Arabic (UAE) when you copy/paste content you are pasting into a paragraph with CTL layout RLTB. You should be able to select language for paragraph from the status bar, at bottom of Writer frame. Choose English (USA) for the paragraph that will hold the pasted content. Does that result in LRTB and alignment left? Are the paragraph styles for each paragraph of pasted text all still set to English (USA)? If so, "Save" to ODF .odt, and then also "Save as" to OOXML .docx. Open the OOXML .docx--are the pasted paragraphs still aligned LRTB? If so, problem solved--you just had to correctly assign a language--other than your default Arabic (UAE)--to each paragraph. If not there *is* a bug in the export/import filter for OOXML.
Hi 1) Dear V Stuart Foote: Please notice that Wine Cinfigration-1 document (odt.) created by LibreOffice in Linux with all setting are "Left to Right" & English as it come in ditro. by default. Right to Left setting that I mentioned are for LibreOffice on windows 7 that I used to convert odt. to docx. However, I now change locale setting from "Arabic UAE" to "English USA". In this case bug disappear, as you expect, when I convert odt. to docx. using "save as" option of LibreOffice on windows OS. But it remain a bug because if I creating odt. by LibreOffice writer on windows 7 (by copy past from web site with correction of alignment to be "Left to right" menualy - notice bug 98682) , then save document as odt. , then re-open this odt. file again & convert it to docx. file by "save as" option , the resulted docx. file will have correct "Left to Right" alignment inspite the "Locale Setting" is defaulted to "Arabic UAE". So, why in the last case alignment remain Left to Right though locale setting is still Arabic - UAE ?? ------------------------ 2) to Buovjaga: Dear friend I'm not agitated.
Yousif, * Actually the copy/paste formatting is not correct. You are getting "justified" and "aligned right" for the text you paste into your default "Text Body" style with English US language selection. The basic setup of Default and Text Body styles are picked up from your local default as established for ar-AE (Arabic UAE) environment. And the pages and default style show Right-to-left which is appropriate for your local. I was wrong by suggesting just setting language would be enough. My apologies. Instead, to handle the pasted content correctly you need to create another style specific to receive the content of your copy/paste activity from web sites. You would assign language of English US (or another if appropriate) as you'd done, but in the new style you also need to fully establish the orientation of the text as distinct from the defaults you have with Complex Text Layout (CTL) support for Arabic. Give that a go, and let us know if you can get the content pasted in from web sites into its own style, and that is reasonably formatted relative to your default local.
Hi V Stuart Foote I think that there is conifusion from your side. I have no problem in copy/past from web page to writer at all. Contents in web page are "Left to Right alignment. Contents still left to right aligned in odt. (Wine Caonfigration-1). It appearing correct (L. to R.) in both Linux & windows. Moreover, LibreOffice in Linux used to create odt. file with default setting to English as it come in distro. I did not even installing Arabic keyboard layout. No problem in copy/past. The problem is in windows OS when I use "save as" to make a docx. version from odt. version THAT CREATED IN LINUX ONLY. I have no such bug with odt. created by windows. --------------------- If you mean bug 98682 please do not discuss it here it will make conifusion. Discuss it within it's threat. If you mean 98682 you have to know that I'm already did what you requested: "in the new style you also need to fully establish the orientation of the text as distinct from the defaults you have with Complex Text Layout (CTL) support for Arabic" but still suffer from same problem.
I can confirm this bug. 1. In simple. set your local to an RTL local (Arabic or Hebrew) (Tools >> options >> Language settings >> Language of: local settings) 2. Open the sample odt file "Wine Configration-1" 3. Save the file as docx 4. close and reopen The text will become aligned to right. It only happens to docx. does not happen when you save to doc or odt files. Version: 5.2.0.0.alpha0+ Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35 Locale: en-US (en_US) OS: Windows 7 Enterprise @Yousif Kadom Thank you for being patient about it. I hope you can install the development version of LO when you test bugs. It has the most recent version after bug fixes and patches. it does not effect your current version of LO. you can get it from here: http://dev-builds.libreoffice.org/daily/master/win-x86@39/current/
Hi Yousif, (In reply to yousifjkadom from comment #21) > If you mean bug 98682 please do not discuss it here it will make conifusion. > Discuss it within it's threat. If you mean 98682 you have to know that I'm > already did what you requested: "in the new style you also need to fully > establish the orientation of the text as distinct from the defaults you have > with Complex Text Layout (CTL) support for Arabic" but still suffer from > same problem. Sorry, too late I was already confused--that should have been against bug 98682 :-) But, believe both issues come from not completely establishing a RLTB style to hold the pasted web content. Language shows correctly in en-US as you set, but the paragraph alignment still picks up other defaults for your UAE locale ar-AE. Including paragraph ends, and empty paragraphs with Arabic UAE language assignment, and cursor movements of LRTB. That lack of a discrete style is carried through by ww8 export filter and elements from the default are assigned. I don't have an Arabic language pack installed on any of my Windows systems so I can't describe exact steps to establish a suitable style to hold pasted text (formatted HTML or unformulated) as RLTB paragraphs within your default LRTB page. @Jay, can you help Yousif?
(In reply to V Stuart Foote from comment #23) Sorry I just added to the confusion... English-US is: LRTB -- Left to Right Top to Bottom Arabic-UAE is: RLTB -- Right to Left Top to Bottom and treated as "complex text layout" I had those notations reversed just now in comment 23, but the usage issue remains of needing to establish a style to contain paragraphs other than default locale.
Confirming .docx problem in Linux (after first setting Locale as Arabic). Note that .doc also has a problem. The first round-trip looks OK, but then it flip-flops back and forth on each round-trip. Tested with 6.2 alpha.
Created attachment 143489 [details] tdf98620_rtlJustify.doc: flip-floping justify on each round-trip (In reply to Justin L from comment #25) > Note that .doc also has a problem. The first round-trip looks OK, but then > it flip-flops back and forth on each round-trip. fix proposed https://gerrit.libreoffice.org/57294 related tdf#98620 ww8import: swap justify when BiDi known Note: to get it to flip-flop, I had set the Alignment to "Right" and the Direction Right-To-Left
The easy fix for this example document would be to set the default paragraph style to a specific format instead of "use superordinate object settings". For DOCX, I think the RTL problem is because it is taking the locale (environment) setting and applying it to each paragraph: > If a given para is using the FRMDIR_ENVIRONMENT direction we > cannot export that, its its ltr then that's ok as thats word's > default. Otherwise we must add a RTL attribute to our export list added pre-docx format in 2002. https://cgit.freedesktop.org/libreoffice/core/commit/?id=2165e74081cd71d862b922546da8af96fc04b12c Also, the ParaAdjust() function takes it's cue from the environment: > if ( nDir == FRMDIR_ENVIRONMENT ) > nDir = GetExport( ).GetDefaultFrameDirection( ); from original 2010 commit "Some fixes for exporting OOXML docx files" https://cgit.freedesktop.org/libreoffice/core/commit/?id=27b1a18b92366ace12bb54c3e21904e2eb380a18 and this detail-less 2007 commit also looks important: https://cgit.freedesktop.org/libreoffice/core/commit/?id=51099bf6493a7f24990da534c41f314c4624b0a8 So, a potential "fix" to make this act more like the .doc format is https://gerrit.libreoffice.org/57356 tdf#98620 RTL: reduce environment effect on loading docx/rtf
Things are way too complicated - getting out of here. 1.) A lot of things depend on RES_FRAMEDIR property existing, but none exist at all on a brand new document. 2.) LO inherits RES_FRAMEDIR all the way back to the page style, but MSO effectively only inherits back to the parent-less paragraph styles. So, on export, every parentless page style needs to ensure that it writes a w:bidi value. 3.) Because styles don't always provide a w:bidi, Paragraphs have been littered with w:bidi settings. (See my patch - wrtw8nds). Something like that needs to be done to the paragraph styles instead. But don't necessarily believe anything here, because the more I think I understand it, the more I find out how wrong I am.
(In reply to Justin L from comment #25) > Confirming .docx problem in Linux (after first setting Locale as Arabic). > Note that .doc also has a problem. The first round-trip looks OK, but then > it flip-flops back and forth on each round-trip. > Tested with 6.2 alpha. So, can you provide clear reproduction instructions? I'm still confused and not able to reproduce. I'm using LO 6.2.0.0 alpha on Linux, with an Israeli locale but the UI language is English. What do I do _exactly_?
(In reply to Eyal Rozenberg from comment #29) > > Note that .doc also has a problem. The first round-trip looks OK, but then > > it flip-flops back and forth on each round-trip. > > So, can you provide clear reproduction instructions? I'm still confused and > not able to reproduce. I'm using LO 6.2.0.0 alpha on Linux, with an Israeli > locale but the UI language is English. What do I do _exactly_? The off-topic tdf98620_rtlJustify.doc bug was fixed in LO 6.2 on August 22 due to bug 106174.
(In reply to Eyal Rozenberg from comment #29) > So, can you provide clear reproduction instructions? To reproduce this report's bug, download the .odt document from comment 0. -start LO and set the locale to a RTL language (tools -> options -> Language Settings -> Languages -> Locale Setting [I used Arabic - Saudi Arabia]). -restart LO just for good measure -open Wine Configration-1.odt. (notice that the alignment is typical LTR). -save as .docx format. -close and re-open the .docx file (notice that the alignment is now on the right.)
Created attachment 145289 [details] inheritedTextDirection.odt: hard to determine paragraph style value from page styles... The reason it works for .ODT is because the LTR/RTL settings are stored in the page style. The default paragraph style is set to inherit from the environment (i.e. the page style). The reason it does not export to .docx is because the export code says that if the paragraph style is set to inherit from the environment, look at the locale setting (since it doesn't know which page style to look at.) This is the same thing I was saying in comment #28 > 2.) LO inherits RES_FRAMEDIR all the way back to the page style, but MSO > effectively only inherits back to the parent-less paragraph styles. So, on > export, every parentless page style needs to ensure that it writes a w:bidi > value.
*** Bug 122747 has been marked as a duplicate of this bug. ***
Proposed fix in three parts: -https://gerrit.libreoffice.org/66921 filter\ww8 export: don't spam RTL if ParaStyle defined -https://gerrit.libreoffice.org/66922 tdf#98620 filter\ww8 export: spam bidi=LTR also -https://gerrit.libreoffice.org/66923 tdf#98620 filter\ww8 export: spam Jc if environment defines BiDi
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/08e78bc7705042d896f0d7c1eddff81d14c35d56%5E%21 tdf#98620 filter\ww8 export: spam bidi=LTR also It will be available in 6.3.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b524cab24b8f7c39104db7842e071599eb1d674f%5E%21 tdf#98620 filter\ww8 export: spam Jc if environment defines BiDi It will be available in 6.3.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.
Fixed. Look at comment 31 for information on how to reproduce the problem. In terms of testing, the most likely place where a problem would show up would be if the paragraph style contains BiDi information. If the existing code does not properly query the style's setting then the end result might be wrong.