Bug 94955 - FILEOPEN: image inside .doc file showed in wrong position
Summary: FILEOPEN: image inside .doc file showed in wrong position
Status: RESOLVED DUPLICATE of bug 80717
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, filter:doc, regression
Depends on:
Blocks: DOC
  Show dependency treegraph
Reported: 2015-10-11 13:10 UTC by tommy27
Modified: 2020-03-30 11:02 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description tommy27 2015-10-11 13:10:19 UTC
spin off of Bug 94950

this is about the image position which is showed at the bottom of the page in LibO (see screenshot: attachment 119503 [details] ) instead of the top of the page as in MS Word (see screenshot: attachment 119502 [details] )

the text position bug will be discussed in the previous report

the image position bug appeared for the first time in LibO 4.1.0 release and was not present in LibO 3.6.7

hence regression that needs bibisecting
Comment 1 tommy27 2015-10-11 13:12:26 UTC
bug persists in LibO too

Build ID: f830600ece806ec365a4839e79afabe183c5e36d
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-06_22:49:09
Locale: it-IT (it_IT)
Comment 2 Nikos Platis 2015-10-12 06:06:31 UTC
Bibisection result:

b827dce34450091ab3fd608fcb1774899cb2f865 is the first bad commit
commit b827dce34450091ab3fd608fcb1774899cb2f865
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Oct 17 05:16:54 2013 +0000

    commit 1472b5f87314fe660ef1a7b254e51272669f12f6
    Author:     Alia Almusaireae <almusaireae@kacst.edu.sa>
    AuthorDate: Mon May 6 09:11:30 2013 +0300
    Commit:     Bosdonnat Cedric <cedric.bosdonnat@free.fr>
    CommitDate: Mon May 13 15:12:01 2013 +0000
        zoomandviewlayout.ui widget
        Change-Id: I8d607a5960ffc3c69ffa97ca3e2ebae555044581
        Reviewed-on: https://gerrit.libreoffice.org/3794
        Reviewed-by: Bosdonnat Cedric <cedric.bosdonnat@free.fr>
        Tested-by: Bosdonnat Cedric <cedric.bosdonnat@free.fr>

:100644 100644 b3d561c5462e2082e8239a025b32f49179640532 3054ac942c5d4b65fec372169cf9a5cf3c8b1f32 M      autogen.log
:100644 100644 6128b74db3cb1f6c27b1a45c50f7c153ff97a258 e407fbaabbe6f6ff899f60b6c361ac957a64c045 M      ccache.log
:100644 100644 edebfbdcc3e04b63975a647dc7c0b96c150fbbd0 a9ad80935f7065b3323e9f96d191a888839923ef M      commitmsg
:100644 100644 809776d76c5acff63ae05acc840151ed3d6c838f 9d4891958550c345355ce51538d22d0bf9417611 M      dev-install.log
:100644 100644 6568832225733800f0f023ebbe299e1af2ffa2d7 9066bd3d8d2d22fa93737a7c071da2c6ef04d83a M      make.log
:040000 040000 2f51c32806a14b911a2cd80cfe103e8d9b000711 d881f8f7d4858f58d394c03c09f66a630c11dd57 M      opt

and the 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
# good: [d084d250b04446535ca1d7c29cf2062e6bd042b3] source-hash-688f72e3a2c3ef923389bbd21f6aea3afe1114db
git bisect good d084d250b04446535ca1d7c29cf2062e6bd042b3
# bad: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
git bisect bad c2069a369d738078124812312d51f21ea1ce2421
# good: [e2a9149a7723f4e00eb3cafe466e204e5da19e9c] source-hash-2ede6c95e6481c92cc199e7d74fd36c841636304
git bisect good e2a9149a7723f4e00eb3cafe466e204e5da19e9c
# bad: [8901dd09508607642af790dafbbe2d9e9bb9b2a8] source-hash-be1833cbc497080af531a207f216a4f560c0b9e9
git bisect bad 8901dd09508607642af790dafbbe2d9e9bb9b2a8
# bad: [38e06ae137e1dcaaaf82127b977869499742bd94] source-hash-3fb33e3e04c7f339e1e15d24529e8ea1d4dbe321
git bisect bad 38e06ae137e1dcaaaf82127b977869499742bd94
# bad: [b827dce34450091ab3fd608fcb1774899cb2f865] source-hash-1472b5f87314fe660ef1a7b254e51272669f12f6
git bisect bad b827dce34450091ab3fd608fcb1774899cb2f865
# first bad commit: [b827dce34450091ab3fd608fcb1774899cb2f865] source-hash-1472b5f87314fe660ef1a7b254e51272669f12f6
Comment 3 V Stuart Foote 2015-10-24 15:06:30 UTC
commented over on see also bug 94950
Comment 4 Katarina Behrens (Inactive) 2015-10-28 10:21:31 UTC
The topmost commit from comment #2 is innocent -- it doesn't even touch any Writer code. When reading bibisect results, one needs to look at the whole range of commits from log, that is in this particular case:

