Bug 78756 - FILEOPEN: DOC: Improper wrapping around table (complex examples, meta-kind-of-report)
Summary: FILEOPEN: DOC: Improper wrapping around table (complex examples, meta-kind-of...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other All
: high normal
Assignee: Not Assigned
Keywords: bibisected, bisected, filter:doc
: 75958 88950 147017 (view as bug list)
Depends on: 103967
Blocks: DOC-Tables DOC-Anchor-and-Text-Wrap
  Show dependency treegraph
Reported: 2014-05-15 19:17 UTC by ape
Modified: 2024-03-15 20:32 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:

DOC file as example (61.50 KB, application/msword)
2014-05-15 19:17 UTC, ape
The screenshot shows an error (564.47 KB, image/png)
2014-05-15 19:21 UTC, ape
DOC re-saved with frame set to "no wrap" LOv4322 (51.50 KB, application/msword)
2014-09-28 12:21 UTC, Owen Genat (retired)
test case for i119466.doc: Aoo testcase used for regression patch from https://bz.apache.org/ooo/show_bug.cgi?id=119466#c7 (41.50 KB, application/msword)
2016-11-17 09:31 UTC, Justin L
LO 24.2.1 vs MS Word showing the problem (257.06 KB, image/png)
2024-03-15 20:21 UTC, Ari Latvala
Difference on LO vs Word for the second example document (239.98 KB, image/png)
2024-03-15 20:28 UTC, Ari Latvala

Note You need to log in before you can comment on or make changes to this bug.
Description ape 2014-05-15 19:17:23 UTC
Created attachment 99125 [details]
DOC file as example

Open the attached file using programs LibreOfficeDev-4.3.0 (or LibreOffice-4.1.6\4.2.4) and LibreOffice-4.0.6. The second table is placed on the page incorrectly.
It’s the regression to the LibreOffice-4.0.6.
Comment 1 ape 2014-05-15 19:21:22 UTC
Created attachment 99126 [details]
The screenshot shows an error
Comment 2 ape 2014-05-16 11:38:07 UTC
It seems to me that there is an error in parsing file.
Please read my message (bug 78745 comment 3) and look at the contents (content.xml) of this file (attachment 99152 [details]).
Comment 3 Owen Genat (retired) 2014-09-28 12:21:44 UTC
Created attachment 107001 [details]
DOC re-saved with frame set to "no wrap" LOv4322

Originally provided DOC opened under GNU/Linux using:

- v3.3.4.1 OOO330m19 Build: 401
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
- v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
- v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
- v4.4.0.0.alpha0+ Build ID: df73f4115cfe4d07e4159adf087571687eb173ec TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-25_23:06:16

Rendering under v3.3-4.0 are all OK. Rendering under v4.1-4.4 show the same problem: the frame (blue graphic) at top-left is anchored "to character" with wrap set to "through/in background". In older versions of LO this evidently was not being handled correctly and so was pushing the small table at top-right to the right and the larger table down the page, keeping positioning as expected. 

This is not correct behaviour for wrap "through/in background" i.e., other objects should flow over the top / in the foreground. Evidently under later versions this frame is now being treated in the correct manner, thus causing the other tables to appear in front. Changing the wrap of this frame to "no wrap" fixes the display as expected. Refer attached.
Comment 4 Owen Genat (retired) 2014-09-28 12:29:25 UTC
Bug was originally self-confirmed. I am confirming that in older versions there appears to have been a problem, but recent versions have fixed this issue. If my findings can be confirmed I think this report can be RESOLVED as NOTABUG. Severity set to normal. Summary amended for clarity.
Comment 5 Luke 2014-10-05 03:35:25 UTC Comment hidden (obsolete)
Comment 6 ape 2014-10-05 15:12:45 UTC Comment hidden (no-value)
Comment 7 Owen Genat (retired) 2014-10-06 00:01:54 UTC
(In reply to Luke from comment #5)
> Owen, if you open blank_edit.doc in Word and look at the properties of the
> TextBox, you'll see that it's set to "Wrap text behind image". So Writer's
> importer should no be setting Wrap to "No Wrap" as in your attached
> solution. 

Which version of Word are you using? In Word 2007 the layout for the top-left AutoShape is "Behind text" and has "Allow overlap" checked. To be clear, I am suggesting that Writer (since v4.1) may be rendering correctly i.e., "Behind text"+"Allow overlap" == "through/in background". The suggestion/example of "No wrap" was a workaround.

> The problem is likely similar to Bug 82824, where the importer is
> not setting the anchor position of the table on the right side correctly.

The example in that bug has columns. I am not clear whether the /anchoring/ reference here refers to the linked bug or this one (there does not appear to be any anchoring issue in this bug). In any case, the top-right table does have text wrapping set to "Around" while the main table has text wrapping set to "None". It may be the handling of these settings by Word that prevents overlap of the tables (as the summary now implies). Thanks for helping clear this up.

(In reply to ape from comment #6)
> Sorry, but reduce the level of this bug, which is a regression, not right.
> So I returned the status to critical. Lowering the error status will lead to
> the fact that about her forget.

Setting this level too high will cause the bug to be ignored. The guidelines for setting this field are here:


This is not a critical issue (although it may be important to you) as critical means data loss / crash. This is formatting issue, thus Severity = normal.

Please ignore my statement about this not being a bug in comment 4.
Comment 8 Luke 2014-10-06 21:17:28 UTC
Yes, it's not an anchor issue with the table. This can be verified by toggling the "Wrap Around" property of the upper right table in Word(I used 2013). When it is off, Word renders the document like current versions of LO. In writer turning the wrapping on for the table will also fix the import.
Comment 9 ape 2014-10-07 19:51:32 UTC
(In reply to Owen Genat from comment #7)
> (In reply to Luke from comment #5)
> Which version of Word are you using? In Word 2007 the layout for the
> top-left AutoShape is "Behind text" and has "Allow overlap" checked. To be
> clear, I am suggesting that Writer (since v4.1) may be rendering correctly
> i.e., "Behind text"+"Allow overlap" == "through/in background". The
> suggestion/example of "No wrap" was a workaround.
> (In reply to ape from comment #6)

WinWord-2007sp3 (last update)
Comment 10 Kevin Suo 2014-11-03 10:57:51 UTC
There are only 'skip'ped commits left to test.
The first bad commit could be any of: 7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2
We cannot bisect more

[7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b] source-hash-bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0

[d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5
Comment 11 Luke 2014-11-07 02:27:28 UTC
Thanks to Kevin's bibisects, I was able to manually further narrow it down to 

id=578d3476f0c1bc13ac08cc111f5d758226f4d07b - BAD
id=1591194a5fc45cbd44c0f4cb022d8ff8c88e0a24 - GOOD
this leave a rage of

With only http://cgit.freedesktop.org/libreoffice/core/commit/?id=4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33 
#i119466# Doc file loaded by AOO, table with incorrect text wrapping property.
as the most likely cause.  

Before this commit
Text box wrap - in background
table wrap - optimal page wrap
Text box wrap - in background
table wrap - page wrap

We need to be careful that the fix for this does not break the test cases in 

Miklos, can you please take a look at this?
Comment 12 Xisco Faulí 2014-11-07 09:55:44 UTC
It seems that the commit that caused this regression was identified. (Or at
least a commit is suspected as the offending one.)

Thus setting keyword "bisected".
Comment 14 Luke 2015-07-25 01:04:17 UTC
So it seems Word's "Wrap Around" is being mapped to LO's "Page Wrap". In LO "Page Wrap" allows tables to overlap, while Word's does not. 

Page's wrap's description is "Wraps text on all four sides of the border frame of the object." By this definition, a table with text should not be overlapping. 

Miklos, would it be possible to fix page wrap or would we need to add a new more compatible wrap type?
Comment 15 ape 2015-09-14 14:47:45 UTC Comment hidden (obsolete)
Comment 16 Timur 2015-10-05 19:20:01 UTC Comment hidden (obsolete)
Comment 17 Timur 2015-12-08 09:06:54 UTC Comment hidden (obsolete)
Comment 18 Robinson Tryon (qubit) 2015-12-14 00:43:26 UTC Comment hidden (obsolete)
Comment 19 Cor Nouws 2016-01-11 19:49:47 UTC
comparing screen shots in
that should provide evidence for the applied patch,
I can hardly see any difference so wonder if that's all worth the trouble it causes..
Comment 20 Xisco Faulí 2016-09-24 14:37:36 UTC
*** Bug 96307 has been marked as a duplicate of this bug. ***
Comment 21 Xisco Faulí 2016-09-24 14:38:33 UTC
*** Bug 88950 has been marked as a duplicate of this bug. ***
Comment 22 Timur 2016-09-29 15:38:15 UTC Comment hidden (obsolete)
Comment 23 Xisco Faulí 2016-10-05 16:51:50 UTC
*** Bug 75958 has been marked as a duplicate of this bug. ***
Comment 24 Xisco Faulí 2016-10-09 14:21:47 UTC
*** Bug 81498 has been marked as a duplicate of this bug. ***
Comment 25 Cor Nouws 2016-11-09 13:59:44 UTC Comment hidden (obsolete)
Comment 26 Cor Nouws 2016-11-09 14:05:28 UTC
if bug 96307 is a duplicate, then this comment points to the commit that caused the regression 

> 4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33 is the commit introducing the
> regression.
> See https://bz.apache.org/ooo/show_bug.cgi?id=119466 for details.
Comment 27 Luke 2016-11-09 19:09:12 UTC Comment hidden (obsolete)
Comment 28 Justin L 2016-11-17 09:31:45 UTC
Created attachment 128804 [details]
test case for i119466.doc: Aoo testcase used for regression patch from https://bz.apache.org/ooo/show_bug.cgi?id=119466#c7

Based on this test case, I conclude that the current code properly imports Word's wrapping (SURROUND_PARALLEL - wrap text on both sides of the table) instead of before the regression (SURROUND_IDEAL - the computer decides whether to wrap right or left, but not both).

(P.S. Frames ALSO ought to wrap parallel as seen in Word if you move the test case's frame more towards the center. Word's frame seems to have a greater demand for empty space than the table for some reason.  Both are considered frames in LO btw.)

All of these broken documents "just happened" to work properly when set to _IDEAL wrapping, some because that triggers enabling "First Paragraph" ( aSurround.SetAnchorOnly(true) which means that the following paragraph starts below the current frame and is not included in the wrapping).

These documents work with EITHER _IDEAL OR “First Paragraph” (or both)
-attachment 112390 [details] (Fee Schedule 01-04-10.doc) from Bug 81498
-attachment 112963 [details] (exemple.doc) from bug 88950
-attachment 121103 [details] (kissaliitto_ilmo_141.doc) from Bug 96307

This document depends on _IDEAL and is not "fixed" by "First Paragraph".
-attachment 95428 [details] (Sea Launch plus image.doc) from Bug 75958

This bug's document depends on “First Paragraph” being set and doesn’t care whether it is wrapped _PARALLEL or _IDEAL:
-attachment 99125 [details] (blank_edit.doc) from this bug. (note: also affected by bug 103967)

Ironically enough, the original Aoo bug (1277__FSODC250FFCSW_TABLE0010.doc) from comment 19 looks best with _IDEAL wrapping and NO “First paragraph”
Comment 29 Justin L 2016-11-17 13:21:00 UTC
Before 2002, frames were imported as _PARALLEL (and changing back to this does not cause any unit test failures... make check runs successfully, but likely
in the real world it would invite many regressions).

author	Caolán McNamara <cmc@openoffice.org>	2002-10-11 13:16:56 (GMT)
commit 61289bef1a88fc1e44012c40b8cf5c82f30a04b3
#i4173# wrapping for old word frames is really optimal wrap, not parallel
-    eSurround = ( rWW.nSp37 > 1 ) ? SURROUND_PARALLEL : SURROUND_NONE;
+    eSurround = ( rWW.nSp37 > 1 ) ? SURROUND_IDEAL : SURROUND_NONE;

The "First Paragraph" part was added by
author	Cédric Bosdonnat <cedricbosdo@openoffice.org>	2010-10-12 08:08:27
commit 7051c834c6c1e98d9e44cc828701477730113448
n#617593  Fixed the frame surrounding in ww8 import
Comment 30 Xisco Faulí 2017-05-26 11:28:30 UTC
*** Bug 108095 has been marked as a duplicate of this bug. ***
Comment 31 ape 2017-06-09 07:23:23 UTC Comment hidden (obsolete)
Comment 32 Xisco Faulí 2017-10-03 14:57:25 UTC Comment hidden (obsolete)
Comment 33 Cor Nouws 2018-10-02 19:58:16 UTC Comment hidden (obsolete)
Comment 34 Cor Nouws 2018-10-02 19:59:43 UTC
(In reply to Cor Nouws from comment #33)
> thinking about comment #28 and comment #29, one might conclude that
> reverting to the old behavior, would cause at least as much, but prolly more
> problems ?

But the amount of 'see also' bugs and duplicates, seem to indicate different..
Comment 35 Justin L 2018-10-03 04:39:42 UTC
(In reply to Cor Nouws from comment #33)
> @justin, pls what is your though on this?

I have no insight into the details of how LO or MSWord handle wrapping, but based on the number of problems, there is probably some fundamental difference that LO tries to emulate on import/export. If true, then having lots of bug reports would be expected regardless of the implementation.

I know that when I heavily use this feature for something like a newsletter, I would tweak the positioning/sizing of the pictures or even the content of the text itself to get it to flow exactly how I want it. Obviously the slightest difference in rendering (when taking the document to a different program) could then throw off all of my tweaking (and lead me to write a bug report about the terrible compatibility).

My thoughts?
1.) Definitely do not revert - regressions are worse than unfixed bugs.
2.) Very likely there ARE real bugs here that need to be fixed. But if I remember correctly all of these examples are very complex documents. Someone will need to tease out the essence of the problem(s) and create a minimal reproducer document.
3.) Don't close a bug report with lots of duplicates. Obviously there are severe compatibility challenges here.
Comment 36 QA Administrators 2019-10-11 02:36:49 UTC Comment hidden (obsolete)
Comment 37 Ari Latvala 2019-10-16 08:01:53 UTC
Problem is still there with the latest LibreOffice

Version: (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded
Comment 38 Xisco Faulí 2020-07-20 10:14:41 UTC
Still reproducible in

Build ID: abea0d6647c7f1f7e76c73c26cb80e6a67dc5111
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 39 Justin L 2021-03-17 05:44:15 UTC
I removed regression, because these seem to be "just happened to look better before" examples and none of them clearly show an error was made.

I'm also reducing the importance - again because these are very complex documents - not simple files that clearly demonstrate one problem. Also, DOC format has isn't getting much attention any more, and used less often.
Comment 40 Timur 2022-02-01 14:18:52 UTC
*** Bug 147017 has been marked as a duplicate of this bug. ***
Comment 41 QA Administrators 2024-02-02 03:16:09 UTC Comment hidden (obsolete)
Comment 42 Ari Latvala 2024-03-15 20:21:21 UTC
Created attachment 193134 [details]
LO 24.2.1 vs MS Word showing the problem

Problem is still there, even though it has changed. Now the top part of the page is not visible at all on LO.

Version: (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_FI); UI: en-US
Calc: threaded
Comment 43 Ari Latvala 2024-03-15 20:28:13 UTC
Created attachment 193135 [details]
Difference on LO vs Word for the second example document

Not sure, which one is "correct" here but clearly there is a difference.
Comment 44 Ari Latvala 2024-03-15 20:32:58 UTC
"DOC re-saved with frame set to "no wrap" LOv4322 (51.50 KB, application/msword)" example then again looks more or less similar on LO and Word.