Bug 100920 - FILEOPEN DOCX Text box position (absolute position right to column and below paragraph) wrong in LO (left to paragraph and top to margin)
Summary: FILEOPEN DOCX Text box position (absolute position right to column and below ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Textbox
  Show dependency treegraph
 
Reported: 2016-07-15 06:13 UTC by Alankrit
Modified: 2021-02-26 13:41 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Sample file (17.28 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-07-15 06:13 UTC, Alankrit
Details
Expected behaviour (57.56 KB, image/png)
2017-11-17 08:18 UTC, vihsa
Details
Sample compared in MSO and LO (144.10 KB, image/jpeg)
2019-11-24 07:39 UTC, Timur
Details
Simplified example file to demonstrate the problem better (21.00 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-10-22 06:11 UTC, NISZ LibreOffice Team
Details
The simplified example file in Word 2013 and Writer 7.1master (107.10 KB, image/png)
2020-10-22 06:26 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alankrit 2016-07-15 06:13:38 UTC
Created attachment 126214 [details]
Sample file

Document name: IAA.docx 
3. Right part of the document over laps the left part:
Actual Behaviour: https://tinytake.mangoapps.com/sf/ODMwMzlfMzQ4MjkxNA
Expected behaviour: https://tinytake.mangoapps.com/sf/ODI5OTdfMzQ4MDQ5Mg
4. Title is shown empty: 
Actual Behaviour: https://tinytake.mangoapps.com/sf/ODMwNDBfMzQ4MjkxNQ
Expected behaviour: https://tinytake.mangoapps.com/sf/ODI5OThfMzQ4MDQ5Mw
Comment 1 Buovjaga 2016-07-18 06:27:16 UTC
(In reply to Alankrit from comment #0)
> Created attachment 126214 [details]
> Sample file
> 
> Document name: IAA.docx 
> 3. Right part of the document over laps the left part:
> Actual Behaviour: https://tinytake.mangoapps.com/sf/ODMwMzlfMzQ4MjkxNA
> Expected behaviour: https://tinytake.mangoapps.com/sf/ODI5OTdfMzQ4MDQ5Mg

Confirmed.

Please create a new report for issue 4 like I mentioned in the other report.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: ab1b351840160655a9f0caedbb35e9fdf203c5a0
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on July 16th 2016
Comment 2 Alankrit 2016-07-18 10:21:14 UTC Comment hidden (obsolete)
Comment 3 Alankrit 2016-09-19 07:14:42 UTC Comment hidden (no-value)
Comment 4 Buovjaga 2016-09-19 07:31:35 UTC
(In reply to Alankrit from comment #3)
> Can I have an estimate when the bug would be solved

Yes, if you are willing to pay for the fix. If you use LibreOffice for your business, I guess it won't be a problem. Here are certified developers: https://www.documentfoundation.org/gethelp/developers/

I did some more testing and the overlap is present already in 4.3.0.1 (Win 7). In 3.5 the layout is way more messed up.
Comment 5 vihsa 2017-11-17 08:18:15 UTC
Created attachment 137822 [details]
Expected behaviour

just in case if link [ https://tinytake.mangoapps.com/sf/ODI5OTdfMzQ4MDQ5Mg ] dies
Comment 6 Timur 2018-09-04 17:21:53 UTC
Repro 3.6. to 6.2+. Not a regression. Renamed.
Comment 7 Timur 2018-11-23 16:37:52 UTC
Alakrit, you closed the bug that is not fixed, without explanation. 
If you're not interested, you may mark "Ignore Bug Mail" but please let's keep open until it's resolved. Whenever and if it happens.
Comment 8 QA Administrators 2019-11-24 03:36:44 UTC Comment hidden (obsolete)
Comment 9 Timur 2019-11-24 07:39:27 UTC
Created attachment 156070 [details]
Sample compared in MSO and LO

Repro Lo 6.5+.
Comment 10 NISZ LibreOffice Team 2020-10-22 06:11:37 UTC
Created attachment 166610 [details]
Simplified example file to demonstrate the problem better
Comment 11 NISZ LibreOffice Team 2020-10-22 06:26:02 UTC
Created attachment 166611 [details]
The simplified example file in Word 2013 and Writer 7.1master

The problem with the original file is that the textbox is anchored inside the table on the left and the table has a -1.24 cm left indent. This is handled differently.

In Word, the textbox of this file is aligned to an absolute cm value right of a column. Even if the table has a left indent, it has no role in the alignment of the textbox. The attachment has three pairs of table and textbox anchored inside it:
- 11 cm table with 2 cm left indent, with a textbox aligned 13 cm right of column.
- 4 cm table with 0 cm left indent, with a textbox aligned 4 cm right of column.
- 4 cm table with -1 cm left indent, with a textbox aligned 3 cm right of column.

In Word the textboxes start next to the right edge of the table.
In Writer the textboxes start:
- 2 cm right of the tables right edge
- 0 cm right of the tables right edge - same as in Word
- 1 cm left of the tables right edge, overlapping it.

On the second page the tables with non-0 left indent are copied with textboxes anchored outside them in the previous paragraph. In these cases the layout is correct.

So at least for docx import the layout should not consider the left indent of the table containing the textbox shapes anchor.
Comment 12 NISZ LibreOffice Team 2020-10-22 06:45:03 UTC
One more observation:
Currently all these shapes are imported with a horizontal position to "Paragraph Area". 
Changing this manually to "Page text area" in case of the table-anchored textboxes recreates the original layout.
Comment 13 Timur 2021-02-26 13:41:19 UTC
Not sure if the same, but let me keep it here so far: DOCX attachment 114591 [details] from bug 90442 that looks like attachment 170085 [details]. 
shape positions misplaced
Line position, Looks like vertical positioning. Anyway, it's differently shown in MSO (to paragraph) and LO (to margin).