Bug 119697 - FILEOPEN DOCX Text box Shape (with absolute position to column in Word?) is positioned incorrectly
Summary: FILEOPEN DOCX Text box Shape (with absolute position to column in Word?) is p...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, implementationError
Depends on:
Blocks: WPS-Support
  Show dependency treegraph
 
Reported: 2018-09-04 17:06 UTC by Timur
Modified: 2022-04-20 11:33 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Page 2 compared in LO (141.53 KB, image/jpeg)
2018-09-04 17:06 UTC, Timur
Details
how it looks in LibreOffice 5.2.7.2 (442.92 KB, image/png)
2018-09-20 10:25 UTC, Xisco Faulí
Details
comparison MSO 2010 and LibreOffice 4.3 (548.47 KB, image/png)
2018-09-20 10:35 UTC, Xisco Faulí
Details
Minimized test document in docx format (23.02 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-10-22 09:17 UTC, NISZ LibreOffice Team
Details
The minimized example file in Word 2013 and Writer (124.16 KB, image/png)
2020-10-22 09:24 UTC, NISZ LibreOffice Team
Details
Word15Mode vs. Word14Mode (295.58 KB, image/jpeg)
2021-08-23 09:40 UTC, Attila Bakos (NISZ)
Details
With the problem in LO 4.4 and whithout in LO 3.6 (209.81 KB, image/jpeg)
2022-01-03 14:11 UTC, Attila Bakos (NISZ)
Details
The test file from Word (15.40 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-01-03 14:12 UTC, Attila Bakos (NISZ)
Details
Test File in LO4.1 (Good) and LO4.2(Bad) (235.56 KB, image/jpeg)
2022-01-03 14:37 UTC, Attila Bakos (NISZ)
Details
Difference between Doc and Docx rendering (458.43 KB, image/jpeg)
2022-01-27 16:48 UTC, Attila Bakos (NISZ)
Details
Difference between rendering the DrawingML and Pure VML (447.34 KB, image/jpeg)
2022-04-19 10:36 UTC, Attila Bakos (NISZ)
Details
the original example without drawingML part (1.75 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-04-19 10:38 UTC, Attila Bakos (NISZ)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2018-09-04 17:06:10 UTC
Created attachment 144672 [details]
Page 2 compared in LO

Open attachment 144603 [details] from Bug 119642 that should look like attachment 144611 [details].
On the 2nd page, the beginning text/first text box shape is wrongly positioned (displaced down the page instead of being at the top of the page and pushed too far to the left of the page).

This was changed thru versions and closest to correct in 4.2.8.2 (except for lines that appear on scroll, but can be a different issue). Let's try with bibisect. 

Note: Original 2007 DOCX if saved in non-compatible MSO looks different, but this issue is unchanged.
Comment 1 Timur 2018-09-04 17:07:44 UTC
Note: Original 2007 DOCX if saved in MSO as non-compatible current version looks different, but this issue is unchanged and bug is still reproduced.
Comment 2 Aron Budea 2018-09-19 23:35:26 UTC
Confirmed with LO 6.1.1.2 / Windows 7.
Comment 3 Xisco Faulí 2018-09-20 10:25:11 UTC
Created attachment 145059 [details]
how it looks in LibreOffice 5.2.7.2

Hi Timur,
I have doubts about your screenshot.
1. 5.2.8.2 doesn't exists
2. the second page of the document is already broken in 5.2.7.2 See attached screenshot
Comment 4 Aron Budea 2018-09-20 10:33:30 UTC
Xisco, he wrote 4.2.8.2. Bibisected to the following commit using repo bibisect-43max. Assuming it's related to implementing wps support, switching keyword to implementationError. Adding Cc: to Miklos Vajna.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=57450afb768c085df0ba2344aa94b5f843060178
author		Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-03 11:59:42 +0100
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-03 15:39:04 +0100

DOCX import: declare wps as a supported feature
Comment 5 Xisco Faulí 2018-09-20 10:35:19 UTC
Created attachment 145061 [details]
comparison MSO 2010 and LibreOffice 4.3
Comment 6 Xisco Faulí 2018-09-20 10:37:08 UTC
(In reply to Aron Budea from comment #4)
> Xisco, he wrote 4.2.8.2. Bibisected to the following commit using repo
> bibisect-43max. Assuming it's related to implementing wps support, switching
> keyword to implementationError. Adding Cc: to Miklos Vajna.

Oh, I didn't see the summary, just the screenshot...

> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=57450afb768c085df0ba2344aa94b5f843060178
> author		Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-03 11:59:42 +0100
> committer	Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-03 15:39:04 +0100
> 
> DOCX import: declare wps as a supported feature

Before that commit, it wasn't perfect either...
Comment 7 Timur 2020-03-11 14:41:00 UTC
rEPRO 7.0+
Comment 8 NISZ LibreOffice Team 2020-10-22 09:17:28 UTC
Created attachment 166618 [details]
Minimized test document in docx format

Only two shapes from the second page in this one.

First page of the document contains text boxes anchored as character to a paragraph each in a two columns section.

Second page contains three textboxes anchored as characters to the same paragraph. At this point Writer places the images below each other in the first column and does not notice that the second textbox does not fit before the bottom of the page.
Comment 9 NISZ LibreOffice Team 2020-10-22 09:24:38 UTC
Created attachment 166619 [details]
The minimized example file in Word 2013 and Writer
Comment 10 Attila Bakos (NISZ) 2021-08-23 09:40:44 UTC
Created attachment 174486 [details]
Word15Mode vs. Word14Mode

Unfortunately, this is not just a problem about columns and text-boxes. There are problem with the w14 - w15 compatibility mode as well. Check the screenshot.
Comment 11 Attila Bakos (NISZ) 2022-01-03 14:11:10 UTC
Created attachment 177281 [details]
With the problem in LO 4.4 and whithout in LO 3.6

This is a DOCX (maybe doc ) specific problem which might be a caused by a compatibility option, and this is a regression (see my attachment). To ensure this:
1) Open Writer 7.4
2) Set the Columns to two.
3) Draw a shape (a rectangle for example) and its length must be greater than of the half of the length of the column and set its anchor as character.
4) Copy the shape below the previous one.

-> First shape in the first column, second one next to it. That's good.

5) Save first to odt and then to docx.
6) Compare the output files

-> Docx has problem odt not.

In LO 3.6 Docx will be fine. (The position and not the shape)
Comment 12 Attila Bakos (NISZ) 2022-01-03 14:12:13 UTC
Created attachment 177282 [details]
The test file from Word
Comment 13 Attila Bakos (NISZ) 2022-01-03 14:37:07 UTC
Created attachment 177283 [details]
Test File in LO4.1 (Good) and LO4.2(Bad)
Comment 14 Attila Bakos (NISZ) 2022-01-27 16:48:18 UTC
Created attachment 177844 [details]
Difference between Doc and Docx rendering

As my attachment shows, only one problem left: the handling of the column break. (It works fine in odt or doc (as in the attachment expect the margin problem) and this remaining issue is can be solved with changing the behaviour of a compatibility option, the only question is, which one needed to be tweaked?
Is someone who can bibisect that in the 4.2 branch (as my last screenshot show that was good in 4.1 and before)? thanks.
Comment 15 Attila Bakos (NISZ) 2022-01-31 07:43:20 UTC Comment hidden (obsolete)
Comment 16 Attila Bakos (NISZ) 2022-01-31 07:44:21 UTC
(In reply to Attila Bakos (NISZ) from comment #15)
> The column break went wrong with this:
> 
> author	Attila Bakos (NISZ) <bakos.attilakaroly@nisz.hu>	2021-02-22 14:28:59
> +0100
> committer	László Németh <nemeth@numbertext.org>	2021-03-01 16:04:05 +0100
> commit 493a916a3113e877835c9bc7c93faef0d29f9a33 (patch)
> tree a0a35dbc7bdc5dbb6df2c4cb71a245c8b5f45c7e
> parent 13f53741dabc33c5ac12ae26538a2803c6ba1073 (diff)
> 
> (Before the position of the shape was good, but the textboxes were detached)
> A bit unpleasant to found myself at bibisect, but never mind this will be
> fixed too. :)

this was bibisected with the 7.2 repo on windows.
Comment 17 Attila Bakos (NISZ) 2022-04-19 10:36:00 UTC
Created attachment 179661 [details]
Difference between rendering the DrawingML and Pure VML

News:
I written before this is a regression, but it seems it is not. it was never good:
-Firstly the textboxes were imported as textframes and the VML part were handled. That is the reason why it seen good in the earlier versions.
-After introducing the WPS it opened as detached textbox, and with bad column break. As my attachment shows, the detached textbox now is fixed and the bad column break, what is remaining.
In this example i removed by hand the DrawingML part, and it proves that, the VML import is good and only the DrawingML has the problem. (the shift between the pages is come from the different margin setting, it is a new problem.)
Fix soon.
Comment 18 Attila Bakos (NISZ) 2022-04-19 10:38:12 UTC
Created attachment 179662 [details]
the original example without drawingML part

The file what works on the previous picture.
Comment 19 Attila Bakos (NISZ) 2022-04-20 11:33:26 UTC
Sorry for the earlier comments, all of them wrong. Today i noticed that, this file has no columns on page level at all, however it has sections, and the columns inside the sections. The positioning is rather a section break problem, not a a wps textbox issue. But what kind of problem inside the section handling, that is a very good question... Setting to unassigned. sorry. :(