Created attachment 70383 [details] file prepared in Word 2007 with inserted jpg Images that have been cropped in a docx file are not displayed correctly. Instead of the image being cropped, it is resized and 'squashed' to fit the new dimensions. See sample files 1 crop-examples-word2007.docx file prepared in Word 2007 with inserted jpg 2 crop-examples-word2007.pdf file as seen in Word2007 3 crop-examples-word2007-lo.docx copy of file to open in LO 4 crop-examples-word2007-lo.pdf file as seen in LO.
Created attachment 70384 [details] as seen in word2007
Created attachment 70385 [details] copy for opening in LO
Created attachment 70386 [details] as seen in LO
Created attachment 70601 [details] file prepared in word2007 (replacement for 70383) file 70383 uploaded as wrong content type - unreadable
Confirmed on LO 3.6.4.1 Windows XP 32bit. The images are shown cropped when opened in Office 2007.
I've now carried out some more experiments, going from LO to Word2007 rather than Word2007 to LO I created a file in LO, inserted 3 copies of an image and cropped two of them from different directions. Then saved the file in docx format. When opened in Word2007, the cropped images were again 'squashed'. The sample files and a pdf of the result in Word2007 are attached
Created attachment 70724 [details] file prepared in LO
Created attachment 70725 [details] file prepared in LO but saved in docx format
Created attachment 70726 [details] pdf of appearance in Word2007
Created attachment 70727 [details] file prepared in LO but saved in docx format
The same file has been tested with LO 4.0.0.3 on windows XP. The problem still exists
@johnmking_uk I changed the version back to 3.6.3.2. The version number is supposed to show where the bug was *first* observed. It is very useful information when trying to resolve a bug.
*** Bug 48258 has been marked as a duplicate of this bug. ***
According to 48258 already a problem in 3.5.0
already a problem in 3.3.0 release (on Ubuntu)
I can confirm this bug existed already in OOo 3.2.1 on Windows XP and in OOo 3.1.0 portable running under wine on openSuSE 11.4 (64-bit) Testing with master (Version: 4.2.0.0.alpha0+, Build ID: 7afc29809ec9db8c5064d5b5857f64db9bd843be) on openSuSE 11.4 (64-bit): The file supplied by John (attachment 70601 [details]) now seems to loads fine, with cropping correctly applied and without squashed trees. Trying with my own docx testing document the cropping also seems to work fine now. But: In this master version I'm still having this very same problem with a "real life" doc file :-(
To get this issue 'on the radar' mark it as major. But I think making a MAB would be better ??
Thanks Cor, The issue with bitmaps in docx files not being cropped seems to be solved. Many thanks to the unknown hero that fixed this. I'm trying to figure out what is going on in my "real life" document. The remaining problem is with drawings (grouped vector and bitmap elements) inside a Word 97-2003 doc. For some reason the bitmap elements inside these drawings are not recognised as bitmaps by Writer, and are treated as some kind of uncroppable but scalable vector element. E.g. the context menu of the bitmap part doesn't have the "Picture" and "Caption" items associated with a bitmap. I can't attach a sample document, but I can provide a small sample file to the LO devs. The only thing I notice different in the content.xml part of this document is an extra empty <text:p/> element within the <draw:frame> surrounding the draw:image refrerence: <draw:frame etc....> <draw:image xlink:href="Pictures/X.jpg" etc..../> <text:p/> </draw:frame> Removing it seems to make no difference. Hope it helps,
Correction: If the problematic .doc file is saved as .odt in LO, the <text:p/> is within the draw:image statement. Not as previously stated within the draw:frame statement.
Hi Stephan, thanks for the explanation. If I understand you correct, the images from .doc (not docx) are imported/shown fine, but are not treated as image? Then the summary of thus bug should be ??? :)
Hi Cor, The summary of this bug is correct. The images are displayed incorrectly, "squashed" exactly like in the OP. I think there are two different causes: ** Cause 1: The cropping information for bitmaps was not imported correctly. The images in attachment 70601 [details] appear as bitmaps in LO (Right-click menu has the "Picture" item). In OOo and older versions of LO these bitmaps are not cropped but scaled to fit the allotted space. Cause 1 seems to be solved in newer versions of LO (see comment 16). ** Cause 2: Some bitmaps are not recognised as bitmaps. As LO doesn't crop not-bitmap images, the cropping information from the Word document is not imported at all. These images are not cropped but scaled in all versions of LO I tried, including MASTER (4.2.0 pre-alpha). My guess is that the import filters are somehow thrown off by some empty vector or text element associated with the bitmap inside the doc.
Attaching a sample document created in MSO 97: Created by: - grouping a cropped bitmap and a line in Powerpoint - copying to Word - saving to .doc The bitmap in this sample file is imported by LO without cropping, but scaled. If the cropped bitmap and the line are ungrouped in Word prior to saving, than the cropped bitmap is imported correctly by newer versions of LO. (Tested on openSuSE 11.4 64-bit with: LO Version 4.0:build-303 (Build ID: 400m0(Build:303)) LO Version: 4.2.0.0.alpha0+ Build ID: 784cfa382be438240dfc936b7551c5012aada9ae (own master build)
Created attachment 83669 [details] Sample document for cause 2 as described in comment 21 and comment 22
Created attachment 83670 [details] How the drawing in attachement 83669 looks in Word
The root cause here (which is not too easy to fix) is that AFAIK drawinglayer pictures don't support cropping (Writer pictures do). On the other hand, Writer pictures can't be part of group shapes, so basically you can't have both: group shape and cropping. Thorsten, please correct me if I'm wrong.
Is this problem by any chance related to the present shortcomings in Writer mentioned on: http://wiki.openoffice.org/wiki/Refactoring_of_Writer's_usage_of_the_Drawing_layer What's the progress on this refactoring?
*** Bug 58907 has been marked as a duplicate of this bug. ***
The original bug about docx is already fixed in 4.1.0.4, not only in master (although it's still an issue for 4.0.5.2). So I'm closing this bug as WORKSFORME + Whiteboard=(target:4.1.0). See: https://wiki.documentfoundation.org/QA/Bugzilla/FAQ#How_to_terminate_a_Bug_if_it_can.27t_be_reproduced_any_longer https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Releases Not sure how the discussion slipped into doc issues, which should go to bug 57378.
I mean doc issues should go to bug 67951.
Hi all I am reopenning this because I do not see the issue being resolved. I am using: LO Version: 4.1.5.1 Build ID: e0a1805d063a472a7b281ae3977a26d42a48b20 On: Ubuntu 13.10 (64 bits) I witnessed this on one of my documents with a PNG picture, and I just tested it with the attachment "file prepared in LO but saved in docx format" and the issue is the same as described. The previous case (attachment "copy for opening in LO") is however working for me. I am of course talking about docx format here. Please tell me if the last attachments are describing a different bug, i.e. "Image cropped with LO in a docx is displayed incorrectly" as opposed to "Image cropped with MS Word in a docx is displayed incorrectly". I am also changing the version to Inherited from OOo as stated in comment 16.
(In reply to comment #30) > I just tested it with the attachment "file prepared in LO but saved in > docx format" and the issue is the same as described. Opening this file under GNU/Linux x86_64 using v4.2.5.2 does indicate rendering problems, but fixing these and re-saving, results in a stable document, so this may have been a problem with how an older version incorrectly saved the file. Example files in the earlier duplicate bug provide a clearer test case, although comment 25 (here) may indicate that these test cases cannot be supported. *** This bug has been marked as a duplicate of bug 37315 ***