Description: A simple Impress document with one page. PNG images inserted shows wrongly when saved in PDF Steps to Reproduce: 1. Mac screen capture in PNG format 2. Crop images with Preview 3. Insert in LibreOffice Impress 4. Crop images 5. Export in PDF Actual Results: The PDF shows a part of the image which does not appear in the Impress file. Expected Results: LibreOffice and PDF should show the same Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15
Created attachment 141419 [details] Original Impress, and resulting PDF
Confirmed on Windows 10 Ent 64-bit en-US with Version: 6.0.3.1 (x64) Build ID: 62abb169b0efa1520d7bee1f586865354060b989 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group The Impress ODP has both PNG and PDF images embedded. When printing via gs the PNG are used. On export to PDF, the embedded PDF are used--but get mangled. Extracting the embedded PDF, they all view (Adobe Reader) as expected. The PDF Producer is listed as: MAC OS X 10.12.6 Quartz PDF Context. But on editing (Acrobat), each chart is a crop out from a larger part of a PDF that is still intact in the ODF. I'd lean toward =>NOB bcz the Quartz generated PDF is corrupt and needs to be cleaned before use. But I'm not sure if we are expecting more robust handling when inserting cropped PDF and how we guard for the cropping extents. @Miklos?
`pdfcrop` from tex is something I tested in the past, that was working fine within LO. How do you know that generated PDF is corrupt, do you have the validation result from https://www.pdf-online.com/osa/validate.aspx or some other PDF validator?
(In reply to Miklos Vajna from comment #3) > `pdfcrop` from tex is something I tested in the past, that was working fine > within LO. How do you know that generated PDF is corrupt, do you have the > validation result from https://www.pdf-online.com/osa/validate.aspx or some > other PDF validator? No, sorry I was not clear. Corrupt in the sense that when exported back to PDF the cropping window for each embedded PDF image has the correct dimension, but is misplaced from its original. So is that an internal of the OS X cropping to PDF (and maybe NOB), or something we need to adjust in LO's PDF export filter to correct location of the cropped element? Guess when I get a moment I'll check if after restoring the full PDFs, i.e. reversing the cropping, I can use a different PDF editor to crop out each chart and then recompose the Impress slide. And then export it from LibreOffice as PDF to see if there is a better result.
Created attachment 141466 [details] How it looks in LibreOffice 5.4
Created attachment 141467 [details] How it looks in LibreOffice 5.2
Created attachment 141468 [details] How it looks in LibreOffice 6.1 master
The content of attachment 141466 [details] has been deleted for the following reason: incorrect
Before https://cgit.freedesktop.org/libreoffice/core/commit/?id=1ec8557d86d53c9df5afd5607a953ec72c33702f, it was exported as displayed in attachment 141467 [details], then the export is broken for some commits, and finally it works again after https://cgit.freedesktop.org/libreoffice/core/commit/?id=242a9b634213acf03cabc373928555dc81afc672, when the output is already incorrect
*** Bug 117156 has been marked as a duplicate of this bug. ***
Repro 6.3+.
Repro 7.1+.
Dear Olivier Marti, 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
Repro 7.4+.
Repro 7.4+. Mikloš, please see this. Regression is Caolán's but you fixed a similar one. (In reply to Xisco Faulí from comment #9) > Before > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=1ec8557d86d53c9df5afd5607a953ec72c33702f, it was exported as displayed > in attachment 141467 [details], Meaning that's the 1st bad commit where export is blank: author Caolán McNamara <caolanm@redhat.com> 2017-03-15 take pre-calculated size from vector::size There was another bug 114460 of similar title that also went blank by the same commit. That one was fixed by Mikloš. > then the export is broken for some commits, > and finally it works again after > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=242a9b634213acf03cabc373928555dc81afc672, when the output is already > incorrect Meaning that export went from blank to differently bad: author Miklos Vajna <vmiklos@collabora.co.uk> 2017-04-05 tdf#106972 vcl PDF export, PDF images: handle indirect font references