Bug 88950 - FILEOPEN: Table is placed on the page incorrectly and not in a frame anymore (.doc import)
Summary: FILEOPEN: Table is placed on the page incorrectly and not in a frame anymore ...
Status: RESOLVED DUPLICATE of bug 78756
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Whiteboard: interoperability
Keywords: bibisected, bisected, filter:doc, regression
Depends on:
Reported: 2015-01-30 16:36 UTC by lced2-lo
Modified: 2016-09-24 14:38 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

File created (139.50 KB, application/doc)
2015-01-30 16:36 UTC, lced2-lo

Note You need to log in before you can comment on or make changes to this bug.
Description lced2-lo 2015-01-30 16:36:39 UTC
Created attachment 112963 [details]
File created

Sorry in advance because it's a bit hard to explain the problem, I'm not an native English speaker and I've got French localized softwares.

When a table is created in Word, with a specific behaviour (text around, and specific position after the paragraph), the document opened in LibreOffice 4.4 won't be displayed in the right place : it will be displayed just behind the paragraph.

Just look at the attachment to see what I mean. I also included in the document itself several one screenshot to help on the second page.
Comment 1 Buovjaga 2015-01-31 13:43:40 UTC
Renders ok in 3.5.0.

Other tested versions have the problem.

Win 7 Pro 64-bit, LibO Version:
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7

Build ID: 309574394bd4ae3e9e10e5ff0d64bdd7bbbc8b83
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-29_23:44:46

Ubuntu 14.10 64-bit Version:
Build ID: 8fd9c25ac66dd238d4c68be3974241a18cb21705
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-01-27_22:43:15


Build ID: 430m0(Build:2)

LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 2 Michael Weghorn 2015-02-01 19:36:54 UTC
bibisect result:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
We cannot bisect more!


$ git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# good: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect good 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# good: [8ad82bc1416a07501651e8d96fe268e47d3931d3] source-hash-13821254f88d2c5488fba9fe6393dcf4ae810db4
git bisect good 8ad82bc1416a07501651e8d96fe268e47d3931d3
# bad: [d084d250b04446535ca1d7c29cf2062e6bd042b3] source-hash-688f72e3a2c3ef923389bbd21f6aea3afe1114db
git bisect bad d084d250b04446535ca1d7c29cf2062e6bd042b3
# bad: [013adf05b6bf8e5d44a4e820d43177d7fb749079] source-hash-a16a4006e40bdb2cb4671846295fe2bf5a856e68
git bisect bad 013adf05b6bf8e5d44a4e820d43177d7fb749079
# bad: [ff4b17247dc05a006a5c4c57dced132c87f2396c] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5
git bisect bad ff4b17247dc05a006a5c4c57dced132c87f2396c
# good: [54c7e3977148ffe7631292f2f7d6d60cf7c86bbc] source-hash-5ad95cec96f6f08c55bb226a6eaeb1eeb95c1279
git bisect good 54c7e3977148ffe7631292f2f7d6d60cf7c86bbc
# skip: [6a9079688b8251402bfcea35b741a418cab30229] source-hash-bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0
git bisect skip 6a9079688b8251402bfcea35b741a418cab30229
# good: [005d70d91c2589e3a200a9dfd4050820cbf73376] source-hash-358b60b3b172968a7605b428af01df456d7669b2
git bisect good 005d70d91c2589e3a200a9dfd4050820cbf73376
# only skipped commits left to test
# possible first bad commit: [ff4b17247dc05a006a5c4c57dced132c87f2396c] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5
# possible first bad commit: [6a9079688b8251402bfcea35b741a418cab30229] source-hash-bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0

Commit 6a9079688b8251402bfcea35b741a418cab30229 fails to start up.
Comment 3 Matthew Francis 2015-02-02 06:24:17 UTC
The behaviour seems to have changed at the below commit.

Adding Cc: to anistenis@gmail.com; Could you possibly take a look at this? Thanks

commit 4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33
Author:     Chen ZuoJun <zjchen@apache.org>
AuthorDate: Mon Oct 8 12:21:52 2012 +0000
Commit:     Xisco Fauli <anistenis@gmail.com>
CommitDate: Sun Apr 14 17:52:34 2013 +0200

    #i119466# Doc file loaded by AOO, table with incorrect text wrapping property.
    Reported by: louqle
    Patch by: Chen Zuo Jun
    Review by: Lei De Bin
Comment 4 Cor Nouws 2015-02-03 11:11:30 UTC
When I open the file in for example in 3.6.6. the table is in a frame too, so the two frames are wrapped.
In there is no frame around the table.

I expect @miklos to know details of the reasoning/cause..

Comment 5 Robinson Tryon (qubit) 2015-12-13 11:12:09 UTC Comment hidden (obsolete)
Comment 6 Aron Budea 2016-09-12 00:15:01 UTC
Still occurs in v5.2.1.2.
Comment 7 Xisco Faulí 2016-09-24 14:38:33 UTC

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