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?

(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 141467 [details]
How it looks in LibreOffice 5.2

Created attachment 141468 [details]
How it looks in LibreOffice 6.1 master

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 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

Still repro - the result looks like the PDF in attachment 141419 [details], not like in attachment 141468 [details] (no blank image).

Arch Linux 64-bit, X11
Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 55097433ed766a2ced6b87021a71c8a31cde9d99
CPU threads: 8; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 1 December 2023

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