Steps to reproduce: 1. Open attachment 90382 [details] from bug 72424 -> all hebrew text is aligned to the right 2. Save it as DOCX. 3. Open the new document -> All hebrew text is aligned to the right Reproduced in Version: 6.3.0.0.alpha0+ Build ID: c977473546e450ec122f5d3dbc4578d8994962ef CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded [Bug found by office-interoperability-tools]
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=9fc9510ae3f46e5c1fd65303bac9f01ddc79cb5c author Justin Luth <justin_luth@sil.org> 2018-07-09 21:05:07 +0300 committer Miklos Vajna <vmiklos@collabora.co.uk> 2018-07-25 10:18:22 +0200 commit 9fc9510ae3f46e5c1fd65303bac9f01ddc79cb5c (patch) tree 746f96c426facc7714276df00cea2ea370069730 parent 921f285c7ff713ad219d3e3385d7e7d12d33581e (diff) tdf#106174 writerfilter: bidi - prev adjust? prev bidi? Bisected with: bibisect-linux64-6.2 Adding Cc: to Justin Luth
(In reply to Xisco Faulí from comment #0) > Steps to reproduce: > 1. Open attachment 90382 [details] from bug 72424 -> all hebrew text is > aligned to the right > 2. Save it as DOCX. > 3. Open the new document > -> All hebrew text is aligned to the right First, in the document, some Hebrew text is justified. But regardless of that - the behavior you describe is just fine: Text aligned to the right stays aligned to the right. What's the problem? If you mean "aligned to the left" - can't reproduce with Version: 6.2.0.2 Build ID: 2ce5217b30a543f7666022df50f0562f82be0cff CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3; Locale: he-IL (en_IL); UI-Language: en-US Calc: threaded so perhaps you want to changed the minimum version?
I did notice that after saving and reloading that the Hebrew switched sides to left-aligned instead of right-aligned. HOWEVER, it now looks identical to Microsoft Office 2003 and 2010, so it shouldn't be called a regression.
Created attachment 148524 [details] ODT ( left ) vs DOCX ( right ) Comparison made with Version: 6.3.0.0.alpha0+ Build ID: 392729c735bb82eecf29bae5527ec786ca293f34 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
As you can see in the image attached, in the left document ( ODT before saving ) the hebrew text is either justified or aligned to the right. After saving it to DOCX, the hebrew text is either justified or aligned to the left. I would expect the output file ( DOCX ) to be the same as the input file ( ODT ), that's why I consider this a regression. Before 9fc9510ae3f46e5c1fd65303bac9f01ddc79cb5c the output file looked as the input file.
(In reply to Xisco Faulí from comment #5) > Before 9fc9510ae3f46e5c1fd65303bac9f01ddc79cb5c the output file looked > as the input file. But only in LibreOffice. In Word, the docx doesn't look like the ODT file before or after the "regression". Correct?
(In reply to Justin L from comment #6) > (In reply to Xisco Faulí from comment #5) > > Before 9fc9510ae3f46e5c1fd65303bac9f01ddc79cb5c the output file looked > > as the input file. > But only in LibreOffice. In Word, the docx doesn't look like the ODT file > before or after the "regression". Correct? Actually, in MSO 2013 the DOCX shows left-aligned text. I guess this is a difference between old MSOs and newer ones. Version: 6.3.0.0.alpha0+ Build ID: 301ff4dfb82dfd961b993aec151784bd478b4f97 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-22_22:44:18 Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded
Comment 3 and comment 7 show that at least 3 versions of Word show the round-tripped document as left-aligned. Since Word is the definition of how the document OUGHT to import, this means that since comment 1's commit, LO is now importing it properly. Removing "regression" since this has just exposed a pre-existing export bug.
(In reply to Justin L from comment #8) > Comment 3 and comment 7 show that at least 3 versions of Word show the > round-tripped document as left-aligned. Since Word is the definition of how > the document OUGHT to import, this means that since comment 1's commit, LO > is now importing it properly. Removing "regression" since this has just > exposed a pre-existing export bug. I don't agree with you. I would take Word as the definition of how the document OUGHT to import if the document is created by Word. However, in this case, the document is created by LibreOffice, thus Word imports what LibreOffice exports...
(In reply to Xisco Faulí from comment #9) > I would take Word as the definition of how the > document OUGHT to import if the document is created by Word. However, in > this case, the document is created by LibreOffice, thus Word imports what > LibreOffice exports... Yes, I agree with that. However, if you test how Word imports the document BEFORE comment 1's commit, you will see that it was already left-aligned. Therefore, it was not that commit which caused the incorrect export. The point is that LO has always EXPORTED it as left aligned - which is wrong. The double negative of also importing it wrong meant that it looked correct, since the two errors cancelled each other out.
(In reply to Justin L from comment #10) > (In reply to Xisco Faulí from comment #9) > > I would take Word as the definition of how the > > document OUGHT to import if the document is created by Word. However, in > > this case, the document is created by LibreOffice, thus Word imports what > > LibreOffice exports... > Yes, I agree with that. However, if you test how Word imports the document > BEFORE comment 1's commit, you will see that it was already left-aligned. > Therefore, it was not that commit which caused the incorrect export. The > point is that LO has always EXPORTED it as left aligned - which is wrong. > The double negative of also importing it wrong meant that it looked correct, > since the two errors cancelled each other out. Hi Justin, Ok, I see your point now. I've just tested it with Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.15; Render: default; and MSO 2010 and indeed MSO imports it exactly as it does in master. I agree it's not a regression...
ParaStyles inherit the RTL setting from the "Environment", and thus fall-back on the locale since it is impossible to connect a page style to a paragraph style. That likely explains why comment 2 is unable to reproduce - likely Eyal's locale is RTL, while I have LTR. So, in ODT the paragraph styles use RTL because they pass through the RTL value from the page style. In the DOCX they are hard-coded as LTR, because export deduced that from the locale with the comment //what else can we do :-( The only option is to plaster a w:jc onto every paragraph when both the paragraph and the style inherit from the page style. *** This bug has been marked as a duplicate of bug 98620 ***