git log -p 2ede6c95e6481c92cc199e7d74fd36c841636304^1..1472b5f87314fe660ef1a7b254e51272669f12f6

and in that range, my money would be on this one: 

commit 8fe8bd6c3b5b1a539b7370f8c457fa69c061d2de
Author: Miklos Vajna <vmiklos@suse.cz>
Date:   Mon May 13 11:24:58 2013 +0200

    Related: fdo#61594 SwWW8ImplReader::StartApo: don't always start a frame

but I'm no Writer dev, so better double-check with them
Comment 5 tommy27 2015-10-29 05:49:12 UTC
one for you?
Comment 6 Robinson Tryon (qubit) 2015-12-13 11:14:29 UTC Comment hidden (no-value, obsolete)
Comment 7 tommy27 2016-03-19 07:21:29 UTC
bug still present in LibO
Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35
Locale: it-IT (it_IT)
Comment 8 V Stuart Foote 2016-03-19 13:29:51 UTC
(In reply to tommy27 from comment #7)
> bug still present in LibO
> Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa
> CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
> TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35
> Locale: it-IT (it_IT)

quoting cmt 7 on bug 94950...

Open attachment 119501 [details] in MS Word 2007, and Save-as ODF .odt

Reopen in MS Word 2007 -- the result? In MS Word it has the same malformed layout as seen in the LibreOffice flavors back to the opening release. I checked back to

So, beside MS handling the filter conversion to OpenDocument Text with the same misformatting--the real issue seems to be with conversion positioning for the graphic, and positioning for the table. 

With the .DOC open in Word 2007 (Format Picture -> Layout -> Advanced -> Picture Position), the graphic has a Vertical absolute position -.37" below Paragraph, and a "Move object with Text" check-box enabled. The "Paragraph" seems to be the first of five--with the fifth holding the only text.

Also in Word 2007 the Table properties (Ribon Layout -> Table -> Properties: Table Properties -> Table -> Positioning: Table Positioning dialog) show Horizontal position Left relative to Margin. And Vertical position 2.5" relative to **PAGE**. Overlap is allowed, but the "Move with text" is unchecked.

When open in Word 2007 or in any LibreOffice build--either the MS Office saved .ODT or LO filter opening of the .DOC--the graphic is anchored to a Character (not Paragraph)--in first Paragraph. And the table is anchored to paragraph (but which one?)--its position now is Horizontal -.08" from Left margin of Page text area--while Vertical is set 2.50" from Top of Entire Page--with "Follow text flow" unchecked. Interesting in Word 2007 that the Table Properties -> Position Dialog is not available for .ODT Tables.

Someone more versed in our ww8 filter would need to comment, but to me this is a really strangely formatted MS binary document! It is no wonder that MS Word 2007 and LibreOffice builds get strange results parsing for use in ODF. 

Not a regression, and rather a corner case. Is it even our bug?
Comment 9 Björn Michaelsen 2016-08-14 18:47:39 UTC Comment hidden (no-value)
Comment 10 Xisco Faulí 2016-10-05 15:51:15 UTC
Regression introduced by https://cgit.freedesktop.org/libreoffice/core/commit/?id=8fe8bd6c3b5b1a539b7370f8c457fa69c061d2de

Adding Cc: to Miklos Vajna
Comment 11 Xisco Faulí 2017-03-10 13:15:20 UTC
Closing as duplicate of bug 80635, as both bisections point to the same commit...

*** This bug has been marked as a duplicate of bug 80635 ***
Comment 12 Justin L 2020-03-28 07:42:05 UTC

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