When exporting a document which contains a cropped picture the picture will be exported in full size in PDF. So the crop is not applyied when the exporting operation is done.
Same as <http://www.openoffice.org/issues/show_bug.cgi?id=105441>? @Jiehong: What kind of document? Please attach a test kit with picture, LibO document and PDF result.
Created attachment 40290 [details] odt Test file It's the ODF file by itself. The issue occurs at the page 7. See the pdf file to understand.
Created attachment 40291 [details] The same in PDF See page 7 and 8. that PDF was created with the quick pdf export button.
[Reproducible] with "LibreOffice 3.3.0 - WIN XP DE [OOO330m9 (Build:1 - build 3.2.99.2)]" Comparing results with OOo3.4-Dev, OOo3.1.1 and LibO: Problem visible in all versions. Pictures like "Figure 7" will be exported without any cropping. I will check for other LibO applications soon. Also reproducible with my own documents.
Completing my comment 2010-11-15 21:58:50 PST: I can reproduce that problem with my own documents, but only with images from reporter's "rapport.odt" (Figure 7). When I insert that image into a new DRAW or WRITER document (where it appears uncropped), crop left 80mm, bottom 60mm and export the page to PDF, the result will be with uncropped picture in PDF export. But I only see that with that particular image, not with own pictures. So the question is: what strange attributes of reporter's images cause this problem? @Jiehong: Any ideas?
May be the problem are the pictures? May be only those 3 pictures in the world cause the problem? I doubt that this problem will be handled without further information.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
The pictures of that documents comes from a print screen made in windows XP. Those pictures are pasted into the document. I've just tried again the document with LO 3.4.4 and the issue remains the same. Therefore, I have opened a PNG picture in The Gimp, copy it and paste it into writer. Then I've cropped it and exported into PDF. However, it's working properly. This confirms that these particular pictures might be the problem. I've tried to save the Fig.7 into an image file (PNG), insert it in a blank document, crop it and export to PDF… it's working properly. However, when I've saved the image the image has been changed a little bit: the "S" of Sobel became a little bit weird. Try yourself and see if it does that too (have a look at the fig7_exported.png attachment). Therefore, when the picture is saved, it has been changed—enough to see it on the S of Sobel. This means the picture in the document might not be in a good shape. I've copied and pasted the Fig.7 into a new document, saved and exported: same issue. (see alone.odt). By opening the odt file with a archive manager I saw that the picture is saved as a *.svm file which I can't open. Therefore, I've looked into the ODF specification file. It says that "While the image data may have an arbitrary format, it is recommended that vector graphics are stored in the [SVG] format and bitmap graphics in the [PNG] format." (p. 298) However, the SVM file isn't a PNG file. (nor a SVG one obviously) p. 684, it says that "The manifest file is always stored at the pathname META-INF/manifest.xml". However this file doesn't say anything about the svm pictures... That's all I have for now.
Created attachment 54811 [details] a document that only contains the picture
Created attachment 54812 [details] saved image of the picture that is not well exported. It has artefacts.
I can't do any further investigation before January 15th.
reproduced on LibO 3.5.0 beta 1 on Fedora 64 bit IMHO problem because image in SVM format to produce image in another format with high quality: 1. Copy-paste image from Writer to Draw 2. Increase size of image as big as possible (we need this for increase resolution of image because impossible specify resolution directly) 3. Copy-paste image into Gimp 4. Save image or copy-paste back to Writer (after this manipulation Writer saves PDFs properly
NoRepro:4.2.0.2:OSX Setting to Worksforme Openend odt Test file with 4.2.0.2 > save to PDF, compare page 7, looks identical. Please re-open if I've missed something.
Hello, I re-open this bug because it doesn't work. I just have tried with LO 4.1.4.2: 1. open "a document that only contains the picture" ==> you will see only a big dark square with a title. It's a cropped picture. 2. click the button "export to pdf" on the toolbar If you open the generated PDF, you will see that the picture is not correct. I have tried under Linux with Gnome/Xfce/KDE (Archlinux). Could you please try with the same version I have and with the same document? Either it is platform specific , or the newer version you are using solved this issue.
Does not work with LibO 4.1.6 Works as expected with LibO 4.2.5.0.0+ under Ubuntu 14.04 x86-64. As LibO 4.1.6 is the last bugfix of branch 4.1, I think we can close this bug report. @Jiehong: please could you try the first RC for LibO 4.1.4 ? Best regards. JBF
(In reply to comment #16) > Works as expected with LibO 4.2.5.0.0+ under Ubuntu 14.04 x86-64. Also confirmed here under Debian 7 x86_64 / v4.3.0.2 Build ID: 14ed55896fdfcb93ff437b85c4f3e1923d2b1409. Both ODTs exported to PDF as expected. > I think we can close this bug report. I agree. Status set back to REOPENED.
Comments #16 and #17 -> closing as WorksForMe. Best regards. JBF