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.
Created attachment 46862 [details] screenshot of the same page made on MSOffice 2003 with extension installed
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.
in 3.5.3 situation is much better than in 3.3.4, but still incorrect
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
*** Bug 48187 has been marked as a duplicate of this bug. ***
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.
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
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.
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
(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
Looks like a good MAB 4.2 candidate.
*** Bug 57378 has been marked as a duplicate of this bug. ***
(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.
Have you tried 4.3.1 or 4.4 master release ? Is issue still present?
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.
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.
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.
(This is an automated message.) Setting priority to highest as this is a MAB. This is part of an effort to make the importance of MAB reflected in priority too.
no change from latest screenshot using LibO 4.4.1.2 and 4.5.0.0.alpha0+ Build ID: ca7f62c8262662c8f58a3fa3b298623f25b55eaa TinderBox: Win-x86@42, Branch:master, Time: 2015-02-26_22:47:46
no change too with LibO 5.1.0.0.alpha1+ Build ID: 7d3fa6bae9f7a755eb2d0ca24bf1afd5f3646bb7 TinderBox: Win-x86@39, Branch:master, Time: 2015-08-09_08:38:08 Locale: it-IT (it_IT)
Migrating Whiteboard tags to Keywords: ( filter:docx ) [NinjaEdit]
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.
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
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).
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
Created attachment 147128 [details] screenshot
(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.
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.
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.
Lowering importance: Highest + Inherit from OOo doesn't make much sense at this point anymore...
Created attachment 157925 [details] Libo 6.3.4 screenshot check new screenshot from LibO 6.3.4 (the same applies to 7.0.0 as well) now the margins of the images are smoother than in 6.1.x but unfortunately the image position are messy with more overlap than before... compare with attachment 147128 [details]
same finding as in previous comment after retesting under Win10 x64 using LibO 6.4.2.2 and 7.0.0.0.alpha0+ (x64) (*) (*) Build ID: 7c5d207c6adaafa8c4f6fe90e3389c7fdaadc800 Thread CPU: 8; SO: Windows 10.0 Build 18362; Resa interfaccia: Skia/Raster; VCL: win; Versione locale: it-IT (it_IT); Lingua interfaccia: it-IT Calc: threaded basically the smoothness of image margins is pretty the same as in MS Word except for the "curly" effect on the ice-skating image. the main problems are position and overlap of the 4 images
Created attachment 168027 [details] Manually fixed version of the 2016 docx If I take the comment #29 docx and change the horizontal position of the bottom two pictures from "Paragraph area" to "Left paragraph border" then the horizontal positioning is fixed. See bug #138782 about this. Other problems I see and need to be separated: - the top left images vertical position is -1.13 cm originally, but it is positioned right below the top of the page. Writer positions it 1.13 cm in the top margin as written into xml: so we should probably clamp this positioning to the page area too. - similarly the bottom left images vertical position is 12.76 cm originally, but it is positioned right above the bottom of the page. Writer positions it a bit in the bottom margin area as written into xml: we should probably clamp this vertical position as well. - the bottom right images vertical position is 2.25 cm originally, but 0.25 in Writer. Changing this back manually and setting the "Left paragraph border" fixes its horizontal positioning.
Of course... these are not plain images, but drawing shapes with image as area fill. Plus Parallel wrap + contour setting. bug #133680 is about images with similar settings.
Dear sasha.libreoffice, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I was still able to reproduce in: Version: 7.6.3.2 (X86_64) / LibreOffice Community Build ID: 29d686fea9f6705b262d369fede658f824154cc0 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded