Bug 122747 - FILESAVE: DOCX: RTL text is left aligned after RT
Summary: FILESAVE: DOCX: RTL text is left aligned after RT
Status: RESOLVED DUPLICATE of bug 98620
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: RTL-CTL
  Show dependency treegraph
 
Reported: 2019-01-15 22:48 UTC by Xisco Faulí
Modified: 2019-01-24 15:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT ( left ) vs DOCX ( right ) (426.51 KB, image/png)
2019-01-22 17:00 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2019-01-15 22:48:50 UTC
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]
Comment 1 Xisco Faulí 2019-01-15 22:52:51 UTC
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
Comment 2 Eyal Rozenberg 2019-01-18 21:50:03 UTC
(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?
Comment 3 Justin L 2019-01-19 17:13:52 UTC
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.
Comment 4 Xisco Faulí 2019-01-22 17:00:53 UTC
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
Comment 5 Xisco Faulí 2019-01-22 17:03:20 UTC
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.
Comment 6 Justin L 2019-01-22 17:54:24 UTC
(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?
Comment 7 Buovjaga 2019-01-23 11:49:58 UTC
(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 8 Justin L 2019-01-24 08:37:30 UTC
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.
Comment 9 Xisco Faulí 2019-01-24 09:32:28 UTC
(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...
Comment 10 Justin L 2019-01-24 09:44:22 UTC
(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.
Comment 11 Xisco Faulí 2019-01-24 09:47:34 UTC
(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...
Comment 12 Justin L 2019-01-24 15:20:07 UTC
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 ***