Bug Hunting Session
Bug 37315 - cropped JPEG images in 2007 .docx file are mangled and in wrong place; position different in original and .docx saved by MSO when opened by MSO
Summary: cropped JPEG images in 2007 .docx file are mangled and in wrong place; positi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: interoperability confirmed:4.2.0.1:OSX
Keywords: filter:docx
: 48187 57378 (view as bug list)
Depends on:
Blocks: DOCX-Images Image-Crop
  Show dependency treegraph
 
Reported: 2011-05-18 06:13 UTC by sasha.libreoffice
Modified: 2019-01-11 20:36 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Example .docx version 2007 (902.08 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2011-05-18 06:13 UTC, sasha.libreoffice
Details
screenshot of the same page made on MSOffice 2003 with extension installed (65.08 KB, image/jpeg)
2011-05-18 06:15 UTC, sasha.libreoffice
Details
4.4.0.0 alpha2+ screenshot (386.62 KB, image/png)
2014-11-20 05:58 UTC, tommy27
Details
5.2.0.0 alpha0+ screenshot (349.13 KB, image/png)
2015-12-27 21:32 UTC, tommy27
Details
5.3.4.2 and 6.0.0.0 alpha screenshot (130.08 KB, image/jpeg)
2017-07-18 19:00 UTC, tommy27
Details
screenshot (170.73 KB, application/pdf)
2018-11-29 09:04 UTC, Anderson
Details
Example .docx compared in MSO as original and resaved in MSO (105.76 KB, image/jpeg)
2018-11-29 10:53 UTC, Timur
Details
Example .docx saved in MSO 2016. (903.00 KB, application/vnd.ms-word.document)
2018-11-29 10:56 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2011-05-18 06:13:40 UTC
Created attachment 46861 [details]
Example .docx version 2007

This document contains 4 pictures. In MSOffice 2007 pictures lies in 4 corners of page. In Writer all pictures are in upper left corner.

produced on LibreOffice 3.4 beta 5 on Mandriva 64 bit and Windows Xp 32 bit

PS: MSWord2007 has some weird crop functions. My be add some transformations for pictures with this crop so sat they resemles they look in MSWord 2007.
This specific crop looks not very useful to add in office as functionality. But transformation while importing will be useful.
Comment 1 sasha.libreoffice 2011-05-18 06:15:23 UTC
Created attachment 46862 [details]
screenshot of the same page made on MSOffice 2003 with extension installed
Comment 2 Jacqueline Rahemipour 2011-06-18 14:29:15 UTC
Confirmed with LibO 3.4.0, Win 7

If the original docx is saved as doc, the result in LibO is minimal better. The crop is ok, but the arrangement of the pictures is also wrong.
Comment 3 sasha.libreoffice 2012-05-02 07:12:31 UTC
in 3.5.3 situation is much better than in 3.3.4, but still incorrect
Comment 4 A (Andy) 2013-05-06 20:17:59 UTC
reproducible with LO 4.0.2.2 (Win7 Home, 64bit), I have compared it with MSO 2007

Result: the pictures are buggy, displaced, wrongly cropped, of one picture only a small border is visible, another picture has a white bar in the middle
Comment 5 Timur 2013-05-10 16:37:59 UTC
*** Bug 48187 has been marked as a duplicate of this bug. ***
Comment 6 Timur 2013-05-16 08:31:34 UTC
I marked Bug 48187 - Wrong image placement in docx as a duplicate of this bug, and suggested Bug 56760 - FILESAVE: docx file save picture position problem be also marked as a duplicate. 
But, even this one may be duplicate of Bug 37002 - DOCX import: Image anchored to page is anchored to character. If you agree, please mark so. 
Looks to me like a good candidate for MAB.
Comment 7 sasha.libreoffice 2013-05-16 12:08:12 UTC
bug 56760 is filesave bug, and here is fileopen, therefore not a dup

Bug 62837 has similar anchoring problem as current bug, but with frames
Bug 35334 also about anchoring problems
Comment 8 retired 2014-01-07 12:37:06 UTC
Confirmed:4.2.0.1:OSX

pictures get mangled rather badly. Bottom left pic missing, top right has a white bar in the middle.

Everthing looks good with Word 2010.
Comment 9 tommy27 2014-02-23 09:30:53 UTC
still present in 4.1.5.3, 4.2.0.4 and recent 4.3master under Win7x64bit
same findings reported by Foss

similar issuse with AOO 4.0.0 as well
Comment 10 tommy27 2014-02-23 09:40:55 UTC
(In reply to comment #0)
> Created attachment 46861 [details]
> all 4 pictures appears in one corner but should be in all corners
> 
 
this was originally present in OOo 3.3.0 and LibO 3.3.0 as well.
so issue is inherited from OOo.(In reply to comment #3)

> in 3.5.3 situation is much better than in 3.3.4, but still incorrect

yes, things improved during development but as pointed out in comment #8:

> pictures get mangled rather badly. Bottom left pic missing, top right has a
> white bar in the middle.


actully bottom left pic is moved to the bottom right and is hiding the original right bottom image which in almost completely obscured by white rectangle
Comment 11 Timur 2014-05-19 13:28:36 UTC Comment hidden (obsolete)
Comment 12 Owen Genat (retired) 2014-08-03 02:31:13 UTC
*** Bug 57378 has been marked as a duplicate of this bug. ***
Comment 13 Timur 2014-08-28 14:44:36 UTC
(In reply to comment #0)
> Created attachment 46861 [details]
> all 4 pictures appears in one corner but should be in all corners

Now, 3 year later, 3 pictures appear in diff. corners and only 1 missing.. hopefully it will be here also within a year. 
Adding to MAB.
Comment 14 tommy27 2014-08-28 14:54:44 UTC
Have you tried 4.3.1 or 4.4 master release ? Is issue still present?
Comment 15 Alexandr 2014-08-28 16:34:14 UTC
I confirm comment 13 with LibreOffice 4.3.1.1 and 
4.4.0.0.alpha0+Build ID: 37b9ea92ba81d74764a2345a9c75c65bfd272d2b 
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-08-26_09:48:30 on Debian.

Cropping of the pictures is wrong and one picture has wrong position.
Comment 16 Andrew Ward 2014-11-14 08:25:24 UTC
In LibO 4.3.2.2, when I import a .docx with pictures, each picture is partially obscured by a large white margin at the top of each picture.

Nothing I can do with any of the picture properties will fix it.

If I copy the contents and paste into a new document, it's absolutely fine. The pictures are correct.

If I re-save the original imported document into a new format (eg, .odt), the white margin is still there. So, it's a document property.

I hope this is helpful. My first post so if I've done something wrong, please be gentle.
Comment 17 tommy27 2014-11-20 05:58:05 UTC
Created attachment 109751 [details]
4.4.0.0 alpha2+ screenshot

this is how the document looks in 4.4.0.0.alpha2+

Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-12_00:19:18

crop margins of the first 3 images are not smooth as in MS Word
I see a thin rectangular frame around each image beyond crop margins (which I don't see in 4.3.3.2) and the bottom left images fails to show the pentagonal crop mask and is displaced to page 2 of the document.

moreover since LibO 4.2.x reached the end of life.
I'm moving this mab4.2 to mab4.3 list.
Comment 18 Björn Michaelsen 2014-11-28 09:45:24 UTC Comment hidden (obsolete)
Comment 19 tommy27 2015-03-07 09:37:39 UTC Comment hidden (obsolete)
Comment 20 tommy27 2015-08-15 13:31:56 UTC Comment hidden (obsolete)
Comment 21 Robinson Tryon (qubit) 2015-12-14 06:03:20 UTC Comment hidden (obsolete)
Comment 22 tommy27 2015-12-27 21:32:27 UTC
Created attachment 121572 [details]
5.2.0.0 alpha0+ screenshot

retested under Win8.1 x64 5.2.0.0.alpha0+
Build ID: 451f359023c681a91dbb232a5ea3fffb12c964bc
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-27_07:49:03
Locale: it-IT (it_IT)

compare with previous screenshots.
the pentagonal crop is now visible; that image is still shown in another page and the crop margins of all images are not as smooth as in MS Word but there's an improvement.
Comment 23 tommy27 2016-10-11 05:24:03 UTC
no change in bug behaviour using LibO 5.3.0.0.alpha0+
Build ID: e2f6c7f0d0cc14f851d7028ff846c5dc658a81c6
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-10-10_23:08:02
Locale: it-IT (it_IT); Calc: group
Comment 24 tommy27 2017-07-18 19:00:12 UTC
Created attachment 134714 [details]
5.3.4.2 and 6.0.0.0 alpha screenshot

restested with LibO 5.3.4.2 and a recent 6.0.0.0 alpha daily build under Win7 x64

now all the 4 pictures are displayed on the same page but there's overlapping of the last 2 pictures (skiing pic and pentagonal picture).
Comment 25 tommy27 2018-05-26 09:38:12 UTC
no change from previous screenshot using  6.2.0.0.alpha0+

Build ID: 938ec2597be2e0ad3af2fb99f77de7f87285ad86
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-05-25_23:38:38
Locale: it-IT (it_IT); Calc: group threaded
Comment 26 Anderson 2018-11-29 09:04:36 UTC
Created attachment 147128 [details]
screenshot
Comment 27 Anderson 2018-11-29 09:06:56 UTC
(In reply to Anderson from comment #26)
> Created attachment 147128 [details]
> screenshot

Still exists in version :
 Version: 6.3.0.0.alpha0+ (x64)
 Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
 TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
 Locale: zh-TW (zh_TW); UI-Language: en-US
 Calc: threaded

the position of one image is still wrong, and shapes of other three images is not the shape showed in Microsoft Office 365 Word version 1811.
Comment 28 Timur 2018-11-29 10:53:23 UTC
Created attachment 147134 [details]
Example .docx compared in MSO as original and resaved in MSO

If we open .docx file and save and reopen in MSO 2016, position also changes, as shown on attached comparison.
Comment 29 Timur 2018-11-29 10:56:51 UTC
Created attachment 147135 [details]
Example .docx saved in MSO 2016.

Example .docx saved in MSO 2016. Real problem with this bug example is this one, because it also opens wrong in LO.
Comment 30 Xisco Faulí 2019-01-11 20:36:50 UTC
Lowering importance: Highest + Inherit from OOo doesn't make much sense at this point anymore...