Created attachment 99126 [details]
The screenshot shows an error

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]).

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.

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.

(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:

https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg

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.

Owen,
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.

(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)

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

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
http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=1591194a5fc45cbd44c0f4cb022d8ff8c88e0a24..578d3476f0c1bc13ac08cc111f5d758226f4d07b

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
After
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 
https://issues.apache.org/ooo/show_bug.cgi?id=119466

Miklos, can you please take a look at this?

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".

Thanks dev-list and this post
http://nabble.documentfoundation.org/Help-needed-about-failing-build-same-pb-as-Clang-tinderbox-td4049931.html
I was able to narrow the range further down to:
http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=5bdba378d6fc9f18f618967ec37d07efed2afee..ce0f4825730a0f96ca5369a7d07982ea073901fb
 4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33 is the source of this regression.

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?

comparing screen shots in
  https://bz.apache.org/ooo/show_bug.cgi?id=119466#c1
and
  https://bz.apache.org/ooo/show_bug.cgi?id=119466#c2
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..

*** Bug 96307 has been marked as a duplicate of this bug. ***

*** Bug 88950 has been marked as a duplicate of this bug. ***

*** Bug 75958 has been marked as a duplicate of this bug. ***

*** Bug 81498 has been marked as a duplicate of this bug. ***

if bug 96307 is a duplicate, then this comment points to the commit that caused the regression 

(https://bugs.documentfoundation.org/show_bug.cgi?id=96307#c12)
> 4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33 is the commit introducing the
> regression.
> See https://bz.apache.org/ooo/show_bug.cgi?id=119466 for details.

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”

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

*** Bug 108095 has been marked as a duplicate of this bug. ***

(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..

(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.

Problem is still there with the latest LibreOffice

Version: 6.3.2.2 (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

Still reproducible in

Version: 7.1.0.0.alpha0+
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

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.

*** Bug 147017 has been marked as a duplicate of this bug. ***

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: 24.2.1.2 (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

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.

"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.