Bug 114948 - FILEOPEN: Wrong position of drawing in DOCX import for rl-tb writing mode
Summary: FILEOPEN: Wrong position of drawing in DOCX import for rl-tb writing mode
Status: RESOLVED DUPLICATE of bug 85994
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: OOXML-Shapes
  Show dependency treegraph
 
Reported: 2018-01-10 12:19 UTC by Ofir
Modified: 2019-04-06 14:08 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
DOCX showing the issue (17.66 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-01-10 12:19 UTC, Ofir
Details
PDF exported from Word 2013 showing the expected result (166.72 KB, application/pdf)
2018-01-10 12:20 UTC, Ofir
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ofir 2018-01-10 12:19:18 UTC
Description:
The attached DOCX has right aligned text and circle drawing on the left.
In writer the circle drawing is placed on the right.

Steps to Reproduce:
1. Open the attached DOCX in Writer

Actual Results:  
The circle drawing is on the right.

Expected Results:
The circle drawing should be on the left.


Reproducible: Always


User Profile Reset: Yes



Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Comment 1 Ofir 2018-01-10 12:19:46 UTC
Created attachment 139016 [details]
DOCX showing the issue
Comment 2 Ofir 2018-01-10 12:20:51 UTC
Created attachment 139017 [details]
PDF exported from Word 2013 showing the expected result
Comment 3 Xisco Faulí 2018-01-10 12:40:34 UTC
Reproduced in

Version: 6.1.0.0.alpha0+
Build ID: 0ef0740298b45379bbf8d00d50beffee7a2f812a
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded


Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 4 Chavdar 2018-01-10 12:55:24 UTC
Reproduced in Windows 10

Version: 6.0.0.1 (x64)
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: bg-BG (bg_BG); Calc: group
Comment 5 QA Administrators 2019-01-11 03:54:31 UTC Comment hidden (obsolete)
Comment 6 Roman Kuznetsov 2019-04-06 11:57:39 UTC
still repro in

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 5cb2db6dd7d234a610a6501668a9901af8472b7f
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-26_23:06:31
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded
Comment 7 Regina Henschel 2019-04-06 13:53:58 UTC
The relevant attribute in ODF is "style:horizontal-pos" with its values 'center', 'left', 'right', and 'from-left' and 'inside', 'outside', 'from-inside' for mirrored page-layout. The value 'from-left' means always 'from-left'; there exists no rule, that it would mean 'from-right' in a rl-tb writing mode.

The docx-file has the attribute posOffset="748030". That value is in EMU, so converted gives 20,78mm. So Word too, uses the offset as "from-left".

LibreOffice is wrong to interpret it as "from-right" in rl-tb writing mode. I have added rl-tb to the summary to reflect the dependence to the writing-mode.
Comment 8 Regina Henschel 2019-04-06 14:08:32 UTC

*** This bug has been marked as a duplicate of bug 85994 ***