Bug 117059 - PDF export show wrong images from ODP with inserted PDF (OK with print to PDF)
Summary: PDF export show wrong images from ODP with inserted PDF (OK with print to PDF)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 117156 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
Reported: 2018-04-17 08:58 UTC by Olivier Marti
Modified: 2022-06-13 08:23 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Original Impress, and resulting PDF (1.06 MB, application/zip)
2018-04-17 09:00 UTC, Olivier Marti
How it looks in LibreOffice 5.4 (deleted)
2018-04-18 16:02 UTC, Xisco Faulí
How it looks in LibreOffice 5.2 (145.21 KB, application/pdf)
2018-04-18 16:03 UTC, Xisco Faulí
How it looks in LibreOffice 6.1 master (603.47 KB, application/pdf)
2018-04-18 16:04 UTC, Xisco Faulí

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Marti 2018-04-17 08:58:25 UTC
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
Comment 1 Olivier Marti 2018-04-17 09:00:31 UTC
Created attachment 141419 [details]
Original Impress, and resulting PDF
Comment 2 V Stuart Foote 2018-04-17 16:13:38 UTC
Confirmed on Windows 10 Ent 64-bit en-US with
Version: (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.

Comment 3 Miklos Vajna 2018-04-18 07:09:04 UTC Comment hidden (obsolete)
Comment 4 V Stuart Foote 2018-04-18 13:11:02 UTC
(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.
Comment 5 Xisco Faulí 2018-04-18 16:02:51 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2018-04-18 16:03:31 UTC
Created attachment 141467 [details]
How it looks in LibreOffice 5.2
Comment 7 Xisco Faulí 2018-04-18 16:04:07 UTC
Created attachment 141468 [details]
How it looks in LibreOffice 6.1 master
Comment 8 Xisco Faulí 2018-04-18 16:14:18 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2018-04-18 16:15:56 UTC
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
Comment 10 V Stuart Foote 2018-04-23 02:43:36 UTC
*** Bug 117156 has been marked as a duplicate of this bug. ***
Comment 11 Timur 2019-01-14 11:21:48 UTC Comment hidden (obsolete)
Comment 12 Timur 2020-06-12 08:09:01 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2022-06-13 03:26:12 UTC Comment hidden (obsolete)
Comment 14 Timur 2022-06-13 07:25:18 UTC Comment hidden (obsolete)
Comment 15 Timur 2022-06-13 08:22:37 UTC
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